Every GrapesJS project starts the same way. You mount the editor, drag a block onto the canvas, and it works on the first afternoon. That part is genuinely easy — the editor is a good piece of software and it does what it says.
Then the questions start. Where do pages live? How does a second user get an account? What doespublishactually mean? What servesacme.coand where does its certificate come from? Where do form submissions go? Four weeks later you have not written a single feature that a customer would notice, and you have built an application that has almost nothing to do with GrapesJS.
That application is what we packaged. PageKit is a production Next.js app wrapped around the open-source GrapesJS core: auth, workspaces, multi-tenant projects, page storage, a publish pipeline, custom domains, lead capture, checkout and a plugin loader. It ships as source under a one-time licence, you host it yourself, and you can change any line of it.
It is at v0.1.0, pre-release, and the waitlist is open at pagekit.gjs.market.
The editor is the easy half
We keep saying this because it is the whole thesis of the product. Most GrapesJS integrations you can buy today stop where the interesting work begins: one project, one user, publish means "download a ZIP", and domains are your problem.
The half that takes a month is tenancy. One workspace holding many projects, each with its own pages, its own domain, its own publish state. Owner, editor and viewer roles with email invitations and a guard that stops you demoting the last owner. An opt-in review gate so a client's marketing team can edit without being able to publish. Wildcard subdomains through middleware plus custom domains with on-demand TLS, so a new project is reachable over HTTPS without a deploy.
None of that is GrapesJS work. All of it is work you cannot ship without.
Four things that break a GrapesJS integration
If you have integrated the editor before, you have met at least one of these. They are the actual reason a weekend prototype takes a month to become production-ready — and each one shaped the architecture.
1. Project state is not the export.getProjectData()returns what restores an editing session.getHtml()andgetCss()produce what you publish. Store the wrong one and you either ship editor scaffolding to visitors or hand your users a page they can no longer edit. PageKit keeps two separate stores: a project-data column for the session, a publications row for the rendered artifact. Published pages are served from the second and never touch the editor code path — which is also why they never load the editor bundle.
2. The canvas is an iframe.Fonts, CSS resets and any runtime library the rendered content needs must be injected into the frame. Adding them to the host page does nothing at all, which reads as a styling bug and gets debugged in the wrong file for an afternoon. Everything the canvas needs goes throughcanvas.stylesandcanvas.scripts, so what you see while editing is what the published document actually loads.
3. Component script is a serialized string.It executes inside the canvas frame and cannot close over the surrounding scope. A script referencing an imported symbol type-checks cleanly and throws at runtime — invisible until a user drags that component onto a page. Every custom component in PageKit passes its dependencies through script-props, and the rule is enforced in review rather than discovered in production.
4. Custom types must be registered before content loads.Content referencing a type that isn't registered yet quietly degrades to plain elements and permanently loses its behaviour for that session. Nothing errors; the page just gets worse every time it is opened. The plugin loader resolves and registers a project's pluginsbeforethe load path runs, and refuses version-incompatible plugins loudly instead of failing silently inside the canvas.
OSS core
PageKit is built ongrapesjs0.23.5 — the open-source core only. This is a licensing decision before it is a technical one: the commercial Studio SDK carries a per-domain licence that cannot be redistributed to you, which makes it unusable in a product sold as source.
Everything you would expect from a modern editor shell — searchable block palette, layer tree, style manager, traits, device switching, autosave guarded by an optimistic version token so two tabs can't silently overwrite each other — is built on the core API and ships in the source you receive. The editor stays a dependency rather than a fork, so upstream fixes stay upstream.
What's in the box
Nine areas, all built and covered by tests: the editor shell; publishing with cached publications, wildcard subdomains and custom domains; per-page SEO with OG image generation, sitemap and robots; forms with a field builder in the trait panel, honeypot plus optional Turnstile or hCaptcha, and a leads inbox with CSV export; micro-ecommerce with products, cart and checkout behind a payment adapter; the plugin loader with an in-admin gjs.market browser; A/B tests and popups; team roles and approvals; white-label branding with an offline Ed25519 licence check.
Storage, email and payments each sit behind one interface, with sane offline defaults — local filesystem, SMTP, and a test payment provider that lets the full checkout flow run on a laptop with no accounts and no keys. Swap in S3, Resend or Postmark, Stripe or PayPal by supplying credentials.
The repository numbers, which you can run yourself against the source: 19 editor blocks in four categories, six custom component types, 23 database tables across 11 Drizzle migrations, 12 Playwright end-to-end specs, 10 unit suites, and zero GPL dependencies among 16 runtime packages.
Your install ships with a catalogue
The plugin loader is a first-class part of the product, and the gjs.market storefront is built into the admin as a full screen, not a link in a footer. Manifests are Zod-validated, semver ranges are checked against your installed GrapesJS before anything is registered, andnpm run create-pluginscaffolds a new one. Extending an install does not mean forking it.
What isn't built yet
Two things, and we would rather you read this now than discover it after buying.Multi-language pages — per-locale variants and a language switcher block — are designed but not written; there is no i18n code in the repository today. AI copy generation against your own key is also not written, and no AI dependency ships in the current source. Both are on the public roadmap.
Everything else listed above is built and under test.
Running it
Node.js 20+, PostgreSQL 16, and either a VPS with Docker (docker compose upbrings Postgres, the app and Caddy) or Vercel with managed Postgres. Around 1 GB of RAM for the Docker path, and a wildcard DNS record for subdomain routing. Shared hosting will not work — Next.js needs a Node runtime, and we would rather say so here than sell you a refund.
Licensing and early access
One-time, per tier: Developer $199 for a single production project, Agency $449 for up to ten client projects with white-label admin branding, SaaS / Unlimited $899 to run your own hosted product and charge end-users. Twelve months of updates are included with every tier; renew afterwards at 40% of the licence price per year. Because you self-host, you upgrade on your own schedule — updates are never force-applied to a running install.
The licence check verifies an Ed25519-signed token offline with a long grace period. If our licence server disappears entirely, the worst that happens is a dismissible notice in your admin panel. It never blocks the dashboard and never touches a published page.
Early bird:the first 20 buyers get the Agency tier at the Developer price, with lifetime updates.
The waitlist is open now at pagekit.gjs.market — one email at launch, the early-bird bonus, and the roadmap. Nothing else.