PageKit: el creador de sitios GrapesJS autoalojado, con el código fuente incluido. Obtener acceso anticipado
Añade un editor visual de arrastrar y soltar a tu CMS headless sin tocar tu API de contenido, tu frontend ni tu infraestructura.
La pantalla de arriba es un prototipo de la disposición, dibujado en CSS para que la página no cueste nada. El motor de edición que hay detrás es real y público: abre la demo oficial de GrapesJS, arrastra una sección al lienzo, y estás viendo los mismos controles de lienzo, árbol de componentes y estilo que tu equipo de contenido tendría encima de tu propio CMS.
La demo funciona en grapesjs.com con almacenamiento en el navegador. Nada en ella toca tu contenido.
Un CMS headless le da a tu aplicación una base de contenido API en primer lugar. Lo que no siempre aporta a quienes escriben el contenido es una forma de ver la página mientras la construyen.
Los campos estructurados son excelentes para un artículo, un registro de producto o un documento de configuración. No encajan bien con una página cuyo significado es su diseño — una página de campaña, un recorrido de reportajes, una comparación de precios. Para esos, las personas que hacen el trabajo suelen pedir la misma lista corta:
Lo que piden los editores
GrapesJS proporciona esa capa de edición visual sin obligarte a cambiar tu CMS.
Una arquitectura headless separa el contenido de la presentación, por eso mismo deja un hueco de edición: el CMS conoce los campos, el frontend conoce el renderizado y nada intermedio conoce la página. Añadir una capa de edición visual cierra ese hueco sin deshacer ninguno de los lados.
CMS headless tradicional
Falta
CMS headless + GrapesJS
Añade edición visual sin renunciar a la arquitectura headless.
Porque cada una de las tres capas es buena en algo que las otras dos no, y una capa de edición visual es la única que nadie te entrega. Aquí tienes quién es dueño de qué una vez que el editor está en su lugar.
Tu CMS headless
La infraestructura de contenidos que ya gestionas.
GrapesJS
La capa de edición visual que vas a añadir.
Tu frontend
Sin cambios. Conserva todo lo que poseía antes.
Mantén la arquitectura. Mejora la experiencia de edición.
La experiencia de edición visual: lienzo, árbol de componentes, bloques, controles de estilo, anchos de dispositivos.
Persistencia a través de REST, GraphQL o tu propio API. Un adaptador de almacenamiento tiene dos funciones: una que carga y otra que guarda.
Tu infraestructura de contenido existente. Mantiene el esquema, la biblioteca multimedia, los usuarios y las reglas de publicación que ya tiene.
El API de entrega que ya leen tus frontends. Añadir un editor añade un escritor, no una segunda fuente de contenido.
Cualquier frontend que consuma tu CMS API.
Una fuente de contenido. Múltiples frontends.
Observa cómo el editor se integra en una aplicaciónLa capa de edición se conecta a través del mismo API que tu frontend ya llama. Tanto si ejecutas Strapi, Contentful, Sanity, Directus, Hygraph, Prismic, Payload o un CMS que escribió tu propio equipo, el punto de integración es un par de endpoints que cargan y guardan un documento.
Estas plataformas pueden integrarse a través de sus APIs, con la implementación exacta dependiendo del modelo de contenido de CMS y API. GJS.Market no publica una integración oficial para la mayoría de ellas, y esta página nunca implica lo contrario.
Quédate con tu CMS. Conserva tu frontend. Añade un editor visual mejor.
Las tarjetas que aparecen a continuación describen la superficie de integración que ofrece cada plataforma, no una afirmación de soporte. Una de ellas tiene un plugin de almacenamiento comunitario en el catálogo GJS.Market; el resto son integraciones que tú o un socio de implementación construiríais contra su API publicado.
REST · GraphQL
Autoalojado, con tipos de contenido que definas. El documento editor suele convertirse en un campo JSON en un tipo de colección de páginas.
REST · GraphQL
Entrega y gestión separadas APIs. El editor escribe a través dla API de gestión; tu frontend sigue leyendo el de entrega.
GROQ · GraphQL
Portable Text y un almacén de documentos. El documento editor está junto a tus campos existentes en lugar de reemplazarlos.
REST · GraphQL
La única plataforma de esta lista con un plugin de almacenamiento comunitario ya publicado en GJS.Market.
Ver el pluginGraphQL
GraphQL primero, así que el adaptador es una consulta y una mutación en lugar de dos URLs.
REST
Contenido basado en slices. Los bloques del editor se asignan limpiamente a los slices cuando mantienes el conjunto de bloques alineado con ellos.
REST · GraphQL
Colecciones definidas por código, de modo que el campo en el que escribe el editor se declara en el mismo repositorio que el editor.
REST · GraphQL · Personalizado
Cualquier cosa que pueda responder a una solicitud de carga y aceptar una solicitud de guardado. Dos endpoints es todo el contrato.
El único adaptador con nombre CMS en el catálogo
Directus Storage es un plugin de almacenamiento para GrapesJS gratuito y publicado por la comunidad, extraído del proyecto Silex. Es una referencia realmente útil sobre cómo se construye un adaptador — comandos de autenticación, cargar, guardar — pero su propia ficha señala que apunta a un SDK de Directus antiguo, así que trátalo como un punto de partida que leer, no como un producto soportado que instalar.
Directus StorageUn editor visual solo es útil en una configuración sin interfaz si lo que produce sigue encajando con el esquema que diseñaste. En GrapesJS, un tipo de componente personalizado declara su propio traits editable — y esos traits son donde van los nombres de los campos CMS.
Ejemplo práctico
hero-section
editor.DomComponents.addType('hero-section', {
model: {
defaults: {
// Traits become the fields your CMS entry already has.
traits: [
{ name: 'title', label: 'Title' },
{ name: 'subtitle', label: 'Subtitle' },
{ name: 'image', type: 'image' },
{ name: 'ctaHref', label: 'Button link' },
],
},
},
});El editor visual debería adaptarse a tu modelo de contenido, no obligar a tu CMS a adaptarse al editor.
Dos representaciones salen del mismo editor y responden a preguntas diferentes. Una puede reabrirse para editar; la otra puede renderizarse. La mayoría de los montajes de producción mantienen ambos, en columnas diferentes, y eso es una decisión de diseño más que una regla.
editor.getProjectData()El árbol de componentes, estilos, páginas y recursos como datos estructurados. Es lo que el editor necesita para reconstruir la sesión exactamente como se dejó, que es la única representación que sobrevive intacta a una segunda ronda de edición.
Úsalo cuando: Alguien volverá a abrir esta página en el editor.
editor.getHtml() + editor.getCss()Marcado y hoja de estilo generados a partir del mismo árbol. Es lo que consume una iframe de previsualización, una exportación estática o una cadena de publicación, y no es fiable reimportable como sesión de edición.
Úsalo cuando: Algo más abajo tiene que renderizarlo sin el editor.
Almacena la representación que tu editor necesita para futuras ediciones y genera la salida que requiere tu frontend o pipeline de publicación.
La misma capa de edición, apuntando a diferentes partes de tu producto. Cada una de estas tiene su propia página en GJS.Market, porque cada una plantea diferentes preguntas una vez que superas el propio editor.
Deja que los equipos de contenido creen páginas visualmente, con las entradas que sigan viviendo en el CMS que ya ejecutas.
Edición visual, en profundidadDeja que los equipos de marketing lancen campañas sin que un desarrollador esté al tanto de cada cambio de diseño.
Creadores de landing pagesCrea páginas visualmente mientras cada contenido permanece en tu CMS y cada URL en tu frontend.
Creadores de páginas de arrastrar y soltarProporciona a tus propios clientes un editor visual dentro de tu producto, además de tu contenido API.
Creadores de páginas SaaSAsigna a cada organización en tu producto sus propias páginas, recursos y plantillas detrás de un solo editor.
Editores multiinquilinoPersonaliza la experiencia de edición en función de tu marca para que el editor se lea como parte de tu producto.
Creadores de marca blancaCrea plantillas de correo reutilizables con el mismo modelo de componentes y un conjunto de bloques seguros para correo.
Creadores de plantillas de correo electrónicoEscribe páginas estructuradas de documentación visual que sigan enviando a través de tu contenido API.
Preajustes de páginaQué viene con el motor, qué añade un plugin y qué sigue siendo el trabajo de tu aplicación. La distinción importa cuando estás definiendo el alcance del trabajo en lugar de leer una lista de funciones.
GrapesJS no entrega CMS, ni hosting, ni cuentas de usuario ni modelo de permisos. Esos se quedan con tu CMS y tu aplicación.
Esta no es una decisión que tomes una sola vez para todo el producto. Es una decisión que tomas por tipo de contenido, y la mayoría de los equipos acaban ejecutando ambos.
La edición basada en formularios de tu propio CMS, impulsada por el esquema.
Mejor para
Un lienzo, donde la disposición es el contenido.
Mejor para
Utiliza campos estructurados donde la estructura importa. Utiliza la edición visual donde el diseño y la composición importen.
La edición y la publicación son eventos separados, y una configuración headless facilita su aplicación: el borrador del documento y el documento publicado son filas diferentes, leídas por tokens distintos.
La entrada existe en tu CMS con estatus de reclutamiento.
Alguien compone la página en el lienzo.
Tu interfaz representa el borrador en cualquier ancho de dispositivo.
Una segunda persona lee la página tal y como la verán los visitantes.
La aprobación la registra tu aplicación, no el editor.
Tu CMS promueve el reclutamiento y tu frontend se revalida.
Puerta humana
Entre qué debería poder alternar un revisor
Edición separada de la publicación.
Este es el beneficio que ya adquiriste al elegir un CMS headless, y añadir un editor visual no lo gasta — siempre que lo que escriba el editor permanezca en el contenido API en lugar de en una plantilla.
CMS headless
Un contenido, API, leído por cada canal
Sitio web
Next.js
Móvil
React Native
Aplicación
Nuxt
Una arquitectura headless permite que la misma infraestructura de contenido sirva a diferentes frontends.
Si el editor forma parte de un producto y no una herramienta interna, cada organización cliente necesita sus propias páginas, recursos y plantillas — y nunca debe ver las de nadie más.
Tu aplicación
La división se hace cumplir aquí, en el servidor
Organización A
Organización B
Organización C
GrapesJS no ofrece multitenencia propia. El aislamiento entre inquilinos, la marca por inquilino y las reglas de publicación son responsabilidad de tu aplicación, y cada llamada de almacenamiento debe limitarse en el servidor.
Si tus clientes usan el editor, debería parecer parte de tu producto. Los paneles, el conjunto de iconos, la biblioteca de bloques y las plantillas son configurables, y la aplicación que lo rodea proporciona todo lo que el editor no.
Los roles y permisos están en esa lista porque un editor de marca los necesita — no porque el editor los proporcione. Los hace cumplir tu backend.
El motor es un peldaño más del montón. A continuación está toda la escalera, con una etiqueta honesta en cada peldaño: qué viene en GrapesJS en sí, qué puedes comprar o descargar en GJS.Market y qué sigue siendo tu propio trabajo.
Dos peldaños están marcados como tu propio trabajo a propósito. La integración de CMS es específica para tu modelo de contenido, y el catálogo no tiene permisos ni plugin de registro de auditoría — un socio de implementación puede construir ambos, pero ningún producto aquí lo hará.
Cada anuncio a continuación se ha comprobado con el catálogo en vivo y es publicado y comprable. Los precios se leen en el mercado en el momento de la compilación, así que lo que ves es lo que dice el anuncio hoy.
A dónde va el documento del proyecto y qué ocurre cuando un navegador falla antes de que llegue.
Explora esta categoríaUn plugin de almacenamiento gratuito publicado por la comunidad para Directus — el único adaptador con nombre CMS en el catálogo, y un modelo legible para escribir el tuyo propio.
Un wrapper de almacenamiento para Cloud Firestore cuando el documento del proyecto pertenece a una base de datos alojada en lugar de tu CMS.
Persistencia en el navegador, útil como búfer offline o para una demo que debe ejecutarse antes de que exista cualquier API.
Guardado automático y recuperación por fallo. Sin ella, una sesión sin guardar desaparece cuando la pestaña se cierra y tu editor recibe la culpa.
La biblioteca de secciones de la que arrastran tus editores y el modelo de reutilización que hay detrás.
Explora esta categoríaEl conjunto básico de bloques para empezar una biblioteca, en lugar de un panel de bloques vacío el primer día.
Introducir formularios, seleccionar, marcar casillas y botones como componentes reales, así que una página con un formulario sigue siendo un solo documento.
Reutiliza un elemento a lo largo de las páginas para que un cambio en una sección compartida no tenga que repetirse manualmente.
Registrar y gestionar una biblioteca de componentes personalizada sin tener que escribir a mano el boilerplate de cada tipo.
Proyectos de varias páginas, puntos de partida reutilizables y una cadena de medios.
Explora esta categoríaAñade, renombra, duplica y exporta páginas — la estructura de varias páginas que necesita un sitio respaldado por CMS.
Plantillas prediseñadas que tus editores pueden usar para empezar una página y luego personalizar.
Los componentes de MJML se compilan en vivo en el lienzo, para las plantillas de correo que un equipo de contenido acabará pidiendo.
Transfiere el gestor de recursos a Cloudinary en lugar del uploader por defecto.
Convertir el documento del proyecto en algo que un frontend o un host pueda ofrecer.
Explora esta categoríaConvierte los datos almacenados del proyecto en HTML y CSS en el lado del servidor, que es exactamente el paso que necesita una publicación sin headless.
Una auditoría de accesibilidad en tiempo real y un panel de metadatos SEO dentro del editor, con cada hallazgo vinculado al componente que lo causó.
Exporta todo el proyecto como un archivo zip para traspaso, copia de seguridad o un host estático.
Despliega desde dentro del editor cuando el artefacto publicado sea un sitio y no una entrada CMS.
Cinco sets iniciales, extraídos de los mismos anuncios verificados. Ninguno de ellos es un paquete que compras con un solo clic — son las combinaciones que siguen apareciendo para cada tipo de producto.
Bloques, plantillas, un componente de formulario y un panel SEO — suficiente para un equipo que envía páginas de campaña sin desarrollador.
Proyectos de varias páginas, almacenamiento alojado, autosave y símbolos reutilizables — el conjunto que importa una vez que el editor tiene clientes.
Un adaptador para leer, recuperación de fallos, una auditoría de accesibilidad y SEO, y renderizado en servidor del documento almacenado. Las pruebas y las pruebas de auditoría siguen siendo trabajo personalizado.
Plantillas, una pipeline multimedia, exportación y un comando de despliegue — para páginas que acaban siendo un sitio en lugar de una entrada CMS.
Creadores de páginas de arrastrar y soltarComponentes MJML, imágenes alojadas y exportación, para las plantillas que un equipo de contenido enviará en lugar de publicar.
Creadores de plantillas de correo electrónicoLos precios provienen del catálogo en vivo en el momento de la compilación. Los listados gratuitos están marcados.
Todas las capacidades de la escalera superior son construibles. La cuestión es cuáles merecen la pena para tu equipo cuando ya existe una extensión mantenida.
| Construye todo | Extender con plugins |
|---|---|
| Más desarrollo | Implementación más rápida |
| Más mantenimiento | Extensiones reutilizables |
| Construye todas las características | Añade solo lo que necesites |
| Herramientas internas | Soluciones listas para usar |
Empieza con el editor visual. Añade capacidades a medida que tu producto crezca.
No es una comparación con proveedores, sino una comparación de alcance. Cada fila es un subsistema que necesita un editor visual, y la única pregunta es si tu equipo lo escribe.
| Capacidad | Desde cero | GrapesJS |
|---|---|---|
| Lienzo | Construir | Incluido |
| Arrastrar y soltar | Construir | Incluido |
| Componentes | Construir | Incluido |
| Bloques | Construir | Extensible |
| Estilo | Construir | Incluido |
| Edición responsiva | Construir | Incluido |
| Capas | Construir | Incluido |
| Recursos | Construir | Extensible |
| Plantillas | Construir | Extensible |
| Almacenamiento | Construir | Extensible |
| Exportación | Construir | Extensible |
"Extensible" significa que el subsistema existe y tiene un punto de extensión — el conjunto de bloques, la biblioteca de plantillas, el backend de recursos, el destino de almacenamiento y el formato de exportación son tuyos para suministrar, ya sea desde el catálogo o desde tu propio código. 2026-09-03 verificado por las afirmaciones del catálogo.
Construye tu producto CMS. No reconstruyas el motor del editor visual.
A menudo deberías hacerlo. Un editor integrado ya está integrado, ya tiene permisos y es familiar, y para contenido estructurado suele ser la respuesta correcta. Una capa dedicada a la edición visual se gana su lugar cuando necesitas cosas para las que el editor integrado no fue diseñado:
Esto no es una afirmación de que los editores integrados sean inferiores. Es una afirmación de que la superficie de edición y la infraestructura de contenido son decisiones separables.
Quédate con tu CMS. Elige tu propia experiencia de edición.
Define tu modelo de contenido
Decide qué puede crear el editor y en qué tipos de contenido existentes escribe. Esta decisión limita a todos los que siguen, así que hazlo antes de que se escriba cualquier código del editor.
Configurar GrapesJS
Configura los tipos de componentes, la biblioteca de bloques y los controles de estilo que tienen tus editores — y, igual de importante, los que no tienen.
Conectar almacenamiento
Persiste el documento del proyecto a través de REST, GraphQL o tu propio API, con la autenticación llevada a cabo por la sesión que ya emite tu CMS.
Construye la vista previa
Renderiza el borrador con tu frontend real, en una ruta a la que solo pueda llegar un revisor autenticado. Cualquier otra cosa es una vista previa de otro sitio.
Añadir publicación
Conecta los estados de borrador, revisión y producción con el flujo de trabajo que ya tiene tu CMS, y registra quién aprobó qué en tu aplicación.
El editor más pequeño que se comunica con un contenido, API. Dos endpoints, una política autosave y las dos llamadas que te dan representación a cada una.
-thumbnail.jpg&w=3840&q=70)
npm install grapesjsimport grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';
const editor = grapesjs.init({
container: '#editor',
height: '100vh',
// Load and save the project through your CMS API. Both endpoints are
// yours: GrapesJS only decides when to call them.
storageManager: {
type: 'remote',
autosave: true,
stepsBeforeSave: 10,
options: {
remote: {
urlLoad: '/api/cms/pages/home',
urlStore: '/api/cms/pages/home',
// Send the session the CMS already issued — never a CMS admin token
// that reached the browser.
fetchOptions: (opts) => ({ ...opts, credentials: 'include' }),
},
},
},
});
// The two representations, whenever you need them.
const project = editor.getProjectData(); // re-openable source
const output = { html: editor.getHtml(), css: editor.getCss() };Envía la sesión que tu CMS ya emitió. Un token de administración del CMS que llega al navegador es un token de administración que tienen tus visitantes.
A GrapesJS no le importa si el otro extremo es REST, GraphQL o algo que haya inventado tu equipo. Un adaptador de almacenamiento es una función de carga y una función de almacenamiento, y todo lo que hay debajo es una elección que tomas dentro de ellos.
Lo que el adaptador tiene que cubrir
Recupera el documento almacenado de una página y entrégalo al editor al inicio.
Escríbelo de vuelta, idealmente como una actualización de un borrador en lugar de una entrada publicada.
Ahorra un recuento de cambios o un temporizador, y haz que el endpoint tolere ser llamado con frecuencia.
Sube a través de tu canal de medios y devuelve la URL que debería mostrar el gestor de recursos.
Expone el borrador a tu frontend detrás de un token, y a nadie más.
Un punto final separado y autorizado. Nunca es la misma llamada que un guardado.
// A storage adapter is just two functions, so GraphQL needs no extra plugin.
editor.Storage.add('cms', {
async load() {
const res = await gql(`query Page($id: ID!) { page(id: $id) { project } }`);
return res.page.project;
},
async store(data) {
await gql(`mutation Save($id: ID!, $project: JSON!) {
updatePage(id: $id, data: { project: $project }) { id }
}`, { project: data });
},
});No se publica ningún paquete adaptador GraphQL en GJS.Market — el fragmento anterior es toda la integración, por eso no se necesita ninguno.
Dos funciones son todo el contrato entre un editor visual y una API de contenido.
La lista que un equipo recorre entre un prototipo funcional y algo que los clientes tocan. Nada aquí es exótico; todo se omite al menos una vez.
Un editor visual es una ruta de escritura hacia tu infraestructura de contenido, por lo que hereda todas las reglas que esa ruta ya tenía — y añade subidas de archivos y marcado arbitrario a la superficie.
Cada carga, guardado, subido y publicación se comprueba con la sesión, para esa página específica, en el servidor.
Alcance por tenant en la propia consulta de la base de datos. Un filtro aplicado tras la lectura no es aislamiento.
El editor utiliza la sesión que emitió tu CMS. Ningún token de gestión o administrador pertenece al código del navegador.
Comprueba el tipo, tamaño y destino en el lado del servidor, y sirve el contenido de usuario desde un origen separado donde puedas.
Los editores pueden colocar código personalizado. Decide deliberadamente quién puede hacerlo y limpia lo que se muestra a los visitantes.
Un endpoint separado con su propia comprobación de permisos, así que poder editar no es lo mismo que poder publicar.
Nunca te bases únicamente en permisos del lado del cliente. Ocultar un panel es una decisión de la interfaz de usuario, no un control de seguridad.
El runtime del editor es una herramienta de desarrollo y solo pertenece a la ruta de edición. Casi todos los problemas de rendimiento en esta arquitectura provienen de dejar que se filtre en las páginas que cargan los visitantes.
Importarla en la ruta de edición. Nada en una página orientada al visitante necesita el paquete de edición.
Una biblioteca multimedia crece sin límite. Paginala y búscala en el lado del servidor en vez de cargarla entera.
Cada plugin registra componentes, comandos y paneles al inicio. Los que no se usan consumen tiempo en cada apertura.
La salida publicada debería ser marcado y estilos renderizados por tu frontend, sin que se incluya código de editor.
El API de entrega puede almacenarse en caché completamente; el borrador leído detrás de la vista previa normalmente no puede. Trátalos por separado.
Aquí no se citan tiempos porque no se han medido para esta página. Mide tu propio editor con tu propio conjunto de bloques — la biblioteca de bloques y el número de recursos dominan los números.
Cinco formas recurrentes. Plantean diferentes preguntas sobre la misma arquitectura, y cada una tiene aquí una página que responde a la suya propia.
Añadir edición visual a un producto que ya tiene clientes, cuentas y facturación.
Creadores de páginas SaaSOfrecer a los clientes una mejor experiencia de edición además de un contenido ya existente.
Creadores de marca blancaConstruyendo un entorno de edición personalizado por cliente, en el CMS que ese cliente ya ejecute.
Servicios de implementaciónPermitir que los profesionales del marketing compongan páginas sin un desarrollador, dentro de una biblioteca de bloques controlada.
Creadores de landing pagesCrear flujos de trabajo de publicación controlados donde quién aprobó qué debe ser responsable.
Editores embebidosServicios
¿Necesitas ayuda para integrar GrapesJS con Strapi, Contentful, Sanity, Directus, Payload o un CMS propio? Te ayudamos con la integración del editor, componentes personalizados, almacenamiento, plugins y flujos de trabajo de producción.
Mantén tu CMS existente, el modelo de contenido y la arquitectura frontend. Añade GrapesJS como capa de edición visual y luego amplíalo con plugins GJS.Market a medida que tu producto crezca.
Cuéntanos el CMS, el modelo de contenido y las páginas que tu equipo necesita componer, y vuelve a tener una configuración con alcance.
EmpezarAlmacenamiento, bloques, plantillas, recursos, formularios, SEO, exportación y publicación — los peldaños que no tienes que escribir.
Explorar pluginsIntegración, componentes personalizados, adaptadores de almacenamiento y el flujo de trabajo de producción que los rodea.
Busca ayuda para implementarTu CMS. Tu frontend. Tu editor.