PageKit: el creador de sitios GrapesJS autoalojado, con el código fuente incluido. Obtener acceso anticipado

Creador de páginas de marca blanca

Creador de páginas de marca blanca con GrapesJS

Crea un creador de páginas visual totalmente personalizado con tu marca para tu SaaS, agencia o plataforma. Personaliza la interfaz del editor, controla usuarios y permisos, gestiona los datos de los inquilinos y publica a través de tu propia infraestructura.

Totalmente personalizableAutoalojadoListo para múltiples inquilinosBloques y plantillas personalizadasTus datos e infraestructura
TTu marca
  • Panel
  • Páginas
  • Plantillas
  • Recursos
  • Ajustes
Páginas / Lanzamiento de primaveraVista previaPublicar

Bloques

  • Hero
  • Características
  • Precios
  • FAQ
  • CTA

Estilos

  • Espaciado
  • Tipografía
  • Color
  • Distribución
El motor de edición es el mismo en ambos frames. Todo lo que un cliente lee — la navegación, las etiquetas, los nombres de bloques, los botones — pertenece a tu producto.
Consulta el producto

Tres editores. Un motor.

Ninguno de estos tres se parece a los demás, y los tres son el mismo motor de edición visual por debajo. Esa es toda la propuesta de etiqueta blanca: el motor es una dependencia, la interfaz es tu producto. Carga uno y haz clic antes de leer otra palabra.

Abrir en una pestaña nueva

La demo de stock, sin estilo ni marca. Este es el punto de partida de toda construcción de marca blanca — y el que tus clientes nunca deberían ver.

grapesjs.com/demo.htmlReferencia

La demo se carga en un marco incrustado solo después de hacer clic, así que la página en sí se mantiene ligera.

Antes / después

Desde editor genérico hasta tu producto

El white-labelling suele describirse como un intercambio de logotipos. No lo es. Compara los dos fotogramas a continuación: mismo lienzo, mismo arrastrar y soltar, mismos controles de estilo — y dos productos completamente diferentes desde el punto de vista de la persona que los usa.

Editor sin título
  • Inicio
  • Documentos
  • Biblioteca
  • Archivos
  • Opciones
Document-1VistaSalvar

Elementos

  • Sección
  • Columna
  • Texto
  • Imagen
  • Botón

Propiedades

  • Margen
  • Fuente
  • Antecedentes
  • Pantalla
Cambia el marco para comparar. La disposición es deliberadamente idéntica en ambos estados: solo cambia la identidad.

Antes

Un editor genérico

  • Interfaz y disposición de paneles por defecto
  • Nombres genéricos de elementos que tus usuarios tienen que aprender
  • Plantillas genéricas para principiantes que no encajan en ningún producto en particular
  • Vocabulario tomado del editor, no de tu dominio
  • No hay relación con el resto de tu aplicación
  • Preguntas de apoyo que en realidad son preguntas de editor

Después

Tu constructor de marca

  • Tu logo, colores y tipografía
  • Tu navegación, envolviendo el editor como una pantalla más
  • Tus bloques, nombrados según las cosas que realmente construyen tus clientes
  • Tus plantillas, con opiniones sobre tu caso de uso
  • Tu terminología, en cada etiqueta y estado vacío
  • Tus permisos deciden qué puede ver y hacer cada usuario
  • Tu flujo de trabajo editorial, terminando donde empieza tu infraestructura

Tus usuarios deberían sentir que están usando tu producto — no un editor de terceros que casualmente está incrustado en él.

Definición

¿Qué es un creador de páginas de marca blanca?

Un creador de páginas de marca blanca es un sistema visual de edición de páginas que puede integrarse en otro producto y personalizarse para adaptarse a su marca, su experiencia de usuario y sus reglas de negocio.

La expresión se toma prestada de la fabricación, donde un producto white label es fabricado por una empresa y vendido bajo el nombre de otra. Aplicado al software, significa que el motor de edición es una dependencia que elige tu equipo, y todo lo que el cliente percibe — la interfaz, el vocabulario, la biblioteca de contenidos, las reglas sobre quién puede hacer qué — te pertenece a ti. Por tanto, un creador de páginas white label es menos un producto que instalas y más un producto que ensamblas.

Qué cubre realmente el white label

  • Imagen de marca
  • Editor UI
  • Bloques
  • Plantillas
  • Componentes
  • Roles de usuario
  • Permisos
  • Almacenamiento
  • Recursos
  • Publicación
  • Dominios personalizados
  • Terminología de producto

El white label es más que cambiar un logotipo. Cada elemento anterior es una decisión sobre quién posee una capa de la experiencia — y un constructor que se detiene en el logo sigue siendo reconociblemente la herramienta de otra persona.

Propiedad

Tu marca. Tus datos. Tu infraestructura.

Una build white label es un montón de capas, y merece la pena ser preciso sobre cuáles de ellas puede proporcionar un motor de edición visual y cuáles no. Lee la pila de arriba hacia abajo: lo que ve tu cliente, hasta dónde finalmente se encuentra la página publicada.

  1. Tu productoTu producto
  2. Tu marcaTu producto
  3. Editor de marca blancaMotor de edición
  4. ExtensionesPlugins
  5. Tus datosTu producto
  6. Tu backendTu producto
  7. Tu infraestructura editorialTu producto
Tu producto

Tu producto

La aplicación en la que inicia sesión tu cliente. Todo lo que hay a continuación se accede a través de ella, por eso el constructor se interpreta como una función y no como una herramienta.

Tu producto

Tu marca

Identidad, tono y vocabulario. Aplicado al shell del editor, los nombres de bloques y cada cadena que lee un usuario.

Motor de edición

Editor de marca blanca

El motor de edición visual: lienzo, componentes, arrastrar y soltar, controles de estilo, edición responsiva, serialización. Código abierto, autoalojado y personalizable hasta el nivel del panel.

Plugins

Extensiones

Bloques, plantillas, presets, adaptadores de almacenamiento, integraciones de recursos y comandos de exportación que completan lo que el núcleo deja deliberadamente abierto.

Tu producto

Tus datos

Proyectos, páginas, revisiones y recursos, en tu esquema y tu base de datos. El editor serializa un proyecto; dónde está escrito ese proyecto es tu decisión.

Tu producto

Tu backend

Cuentas, organizaciones, roles, permisos, facturación y el API con el que habla el editor. Ningún motor de edición puede proporcionar esto, porque es tu lógica de negocio.

Tu producto

Tu infraestructura editorial

Renderizado, alojamiento, caché, dominios y certificados para las páginas que tus clientes envían.

El motor de edición es la única capa que no tienes que construir. Cada otra capa es donde tu producto realmente se diferencia — lo cual es una buena razón para no pasar un año reconstruyendo la que ya está resuelta.

Mapa de control

Qué capa controla qué

La misma pila, detallada. Tres carriles: lo que el motor te ofrece de fábrica, lo que puede ofrecer una extensión y lo que solo tu aplicación puede poseer. El tercer carril es el honesto — y es donde un comprador empresarial gastará sus preguntas.

Tu aplicación
  • Usuarios y cuentasIdentidad, sesiones, incorporación
  • PermisosQuién puede editar, aprobar y publicar
  • Multi-inquilinaAislamiento entre clientes
  • Flujo de trabajo de aprobaciónRedactar, revisar, publicar estados
  • Pista de auditoríaQuién cambió qué y cuándo
  • Dominios personalizadosDNS, certificados, enrutamiento
  • Facturación y planesEmbalaje, límites, suscripciones
Motor de edición
  • Lienzo visualRenderizado en directo de la página que se está editando
  • Arrastrar y soltarColocación, anidamiento y reordenación
  • Controles de estiloTipografía, espaciado, color, disposición
  • Edición responsivaEdición por punto de interrupción
  • Paneles y barra de herramientasEditor Chrome, configurable y reemplazable
  • ComandosAcciones personalizadas vinculadas a tus propios botones
  • Lenguaje del editorCadenas de interfaz, traducibles
Plugin o código personalizado
  • Imagen y temaLogotipo, colores, tipografía, iconos
  • Biblioteca de bloquesLas secciones con las que componen tus usuarios
  • PlantillasPuntos de partida por caso de uso
  • Biblioteca de recursosSubidas, almacenamiento multimedia, herramientas de imágenes
  • Almacenamiento de proyectosCuando un proyecto se lee y escribe
  • ExportaciónMarcado, archivos, datos estructurados de proyectos

Nada en el carril derecho es un hueco en el editor — esas capacidades dependen de tus cuentas, tu modelo de tenencia y tu infraestructura, así que ningún motor de edición puede decidirlas por ti.

Experiencia del cliente

Lo que ven tus clientes

Tu cliente nunca abre un editor. Abre tu producto, va a sus páginas, elige una plantilla y empieza a editar — y el motor de edición es el que dibuja el lienzo en medio de ese camino.

El viaje que realmente recorre tu cliente

  1. Tu panel
  2. Páginas
  3. Elegir plantilla
  4. Editor visual
  5. Personalizar
  6. Vista previa
  7. Publicar
Cada paso de este flujo es una pantalla de tu aplicación. Solo uno de ellos renderiza un lienzo de edición, y hasta ese está dentro de tu navegación, tu cabecera y tus permisos.

GrapesJS puede trabajar entre bastidores mientras tus clientes interactúan con la experiencia de tu producto.

Arquitectura

Cómo construir un creador de páginas de marca blanca

Arquitectónicamente, la división es limpia, y mantenerla limpia es lo que hace que la compilación sea mantenible. Tu aplicación posee la identidad, la tenencia y las reglas de negocio. El constructor de páginas es una función de esa aplicación. El motor de edición es una biblioteca de la que depende la funcionalidad.
  1. Your SaaS

    Tu producto, con el constructor como una característica entre varias.

  2. Application layer

    Autenticación, organizaciones, facturación, usuarios y permisos — el contexto en el que se ejecuta cada sesión de edición.

  3. Page Builder

    La función del creador de páginas: carga de proyectos, guardado, selección de plantillas, disparadores de publicación.

  4. GrapesJS

    La capa de edición visual — lienzo, componentes, bloques, capas, estilos, recursos y comandos.

    • Canvas
    • Components
    • Blocks
    • Layers
    • Styles
    • Assets
    • Commands

GrapesJS se encarga de la capa de edición visual. Tu aplicación se encarga de la lógica de negocio que la rodea — y el límite entre ambas es la decisión de diseño más importante de toda la construcción.

Mira cómo funciona

Qué aporta tu aplicación al límite

  • Autenticación
  • Organizaciones
  • Facturación
  • Usuarios
  • Permisos
Multiinquilino

Crea un creador de páginas de marca blanca multiinquilino

Si más de un cliente utiliza tu constructor, la tenencia deja de ser un detalle de implementación. Cada organización necesita sus propias páginas, su propia biblioteca de recursos, sus propias plantillas y su propia marca — y debe ser estructuralmente incapaz de acceder a la de nadie más.

Tu plataforma

Es propietario del límite de inquilino y lo hace cumplir en cada solicitud

  • Org A

    • Páginas
    • Recursos
    • Plantillas
    • Marca
  • Org B

    • Páginas
    • Recursos
    • Plantillas
    • Marca
  • Org C

    • Páginas
    • Recursos
    • Plantillas
    • Marca
El fan-out ocurre en tu aplicación. El editor se instancia por sesión con el proyecto, assets y conjunto de bloques al que tiene derecho ese inquilino.
  • Aislamiento de inquilinos

    Cada proyecto, fila de recursos y plantillas se asigna a una organización, y el alcance se aplica al lado del servidor — no filtrando en el navegador.

  • Proyectos

    Las páginas de un inquilino son filas en tu base de datos. El editor carga un proyecto a la vez y lo vuelve a escribir a través de tu API.

  • Bibliotecas de recursos

    Las subidas caen en un prefijo o cubo por inquilino, por lo que el contenido multimedia de un cliente nunca puede aparecer en el selector de otro.

  • Conjuntos plantilla

    Las plantillas pueden ser globales, específicas de un plan o privadas para una sola organización, que a menudo es lo que realmente desbloquea una actualización de plan.

  • Marca por inquilino

    Los colores, fuentes y logotipos se resuelven por organización, de modo que los clientes de una agencia ven su propia identidad en el mismo despliegue.

  • Objetivos de publicación

    Cuando se publican las páginas de un inquilino — path, subdominio o dominio personalizado — es la configuración de inquilinos que resuelve tu aplicación.

GrapesJS no tiene un concepto incorporado de inquilinos. Edita un proyecto a la vez; el aislamiento, el alcance y las comprobaciones de derechos alrededor de ese proyecto se implementan en tu aplicación y se aplican en tu backend.

Imagen de marca

Haz que el editor parezca tu producto

La personalización es más profunda de lo que la mayoría de equipos planean. Estos cuatro niveles están ordenados según lo visibles que son, no por el trabajo que requieren — y el último es el que separa una herramienta renombrada de un producto que se siente nativo.

  • 01

    Identidad visual

    La capa con la que todos empiezan. Necesaria, y por sí sola nunca es suficiente.

    • Logotipo
    • Colores
    • Tipografía
    • Iconos
  • 02

    Editor UI

    El cromo alrededor del lienzo. Los paneles pueden ser reorganizados, reemplazados o renderizados por tus propios componentes.

    • Paneles
    • Barra de herramientas
    • Navegación
    • Comandos
    • Menús
  • 03

    Sistema de contenidos

    Lo que los usuarios pueden colocar realmente en una página. Aquí es donde un builder deja de ser genérico.

    • Bloques
    • Componentes
    • Plantillas
    • Presets
  • 04

    Lenguaje del producto

    Las palabras. Un usuario que lee tu vocabulario por todas partes nunca se da cuenta de que hay un motor debajo.

    • Etiquetas
    • Terminología
    • Flujos de usuario
    • Incorporación

Las cadenas de interfaz del editor son traducibles y sus paneles son configurables, así que los dos primeros niveles son configuraciones y no bifurcaciones. El núcleo es BSD-3-Clause, licenciado y autoalojado, lo que es lo que hace posibles los niveles más profundos.

Control de acceso

Da a cada usuario el nivel adecuado de control

Un constructor que distribuye a equipos necesita más de un tipo de usuario. Estos cinco roles cubren la mayoría de los productos; los nombres importan menos que el hecho de que cada uno resuelva un conjunto diferente de paneles visibles, bloques disponibles y derechos de publicación.

  • Propietario

    Acceso completo, incluyendo facturación y eliminación

  • Administrador

    Usuarios, configuración y publicación

  • Diseñador

    Diseños, estilos y plantillas

  • Editor

    Contenido dentro de bloques aprobados

  • Lector

    Acceso de solo lectura y avances

Cómo llega un permiso al lienzo

  1. Usuario
  2. Rol
  3. Permisos
  4. Paneles visibles
  5. Bloques disponibles
  6. Derechos de publicación

Lee la cadena de arriba hacia abajo: los tres primeros pasos ocurren en tu aplicación, y solo los últimos tres son la configuración del editor. Ocultar un panel es una consecuencia de renderizado de una decisión ya tomada y ya aplicada en el lado del servidor: un permiso que solo existe en el navegador no es un permiso.

Gobernanza

Del borrador a la página publicada

En una herramienta de un solo usuario, editar y publicar son la misma acción. En un producto vendido a equipos, son estados separados con derechos distintos — y esa separación suele ser lo primero que pregunta un comprador empresarial.

  1. 1

    Borrador

    Existe una página en tu base de datos sin representación pública todavía.

  2. 2

    Edición

    Cualquiera que tenga derechos de edición en este proyecto trabaja en el lienzo.

  3. 3

    Revisión

    El borrador se comparte como un avance, con los comentarios gestionados por tu producto.

  4. 4

    Aprobar

    Un usuario con derechos de aprobación firma el acuerdo. El cambio de estado es tuyo para registrar.

  5. 5

    Publicar

    Tu infraestructura renderiza y publica la página. El papel del editor ha terminado.

Las etapas marcadas son donde debe estar una comprobación de autorización.

Los editores pueden crear contenido mientras que solo los usuarios autorizados pueden publicarlo — una frase que decide un número sorprendente de acuerdos empresariales.

Sistema de contenidos

Crea tu propio sistema de contenidos

El núcleo incluye una paleta de bloques vacía a propósito: un conjunto genérico de bloques sería incorrecto para cada producto en el que se colocara. Lo que pongas en esa paleta es la decisión más específica de producto de toda la construcción.

  • Hero

    Tu sección inicial, con los campos que realmente utiliza tu producto.

  • Precios

    Tablas de planos que puedan leer tus propios datos de precios.

  • Testimonios

    La prueba social expone la forma en que tu marca la presenta.

  • Cuadrícula de características

    Una cuadrícula repetible que tus usuarios no puedan romper accidentalmente.

  • FAQ

    Pares de preguntas y respuestas, ampliables en la página publicada.

  • Contacto

    Un formulario conectado por cable a tu endpoint, no al de un tercero.

  • CTA

    El bloque de conversión, bloqueado a tus estilos de botones.

  • Pie de página

    Un pie de página compartido que se mantenga consistente en cada página.

Plantillas

Dale a cada nueva página un punto de partida

Las plantillas son la forma en que un constructor enseña a sus usuarios cómo es un bien. Un lienzo en blanco intimida; un conjunto de plantillas basado en el trabajo de tus clientes es una característica del producto.

Tipos de plantillas que merecen la pena enviar

  • Página de incorporación
  • Página de campaña
  • Página de producto
  • Página de precios
  • Página de documentación
  • Página del evento
  • Página del portal del cliente
  • Micrositio del cliente

Estos son tipos de plantillas que un constructor suele enviar, no listados de catálogo. Lo que contiene tu conjunto debería derivarse de lo que tus clientes publican con más frecuencia.

No des a los usuarios un editor genérico. Dales un editor diseñado para tu producto.

Publicación

Permite que los clientes publiquen bajo su propia marca

Para agencias y plataformas web, la página publicada que lleva el dominio propio del cliente es el producto. También es una preocupación entera de infraestructura — merece la pena diseñar desde el principio, porque adaptar el enrutamiento de dominios a un constructor en activo es desagradable.

  1. Tu plataforma
  2. Espacio de trabajo para clientes
  3. Dominio personalizado
  4. Página publicada
El editor produce la página. Todo desde el espacio de trabajo hacia la derecha es tu alojamiento, tu enrutamiento y tu gestión de certificados.
  • Un dominio es la configuración de inquilino

    Guarda el nombre del host junto al espacio de trabajo, verifica la propiedad y luego enruta las solicitudes entrantes hacia las páginas publicadas de ese tenant.

  • Los certificados son tuyos para automatizar

    Emitir y renovar certificados por dominio de cliente es responsabilidad de la plataforma, ya sea que lo gestiones tú mismo o lo deleges a un host.

  • La publicación puede ser un despliegue

    Algunos equipos renderizan páginas desde su propia base de datos; otros envían la salida generada a un host estático. Ambos patrones funcionan, y una familia de plugins ya automatiza la segunda.

  • Previsualización antes de que exista el dominio

    Asigna a cada página una URL de vista previa alojada en la plataforma desde el principio, para que la revisión y aprobación no esperen a DNS.

Ninguna biblioteca de edición visual ofrece alojamiento de dominio. GrapesJS emite páginas; DNS, certificados, enrutamiento y caché permanecen con tu infraestructura o tu proveedor de alojamiento.

Responsabilidad

Saber quién cambió qué

En el momento en que dos personas pueden editar la misma página, alguien preguntará quién la cambió. Un rastro de actividades es barato de añadir mientras diseñas, guarda y publica, y caro de reconstruir después.

Actividad

  • AlexEditado · Página principal12:42
  • MariaPublicado · Página de aterrizajePublicado13:07
  • JohnCambios · Sección de precios13:21

Qué anotar en cada entrada

  • Actor
  • Acción
  • Proyecto
  • Versión
  • Marca temporal
  • Inquilino

Filas ilustrativas. GrapesJS no tiene registro de auditoría; la pista la escribe tu aplicación cuando gestiona un guardado, una aprobación o una publicación, que además es el único lugar donde se sabe qué usuario está actuando.

Pila de plugins

Construye tu pila para un creador de páginas de marca blanca

Lee la pila como un orden de construcción. Cada peldaño está suministrado por el motor, disponible como plugin o trabajo que solo tu equipo puede hacer — y ser honesto sobre cuál es lo que hace que una estimación sobreviva al contacto con el proyecto.

  1. Motor de ediciónCódigo abierto
  2. Tema de marca blanca y UI personalizadoPlugin
  3. Bloques personalizadosPlugin
  4. PlantillasPlugin
  5. Roles y permisosTu aplicación
  6. AlmacenamientoPlugin
  7. RecursosPlugin
  8. Registros de auditoríaTu aplicación
  9. ExportaciónPlugin
  10. PublicaciónPlugin

Dos peldaños no tienen respuesta de catálogo, y eso es deliberado más que un descuido: los roles y el registro de auditorías dependen de tu modelo de identidad y tu base de datos, así que son trabajo de aplicación. Si esa es la parte que tu equipo prefiere no construir solo, es exactamente para eso que existen los servicios de implementación.

Mercado

Plugins para cada capa de la pila

Cada anuncio a continuación es un producto real en GJS.Market, agrupado según el trabajo que realiza en una versión de marca blanca.

Puntos de partida

Empieza con una pila que se ajuste a tu producto

Tres combinaciones que aparecen repetidamente. Ninguna es un paquete: son puntos de partida, y cada una de ellas necesita tu aplicación alrededor de ellas.

Los precios son los precios listados en el mercado en el momento de la construcción y se muestran para orientación.

Hazlo o cómpralo

Empieza con GrapesJS. Añade lo que necesite tu producto.

GrapesJS proporciona la base de edición visual. Los plugins de GJS.Market pueden añadir funcionalidades especializadas sin que tu equipo tenga que construir todas las funciones internamente. Ambas vías que se muestran a continuación son legítimas: la cuestión es qué partes de la pila son realmente tu diferenciadora.

Construye todo tú mismo

Control total sobre cada línea, pagado en tiempo de ingeniería que sigues pagando.

Lo que asumes

  • Más ingeniería, en una superficie que no es tu producto
  • Más mantenimiento a medida que los navegadores y frameworks avanzan
  • Más código interno que nadie fuera de tu equipo revisa
  • Errores del editor compitiendo con el trabajo de la hoja de ruta por la atención

Justo cuando el propio comportamiento de edición es tu diferencia.

Habla a través del alcance

Extender con plugins

Adopta lo que se resuelve y dedica tu ingeniería a lo que es tuyo.

Cómo es el lazo

  • Instala un plugin que cubra un peldaño de la pila
  • Configúralo con tus datos y tu API
  • Personaliza las piezas que tu producto necesita poseer
  • Envía y mantén a tu equipo en arrendamiento, permisos y publicación

Justo cuando tu diferenciador es el producto alrededor del editor.

Explorar plugins
Comparación

Crea un editor white label desde cero frente a GrapesJS

Función por característica, lo que tú mismo estarías escribiendo frente a lo que un motor ya establecido ya expuesto. Las filas marcadas como capa de aplicación son la mitad honesta de esta tabla: un motor de edición no puede poseerlas, así que están en tu agenda de cualquier forma.

CapacidadDesde ceroGrapesJS
Lienzo visualConstrucciónIncluido
Arrastrar y soltarConstrucciónIncluido
ComponentesConstrucciónIncluido
BloquesConstrucciónExtensible
EstiloConstrucciónIncluido
Edición responsivaConstrucciónIncluido
UI personalizadoConstrucciónExtensible
RecursosConstrucciónExtensible
AlmacenamientoConstrucciónExtensible
PermisosConstrucciónCapa de aplicación
Multi-inquilinaConstrucciónCapa de aplicación
PublicaciónConstrucciónCapa de aplicación
PluginsConstrucciónExtensible

Los veredictos reflejan la versión actual, 2026-09-02 re-verificada. "Capa de aplicación" significa que la capacidad depende de tus cuentas e infraestructura, no que falte.

Construye tu lógica de negocio y tu experiencia de marca. No reconstruyas el motor de edición visual.

Modelos adyacentes

Marca blanca vs embebible vs creador de páginas SaaS

Tres decisiones relacionadas que se discuten como si fueran una sola. Se acumulan en lugar de competir: la mayoría de los productos acaban haciendo las tres, en este orden.

Comercial

Convierte tu creador de páginas en un producto

Una vez que el constructor es tuyo, también lo es la relación comercial que lo rodea. Cómo lo empaquetas es una decisión empresarial más que técnica, pero merece la pena tomarlo antes de que el modelo de arrendamiento esté definido, porque los planes y límites son cuestiones de arrendamiento.

  1. Tu producto
  2. Editor visual
  3. Espacio de trabajo para clientes
  4. Suscripción
  5. Tus ingresos
Eres dueño de cada paso de esta cadena, incluyendo los precios y la relación con el cliente al final.
Embalaje

Una forma de empaquetar a un constructor

Una forma convencional de cuatro niveles, que demostró concretar las implicaciones de arrendamiento en lugar de establecer una lista de precios.

  1. 01

    Gratis

    Un espacio de trabajo, un pequeño límite de páginas, URLs de vista previa alojadas en la plataforma.

  2. 02

    Pro

    Más páginas, el conjunto completo de plantillas, un dominio personalizado.

  3. 03

    Equipo

    Varios asientos, roles y un paso de aprobación antes de publicar.

  4. 04

    Enterprise

    Múltiples organizaciones, una pista de auditoría, bloques personalizados y términos de soporte.

Solo ilustrativo. Lo que pertenece a cada nivel depende de tu mercado — pero fíjate en cuánto de la escala se basa en las características de permisos y arrendamientos que aparecen antes en esta página.

Tú controlas tus precios, planes y la relación con el cliente.

Base

¿Por qué empezar con un editor de código abierto?

Una compilación de marca blanca exige exigencias que un editor cerrado no puede satisfacer. Necesitas cambiar la interfaz, ejecutarla en tu propia infraestructura e integrarla con sistemas que el proveedor nunca ha oído conocer. El núcleo es BSD-3-Clause, licenciado y auto-hostable, lo que hace que todo eso sea posible.

  • Personalización

    La interfaz es de marcado y configuración que puedes leer, reemplazar y ampliar — no una caja negra con un API tematizado.

  • Autoalojamiento

    El editor se ejecuta donde se ejecuta tu aplicación, así que los proyectos y recursos nunca tienen que salir de tu infraestructura.

  • Extensibilidad

    Una arquitectura de plugins documentada, además de un ecosistema de plugins existentes para adaptar en lugar de empezar.

  • Libertad de integración

    El almacenamiento, los recursos y los comandos son costuras que apuntas a tus propios servicios.

  • Control sobre la infraestructura

    El despliegue, las actualizaciones y la ubicación de datos son tus decisiones, según tu calendario.

  • Auditabilidad

    Puedes leer el código que envías a los clientes, lo cual cada vez es más un requisito de compras que una preferencia.

Integración

Integra con tu stack actual

El editor es una biblioteca de navegador, así que va donde ya está tu aplicación. Estas páginas cubren la mecánica por framework: montar, limpiar y mantener el estado del editor fuera de tu bucle de renderizado.

Hoja de ruta

Desde prototipo hasta producción

  1. 1
    Fase 1

    Editor

    Pon en marcha el motor con un set de bloques de salida, un par de plantillas y tu marca aplicada. El objetivo es una demo en la que cree tu propio equipo, no un producto que se pueda enviar.

  2. 2
    Fase 2

    Producto

    Intégralo en la aplicación: autenticación, usuarios, organizaciones, almacenamiento de proyectos y una biblioteca de recursos. Aquí es donde el creador deja de ser una demo.

  3. 3
    Fase 3

    Gobernanza

    Roles, permisos, un paso de aprobación y un rastro de actividades. Normalmente impulsado por el primer cliente con más de tres personas.

  4. 4
    Fase 4

    Escala

    Multi-inquilinos, dominios personalizados, infraestructura de publicación, facturación, analítica y los flujos de trabajo de marca blanca que permiten que cada cliente se parezca a sí mismo.

Rendimiento

Consideraciones de rendimiento

Un constructor tiene dos tiempos de ejecución con casi nada en común, y tratarlos como uno es el error de rendimiento más común en este tipo de producto.

  • Carga perezosamente el editor

    Carga el paquete de edición cuando un usuario abra el editor, no cuando abra tu panel de control.

  • Mantén el estado del editor fuera del estado de tu app

    El editor gestiona su propio árbol. Espejarlo en tu tienda global vuelve a renderizar tu aplicación en cada pulsación de teclado.

  • Paginar grandes bibliotecas de recursos

    Un inquilino con miles de imágenes necesita un selector paginado y buscable en lugar de una lista larga.

  • Plugins con cargas perezosas

    Los motores de texto enriquecido, editores de código y herramientas de imagen merecen la pena posponerlos hasta que se abra el panel que los necesita.

  • Separa los tiempos de ejecución

    Nada de lo que necesita el editor pertenece al paquete que un visitante descarga para una página publicada.

  • Optimizar la salida publicada de forma independiente

    Las imágenes, el CSS crítico y la caché para páginas publicadas las decide tu capa de renderizado, donde tienes control total.

El entorno de autoría y el sitio web publicado no necesitan tener los mismos requisitos de tiempo de ejecución.

Seguridad

Consideraciones de seguridad

Un constructor multi-inquilino acepta contenido no confiable y produce páginas que otras personas cargan. Ambas mitades merecen atención, y la mayor parte del trabajo está en tu lado del límite.

  • Autentica cada llamada API

    Carga de proyectos, guardado, subida y publicación de recursos son todos endpoints a los que llega una sesión autenticada — y todos merecen ser tratados como tales.

  • Validar permisos en el lado del servidor

    Vuelve a comprobar en el servidor qué ya ocultaba la interfaz. Un botón oculto es una posibilidad de experiencia de usuario, no control de acceso.

  • Aislar datos de inquilinos

    Define cada consulta por organización y prefieres un alcance imposible de omitir antes que uno que todo desarrollador deba recordar.

  • Validar subidas

    Comprueba el tipo, tamaño y extensión en el servidor, y sirve medios de usuario desde un origen separado cuando puedas.

  • Limpiar el contenido de los usuarios

    Un constructor visual puede producir un margrado arbitrario. Decide deliberadamente si se permiten scripts personalizados y desinfecta en consecuencia.

  • Proteger los endpoints de publicación

    La publicación cambia lo que ve el público. Limita la tarifa, autoriza explícitamente y registra quién la activó.

  • Validar los datos del proyecto

    Un proyecto guardado es una entrada del usuario. Valida su forma antes de almacenarlo o volver a renderizarlo.

  • Nunca confíes en los permisos del lado del cliente

    La lista de bloques y el conjunto de paneles son configuraciones sobre las que el navegador puede estar dispuesto.

Esta es una lista de verificación inicial para un constructor en concreto, no un programa de seguridad completo, y ninguna arquitectura es segura por construcción. Trata un constructor white label como cualquier otra aplicación multi-inquilino que acepte contenido de usuario.

Implementación

¿Necesitas ayuda para crear tu creador de páginas de marca blanca?

¿Necesitas ayuda para integrar, crear marca o ampliar GrapesJS dentro de tu producto? Explora servicios de implementación para integraciones personalizadas, personalización de UI, plugins y soporte de producción — incluyendo los dos peldaños de la pila que el catálogo no puede cubrir por ti.

  • Integración del editor
  • Personalización de UI
  • Bloques y plantillas personalizadas
  • Adaptadores de almacenamiento y recursos
  • Roles y flujos de trabajo de aprobación
  • Apoyo a la producción
FAQ

Preguntas sobre el creador de páginas de marca blanca

¿Qué es un creador de páginas de marca blanca?

Un sistema visual de edición de páginas que se integra en otro producto y se personaliza para ajustarse a su marca, experiencia de usuario y reglas de negocio. Tus clientes lo utilizan como una función de tu aplicación en lugar de como una herramienta de terceros.

¿Puedo poner una marca blanca en GrapesJS?

Sí. Es una biblioteca de código abierto y autoalojada, así que la interfaz, el conjunto de bloques, las plantillas y el vocabulario son todos tuyos para cambiar. Las partes que la rodean — cuentas, permisos, arrendamiento, publicación — están implementadas en tu aplicación.

¿Puedo personalizar el GrapesJS UI?

Sí. Los paneles, botones y comandos son configurables, y la interfaz del editor puede renderizarse con tus propios componentes si quieres que herede tu sistema de diseño en lugar de aproximarse.

¿Puedo reemplazar la marca predeterminada?

Sí. No hay ningún branding de proveedor que debas mostrar. La interfaz es tuya para diseñar, y las propias cadenas del editor son traducibles, por lo que las etiquetas pueden seguir la terminología de tu producto.

¿Puedo añadir mi propio logo y colores?

Sí. La shell del editor es el marcado y los estilos en tu aplicación, así que un logo, una paleta de colores y tus tipografías se aplican igual que en cualquier otro lugar de tu producto.

¿Puedo crear bloques personalizados?

Sí, y lo necesitarás: el núcleo distribuye deliberadamente una paleta de bloques vacía. Los bloques se definen en tu propio código o se añaden mediante plugins, que es lo que permite que la paleta coincida con lo que realmente crean tus clientes.

¿Puedo crear plantillas personalizadas?

Sí. Una plantilla es un proyecto almacenado que tu aplicación ofrece como punto de partida. Las plantillas pueden ser globales, específicas de un plan o privadas para un solo cliente.

¿Puedo restringir bloqueos por rol de usuario?

Sí, inicializando el editor con el conjunto de bloques al que tiene derecho ese rol. El derecho en sí se resuelve por tu backend — restringir la paleta en el navegador es presentación, no aplicación.

¿Puedo crear un constructor de páginas multi-inquilino?

Sí, con la tenencia implementada en tu aplicación. GrapesJS edita un proyecto a la vez y no tiene concepto de organizaciones, así que definir proyectos, recursos y plantillas por inquilino es tarea de tu backend.

¿Puede cada cliente tener páginas y recursos separados?

Sí. Guarda los proyectos y recursos frente a la organización que los posee y escala cada consulta por ella. El editor se instancia por sesión solo con los datos de ese tenant.

¿Pueden los clientes publicar en dominios personalizados?

Sí, como una función de plataforma. Tu aplicación almacena el dominio junto al espacio de trabajo, verifica la propiedad y enruta las solicitudes a las páginas de ese inquilino. El editor produce la página; DNS, los certificados y el alojamiento permanecen en tu infraestructura.

¿Puedo conectar mi propia base de datos?

Sí. El editor serializa un proyecto y llama a tus endpoints para cargarlo y almacenarlo, así que cualquier base de datos detrás de tu API funciona. Nada requiere un servicio alojado.

¿Puedo usar mi propio almacenamiento?

Sí. La persistencia de proyectos y la biblioteca de assets son dos costuras configurables, y existen plugins que los apuntan a varios backends si prefieres adaptar uno antes que escribir el tuyo propio.

¿Puedo crear flujos de trabajo de aprobación?

Sí, en tu aplicación. Modela el estado de la página — borrador, en revisión, aprobado, publicado — y requiere la aprobación justo antes de que se ejecute la acción de publicación. El editor no está involucrado en la máquina estatal.

¿Puedo rastrear la actividad de los usuarios?

Sí, registrando una entrada cada vez que tu aplicación gestiona una partida, una aprobación o una publicación. GrapesJS no tiene registro de auditoría, y tu API es la única capa que sabe qué usuario autenticado está actuando.

¿Puedo crear un creador de páginas SaaS de marca blanca?

Sí — esa combinación es común. La etiqueta blanca cubre la experiencia de marca; empaquetarla como un producto comercial con planes y límites es un conjunto separado de decisiones, cubiertas en la página del creador de páginas SaaS.

¿Puedo usar GrapesJS con React?

Sí. Hay un envoltorio oficial de React, y el editor también puede montarse manualmente en un componente. La regla principal es mantener el estado del editor fuera de tu ciclo de renderizado de React.

¿Puedo usar GrapesJS con Next.js?

Sí. El editor es solo para navegador, así que se carga en el lado del cliente, mientras que las páginas publicadas se renderizan normalmente por el servidor. Mantener esos dos tiempos de ejecución separados también es la mejor decisión de rendimiento.
Empieza

Crea el creador de páginas que tus clientes vean como suyo

Empieza con el motor de edición visual GrapesJS. Añade tu marca, sistema de contenidos, permisos e infraestructura para crear un creador de páginas que se sienta nativo de tu producto.

Comienzo

Crea tu creador de páginas de marca blanca

Dinos qué estás construyendo y qué capas de la pila quieres tener. Volvemos con un telescopio.

Empieza
Explorar

Explora el catálogo de plugins

Temas, UI personalizados, bloques, plantillas, adaptadores de almacenamiento y comandos de publicación — agrupados por el peldaño de la pila que llenan.

Explorar plugins
Habla

Habla con un experto

Integración, branding, bloques personalizados, roles y flujos de trabajo de aprobación, implementados con tu equipo.

Explorar servicios

Tu marca. Tu editor. Tus clientes. Tu infraestructura.