PageKit — the self-hosted GrapesJS site builder, sold as source. Get early access
Add a visual drag-and-drop editor to your headless CMS while keeping your existing content API, frontend and infrastructure.
The screen above is a mock-up of the arrangement, drawn in CSS so it costs the page nothing. The editor engine behind it is real and public: open the official GrapesJS demo, drag a section onto the canvas, and you are looking at the same canvas, component tree and style controls your content team would get on top of your own CMS.
The demo runs on grapesjs.com with browser storage. Nothing on it touches your content.
A headless CMS gives your application an API-first content foundation. What it does not always give the people writing the content is a way to see the page while they build it.
Structured fields are excellent for an article, a product record or a settings document. They are a poor fit for a page whose meaning is its layout — a campaign page, a feature tour, a pricing comparison. For those, the people doing the work usually ask for the same short list:
What editors ask for
GrapesJS provides that visual editing layer without forcing you to replace your CMS.
A headless architecture separates content from presentation, which is exactly why it leaves an editing gap: the CMS knows the fields, the frontend knows the rendering, and nothing in between knows the page. Adding a visual editing layer closes that gap without unpicking either side.
Traditional headless CMS
Missing
Headless CMS + GrapesJS
Add visual editing without giving up the headless architecture.
Because each of the three layers is good at something the other two are not, and a visual editing layer is the only one of them that nobody ships for you. Here is who owns what once the editor is in place.
Your headless CMS
The content infrastructure you already run.
GrapesJS
The visual editing layer you are adding.
Your frontend
Unchanged. It keeps everything it owned before.
Keep the architecture. Upgrade the editing experience.
The visual editing experience: canvas, component tree, blocks, style controls, device widths.
Persistence through REST, GraphQL or your own API. A storage adapter is two functions — one that loads, one that saves.
Your existing content infrastructure. It keeps the schema, the media library, the users and the publishing rules it already has.
The delivery API your frontends already read from. Adding an editor adds a writer, not a second source of content.
Any frontend that consumes your CMS API.
One content source. Multiple frontends.
See how the editor embeds into an applicationThe editing layer attaches through the same API your frontend already calls. Whether you are running Strapi, Contentful, Sanity, Directus, Hygraph, Prismic, Payload or a CMS your own team wrote, the integration point is a pair of endpoints that load and save one document.
These platforms can be integrated through their APIs, with the exact implementation depending on the CMS content model and API. GJS.Market does not publish an official integration for most of them, and this page never implies otherwise.
Keep your CMS. Keep your frontend. Add a better visual editor.
The cards below describe the integration surface each platform offers, not a support claim. One of them has a community storage plugin in the GJS.Market catalogue; the rest are integrations you or an implementation partner would build against their published API.
REST · GraphQL
Self-hosted, with content types you define. The editor document usually becomes a JSON field on a page collection type.
REST · GraphQL
Separate delivery and management APIs. The editor writes through the management API; your frontend keeps reading the delivery one.
GROQ · GraphQL
Portable Text and a document store. The editor document sits alongside your existing fields rather than replacing them.
REST · GraphQL
The only platform on this list with a community storage plugin already published on GJS.Market.
View the pluginGraphQL
GraphQL-first, so the adapter is a query and a mutation instead of two URLs.
REST
Slice-based content. Editor blocks map cleanly onto slices when you keep the block set aligned with them.
REST · GraphQL
Code-defined collections, so the field the editor writes to is declared in the same repository as the editor.
REST · GraphQL · custom
Anything that can answer a load request and accept a save request. Two endpoints is the whole contract.
The one CMS-named adapter in the catalogue
Directus Storage is a free, community-published GrapesJS storage plugin extracted from the Silex project. It is a genuinely useful reference for how an adapter is shaped — authentication commands, load, save — but its own listing notes that it targets an older Directus SDK, so treat it as a starting point to read rather than a supported product to drop in.
Directus StorageA visual editor is only useful in a headless setup if what it produces still fits the schema you designed. In GrapesJS, a custom component type declares its own editable traits — and those traits are where your CMS field names go.
Worked example
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' },
],
},
},
});The visual editor should adapt to your content model — not force your CMS to adapt to the editor.
Two representations come out of the same editor, and they answer different questions. One can be reopened for editing; the other can be rendered. Most production setups keep both, in different columns, and that is a design decision rather than a rule.
editor.getProjectData()The component tree, styles, pages and assets as structured data. It is what the editor needs to reconstruct the session exactly as it was left, which is the only representation that survives a second round of editing intact.
Use it when: someone will open this page in the editor again.
editor.getHtml() + editor.getCss()Markup and stylesheet generated from the same tree. It is what a preview iframe, a static export or a publishing pipeline consumes, and it is not reliably re-importable as an editing session.
Use it when: something downstream has to render it without the editor.
Store the representation your editor needs for future editing, and generate the output required by your frontend or publishing pipeline.
The same editing layer, pointed at different parts of your product. Each of these has a page of its own on GJS.Market, because each one raises different questions once you get past the editor itself.
Let content teams create pages visually, with the entries still living in the CMS you already run.
Visual editing, in depthLet marketing teams launch campaigns without a developer in the loop for every layout change.
Landing page buildersCreate pages visually while every piece of content stays in your CMS and every URL stays with your frontend.
Drag & drop buildersGive your own customers a visual editor inside your product, on top of your content API.
SaaS page buildersGive every organisation in your product its own pages, assets and templates behind one editor.
Multi-tenant editorsCustomise the editing experience around your brand so the editor reads as part of your product.
White-label buildersCreate reusable email templates with the same component model and a mail-safe block set.
Email template buildersCompose structured visual documentation pages that still ship through your content API.
Page presetsWhat comes with the engine, what a plugin adds, and what stays your application's job. The distinction matters when you are scoping the work rather than reading a feature list.
GrapesJS ships no CMS, no hosting, no user accounts and no permission model. Those stay with your CMS and your application.
This is not a decision you make once for the whole product. It is a decision you make per content type, and most teams end up running both.
Your CMS's own form-based editing, driven by the schema.
Best for
A canvas, where the arrangement is the content.
Best for
Use structured fields where structure matters. Use visual editing where layout and composition matter.
Editing and publishing are separate events, and a headless setup makes that easy to enforce: the draft document and the published document are different rows, read by different tokens.
The entry exists in your CMS with draft status.
Someone composes the page on the canvas.
Your frontend renders the draft at every device width.
A second person reads the page as visitors will see it.
The approval is recorded by your application, not by the editor.
Your CMS promotes the draft and your frontend revalidates.
Human gate
What a reviewer should be able to switch between
Separate editing from publishing.
This is the benefit you already bought when you chose a headless CMS, and adding a visual editor does not spend it — as long as what the editor writes stays in the content API rather than in a template.
Headless CMS
One content API, read by every channel
Website
Next.js
Mobile
React Native
Application
Nuxt
A headless architecture lets the same content infrastructure serve different frontends.
If the editor is part of a product rather than an internal tool, every customer organisation needs its own pages, assets and templates — and must never see anyone else's.
Your application
The split is enforced here, on the server
Organisation A
Organisation B
Organisation C
GrapesJS provides no multi-tenancy of its own. Tenant isolation, per-tenant branding and publishing rules are your application's responsibility, and every storage call has to be scoped server-side.
If your customers use the editor, it should look like part of your product. The panels, the icon set, the block library and the templates are all configurable, and the surrounding application supplies everything the editor does not.
Roles and permissions are on that list because a branded editor needs them — not because the editor provides them. They are enforced by your backend.
The engine is one rung of the stack. Below is the whole ladder, with an honest label on each rung: what ships in GrapesJS itself, what you can buy or download on GJS.Market, and what remains your own work.
Two rungs are marked as your own work on purpose. The CMS integration is specific to your content model, and the catalogue has no permissions or audit-log plugin — an implementation partner can build both, but no product here will.
Every listing below was checked against the live catalogue and is published and buyable. Prices are read from the marketplace at build time, so what you see is what the listing says today.
Where the project document goes, and what happens when a browser dies before it gets there.
Browse this categoryA free, community-published storage plugin for Directus — the one CMS-named adapter in the catalogue, and a readable model for writing your own.
A storage wrapper for Cloud Firestore when the project document belongs in a hosted document database rather than your CMS.
Browser-side persistence, useful as an offline buffer or for a demo that must run before any API exists.
Autosave and crash recovery. Without it, an unsaved session is gone when the tab closes and your editor gets the blame.
The section library your editors drag from, and the reuse model behind it.
Browse this categoryThe basic block set to start a library from, rather than an empty block panel on day one.
Form inputs, selects, checkboxes and buttons as real components, so a page with a form is still one document.
Reuse one element across pages so a change to a shared section does not have to be repeated by hand.
Register and manage a custom component library without hand-writing the boilerplate for each type.
Multi-page projects, reusable starting points and a media pipeline.
Browse this categoryAdd, rename, duplicate and export pages — the multi-page structure a CMS-backed site needs.
Pre-designed templates your editors can start a page from and then customise.
MJML components compiled live in the canvas, for the email templates a content team will eventually ask for.
Wire the asset manager to Cloudinary instead of the default uploader.
Turning the project document into something a frontend or a host can serve.
Browse this categoryConvert the stored project data into HTML and CSS server-side, which is exactly the step a headless publish needs.
A live accessibility audit and an SEO metadata panel inside the editor, with each finding bound to the component that caused it.
Export the whole project as a zip archive for handover, backup or a static host.
Deploy from inside the editor when the published artefact is a site rather than a CMS entry.
Five starting sets, drawn from the same verified listings. None of them is a bundle you buy in one click — they are the combinations that keep coming up for each kind of product.
Blocks, templates, a form component and an SEO panel — enough for a team shipping campaign pages without a developer.
Multi-page projects, hosted storage, autosave and reusable symbols — the set that matters once the editor has customers in it.
An adapter to read, crash recovery, an accessibility and SEO audit, and server-side rendering of the stored document. Approval and audit trails stay custom work.
Templates, a media pipeline, export and a deploy command — for pages that end up as a site rather than a CMS entry.
Drag & drop buildersMJML components, hosted images and export, for the templates a content team will send rather than publish.
Email template buildersPrices come from the live catalogue at build time. Free listings are marked.
Every capability on the ladder above is buildable. The question is which ones are worth your team's time when a maintained extension already exists.
| Build everything | Extend with plugins |
|---|---|
| More development | Faster implementation |
| More maintenance | Reusable extensions |
| Build every feature | Add only what you need |
| Internal tooling | Ready-made solutions |
Start with the visual editor. Add capabilities as your product grows.
Not a vendor comparison — a scope comparison. Each row is a subsystem a visual editor needs, and the only question is whether your team writes it.
| Capability | From scratch | GrapesJS |
|---|---|---|
| Canvas | Build | Included |
| Drag & drop | Build | Included |
| Components | Build | Included |
| Blocks | Build | Extensible |
| Styling | Build | Included |
| Responsive editing | Build | Included |
| Layers | Build | Included |
| Assets | Build | Extensible |
| Templates | Build | Extensible |
| Storage | Build | Extensible |
| Export | Build | Extensible |
"Extensible" means the subsystem exists and has an extension point — the block set, template library, asset backend, storage target and export format are yours to supply, from the catalogue or your own code. Catalogue claims verified 2026-09-03.
Build your CMS product. Don't rebuild the visual editor engine.
Often you should. A built-in editor is already integrated, already permissioned and already familiar, and for structured content it is usually the right answer. A dedicated visual editing layer earns its place when you need things the built-in editor was not built to do:
This is not a claim that built-in editors are inferior. It is a claim that the editing surface and the content infrastructure are separable decisions.
Keep your CMS. Choose your own editing experience.
Define your content model
Decide what the editor is allowed to create, and which existing content types it writes into. This decision constrains every one that follows, so make it before any editor code is written.
Configure GrapesJS
Set up the component types, the block library and the style controls your editors get — and, just as importantly, the ones they don't.
Connect storage
Persist the project document through REST, GraphQL or your own API, with authentication carried by the session your CMS already issues.
Build preview
Render the draft with your real frontend, at a route only an authenticated reviewer can reach. Anything else is a preview of a different site.
Add publishing
Connect draft, review and production states to the workflow your CMS already has, and record who approved what in your application.
The smallest editor that talks to a content API. Two endpoints, one autosave policy, and the two calls that give you each representation.
-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() };Send the session your CMS already issued. A CMS admin token that reaches the browser is a CMS admin token your visitors have.
GrapesJS does not care whether the other end is REST, GraphQL or something your team invented. A storage adapter is a load function and a store function, and everything below is a choice you make inside them.
What the adapter has to cover
Fetch the stored document for one page and hand it to the editor at start-up.
Write it back, ideally as an update to a draft rather than to the published entry.
Save on a change count or a timer, and make the endpoint tolerate being called often.
Upload through your media pipeline and return the URL the asset manager should show.
Expose the draft to your frontend behind a token, and to nobody else.
A separate, authorised endpoint. Never the same call as a save.
// 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 GraphQL adapter package is published on GJS.Market — the snippet above is the whole integration, which is why none is needed.
Two functions is the entire contract between a visual editor and a content API.
The list a team works through between a working prototype and something customers touch. Nothing here is exotic; all of it is skipped at least once.
A visual editor is a write path into your content infrastructure, so it inherits every rule that path already had — and adds file uploads and arbitrary markup to the surface.
Every load, save, upload and publish is checked against the session, for that specific page, on the server.
Scope by tenant in the database query itself. A filter applied after the read is not isolation.
The editor uses the session your CMS issued. No management or admin token belongs in browser code.
Check type, size and destination server-side, and serve user media from a separate origin where you can.
Editors can place custom code. Decide deliberately who may, and sanitise what is rendered to visitors.
A separate endpoint with its own permission check, so being able to edit is not the same as being able to publish.
Never rely only on client-side permissions. Hiding a panel is a user-interface decision, not a security control.
The editor runtime is a developer tool and belongs on the editing route only. Almost every performance problem in this architecture comes from letting it leak into the pages visitors load.
Import it on the editing route. Nothing about a visitor-facing page needs the editing bundle.
A media library grows without limit. Paginate and search it server-side instead of loading it whole.
Each plugin registers components, commands and panels at start-up. Unused ones cost time on every open.
Published output should be markup and styles rendered by your frontend, with no editor code shipped.
The delivery API can be cached hard; the draft read behind preview usually cannot. Treat them separately.
No timings are quoted here because none have been measured for this page. Measure your own editor with your own block set — the block library and asset count dominate the numbers.
Five recurring shapes. They ask different questions of the same architecture, and each one has a page here that answers its own.
Adding visual editing to a product that already has customers, accounts and billing.
SaaS page buildersGiving customers a better editing experience on top of an existing content API.
White-label buildersBuilding a custom editing environment per client, on whichever CMS that client already runs.
Implementation servicesLetting marketers compose pages without a developer, inside a controlled block library.
Landing page buildersBuilding controlled publishing workflows where who approved what has to be answerable.
Embedded editorsServices
Need help integrating GrapesJS with Strapi, Contentful, Sanity, Directus, Payload or a custom CMS? Get help with editor integration, custom components, storage, plugins and production workflows.
Keep your existing CMS, content model and frontend architecture. Add GrapesJS as the visual editing layer, then extend it with GJS.Market plugins as your product grows.
Tell us the CMS, the content model and the pages your team needs to compose, and get a scoped setup back.
Get StartedStorage, blocks, templates, assets, forms, SEO, export and publishing — the rungs you do not have to write.
Browse pluginsIntegration, custom components, storage adapters and the production workflow around them.
Get implementation helpYour CMS. Your frontend. Your editor.