Which open-source option replaces the Storyblok Visual Editor?
For a marketing team that chose Storyblok for in-context editing, the closest self-hosted fit is usually Payload's live preview and block layout builder when the front end is Next.js. Drupal Canvas, the visual page builder in Drupal CMS, suits teams that already run Drupal. Neither product copies the Storyblok visual editor out of the box, so editing parity is not automatic: developers must engineer the preview, and the effort depends on how your front end renders content. A renewal, a price change or a residency requirement is a sound moment to test that work on one landing page before committing to a migration.
Licensing is the simplest part of the comparison. Payload is MIT licensed and installs directly into an existing Next.js /app folder, so there is no license fee to pay, and your costs shift to hosting, the database and development time. Drupal and its contributed modules are GPL-2.0-or-later, and there is no paid edition of Drupal itself, though Drupal CMS is a distribution built on Drupal core that you still host yourself. Storyblok is a hosted SaaS product, so its terms come from your contract. Confirm in writing which editing features your plan includes, including whether the visual editor and preview are covered at your tier.
Before choosing, have developers confirm three things: the preview route in the Next.js app that reads draft content, the blocks editors will place on pages and the components that render them, and who will maintain that code after launch. Payload supports versions and drafts, so previews can show unpublished changes, but connecting the preview to your front end is project work. Ask the team to build one page with two blocks, including one localized block and one with an image, then have an editor judge the experience. Expect differences in editor ergonomics and in-context click-to-edit behavior, and confirm both against current Payload and Drupal Canvas documentation before assuming parity with Storyblok.
How Storyblok visual editing capabilities map to open-source options
This table maps each Storyblok visual editing capability to what Payload and Drupal Canvas provide out of the box and what your team must build or confirm. Read the middle column first for built-in coverage, then the last column for the work that falls to your developers and editors. The main takeaway is that Payload covers the content side well, while click-to-edit overlay behavior is a custom build on either platform.
| Storyblok capability | Payload built-in coverage | Gap or build work |
|---|---|---|
| Nestable components | Block-based layout builder with blocks defined in code and nested within layouts | Confirm nesting depth and editor limits against your block design before migrating |
| Click-to-edit in preview | Live preview renders the front end inside the admin panel | No Storyblok-style click-to-edit overlay is included; developers must add element-to-field mapping in the Next.js front end |
| Component presets | Blocks and default values can be defined in code, with the customizable React admin panel for editor-facing choices | Presets that editors save themselves are not a listed built-in feature; plan a custom admin component or a shared block library |
| Draft and publish | Versions and drafts are built in | Confirm how scheduled publishing and preview of drafts behave for your workflow |
| Localization in the editor | Localization is a built-in feature | Translators' views, per-locale workflows and fallback rules usually need configuration and testing |
| Roles and permissions | Built-in authentication and field-level access control, with admin and customer users managed in the CMS | Editorial roles such as approver or translator must be modeled in access rules and hooks |
| Rich text editing | Lexical rich text editor | Confirm that inline components and custom embeds match what your editors used in Storyblok |
| Workflow and approvals | Hooks can run logic on document and field events | Approval steps and notifications are not listed as built in and must be built and tested |
| Visual page building for marketers | Drupal Canvas is a visual page builder in Drupal CMS, a separate option from Payload | Confirm Drupal Canvas component coverage against the Drupal CMS page before choosing it over Payload |
When Payload or Drupal Canvas fits better
Payload is the closer fit when your front end is, or will be, a Next.js application. It is MIT licensed and installs directly into an existing Next.js /app folder, so the admin panel, the API and the page code share one repository and one deployment. Its block-based layout builder and live preview give editors a route to in-context editing, but the preview is something your developers build and maintain, not a feature that arrives configured.
- Preview wiring is custom work: developers connect the live preview to each front-end route, define how draft content renders, and keep that mapping current as blocks change.
- Database choice is yours: Payload supports MongoDB, PostgreSQL and SQLite, so your database team picks the engine and runs its backups.
- Types come from code: TypeScript types are generated from collections and fields, which helps when the front end and the schema change together.
- Hosting is flexible: Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted anywhere.
- Built-in authentication: admin and customer users can be managed in the CMS itself, which reduces one integration but still needs a review against your identity policy.
Confirm with your developers that they can own preview routing and upgrades of the Payload version you choose. Payload v3.91.0 was released on October 15, 2026, and a v4.0.0 beta line is in progress, so plan which major version you will run.
Drupal CMS is the stronger option when your organization already runs Drupal or has PHP and Drupal operations skills. Drupal CMS 2.0 is a distribution built on Drupal core for marketers and content teams, with recipes, site templates, the Drupal Canvas visual page builder (previously Experience Builder) and optional AI tools. Drupal and its contributed projects are GPL-2.0-or-later, and there is no paid edition of Drupal itself, so the cost is in hosting, people and support contracts.
- Canvas is a page builder: editors compose pages visually, but its scope and maturity for your component library should be tested against your current Storyblok bloks.
- PHP stack is required: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later.
- Upgrade cadence is fixed: Drupal 12 is scheduled for the week of December 7, 2026, Drupal 10 reaches end of life on December 9, 2026, and new major versions typically arrive every three years.
- Identity integration exists: the contributed SAML Authentication and OpenID Connect modules cover common enterprise sign-in.
- Security releases are monthly rhythm: bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, which your operations team must absorb.
Before committing, ask a Drupal partner to test Canvas against a representative Storyblok page and confirm which Drupal version your upgrade path will target.
Strapi is a common third choice, but this page does not treat it as a full option because it has its own comparison page. Strapi is open core: its Community Edition is MIT licensed, while code in its ee/ directories falls under the Strapi Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. That split matters for a regulated buyer reviewing license scope, and it should be checked before you build on any enterprise-only feature.
- Licensing scope: confirm which features you need sit in the Community Edition.
- Visual editing gap: Strapi does not offer the same in-context editing model as Storyblok, so compare the editor experience directly.
- Developer ownership: preview and frontend wiring carry the same custom work as Payload.
- Read the sibling page: the Storyblok vs Strapi comparison covers content types, dynamic zones and delivery in detail.
For licensing questions, use the Strapi LICENSE file as the starting reference and confirm your feature list with the vendor.
What developers must build before preview works for editors
Visual preview in a self-hosted stack is not a checkbox. Before an editor can see a draft in context, your team must build a front-end route that renders draft versions of entries, a preview secret that gates entry into draft mode, and an authenticated draft mode that the route can switch on and off. Payload's live preview is configured per collection through its admin settings, and it expects a preview URL that your Next.js app resolves for each document. Your developers then wire a live preview endpoint to the same block components the public site uses, so that a hero or pricingTable block renders identically in preview and in production. Each piece is ordinary code, but none of it arrives ready-made for your brand's layouts.
Localization adds a second layer. Each locale needs its own preview URL pattern, and the route must pass the locale and the document ID through to the query that loads draft content, otherwise editors will preview the default language while editing a French version. Storyblok's built-in click-to-edit overlay has no drop-in equivalent here. Payload gives you the hooks and the admin panel, but the click-to-select behavior on rendered blocks, the highlighting of the field that was clicked and the mapping from a DOM element back to a block and field are work your team designs and tests. Confirm each of these behaviors with Payload's current documentation and a working prototype before committing to a timeline, and test them with real editors on your heaviest page templates.
Treat the preview build as a deliverable with its own acceptance tests. Check that draft content never leaks into public routes, that the preview secret rotates and expires, that draft mode turns off cleanly, and that preview works through your CDN and any edge caching layer. Ask your implementation partner to show these checks in writing, and to document which editor actions still require a full page reload. Keep a short list of known gaps, such as drag-and-drop reordering that the preview may not reflect immediately, so editors are not surprised on launch day.
Where editors will notice the difference
Moving from Storyblok's visual editor to a code-defined stack changes daily editing work, not just the back end. The cards below cover the places where editors tend to notice the change first, so the team can test each one with real editors before cutover.
Fewer ready-made editor affordances
Storyblok ships with a visual editor that editors use without setup. In Payload, the block layout builder and live preview are building blocks, so features such as inline component reordering, bulk actions and asset pickers depend on what your team builds or configures. Ask editors to list the five actions they perform most often in Storyblok, then check each one in the new admin panel before signing off on scope.
Custom admin panel work
Payload's admin panel is React and customizable, so field labels, grouping, help text and custom components become code your team maintains. Editors will see whatever the developers ship, which means every admin change needs a review step with the content team. Test a sample page with real field labels and confirm that editors can find each field without asking for help.
Versions and drafts behavior
Payload supports versions and drafts as built-in features, but how a draft previews, publishes and reverts depends on how collections are configured. Storyblok users often expect a publish step that works the same way across every story, so confirm the publish, schedule and restore flows with editors. Run a test where an editor saves a draft, a reviewer edits it and the page is published, then reverts it.
Localized previews
Payload supports localization, and live preview can render a page in a chosen locale, but editors must see the correct language, fallback content and missing-translation states on the same preview screen. Ask translators to edit a page in a second locale and check that the preview shows their text, not the default language. Confirm the fallback behavior with the content team before launch.
Role setup done in code
In a self-hosted Payload project, access control is defined in code through collection and field access functions, so changing who can edit a component means a code change and a deployment. Storyblok roles are often changed by content leads directly in the admin. Document each role with its allowed collections and actions, then have an editor test that a restricted user cannot see or publish content outside their scope.
Training on a new interface
Even a close match to the old workflow will feel different, and editors will spend the first weeks finding where things moved. Plan short sessions built around the team's own pages and publishing tasks, and keep a one-page guide for the actions that changed. Track which tasks still take longer than in Storyblok during a pilot period, and decide which gaps to fix before the rest of the team moves.
How much work and cost does replacing Storyblok's visual editor take?
What are the main cost drivers when replacing Storyblok's visual editor?
The biggest cost drivers are developer time to build live preview, the work of migrating and remodeling components, and the hosting and database you will run yourself. Storyblok's visual editor is hosted for you, so with Payload or Strapi these costs move onto your team or your implementation partner's scope. Hosting and the database recur every month, while preview development, schema translation and editor training are mostly one-time. Ask any quote to split these lines out: preview build, component schema mapping, asset and content import, hosting and database setup, and ongoing maintenance. Compare that total with your current Storyblok plan, seat, locale and API request charges over the same period.
Can our marketing editors be trained in-house on the new editing workflow?
Often yes, but the answer depends on how much in-context editing your editors rely on today. Payload's admin panel and block-based layout builder are learnable for content teams, yet live preview is a developer-built feature, so editors will not see the same click-to-edit behavior Storyblok provides out of the box unless someone builds it. Plan training around the blocks your editors actually use, the preview route each block needs, and how drafts and publishing work. Confirm with your implementation partner exactly which editing behaviors are delivered and which are left for your team to refine after launch.
How long does a Storyblok to Payload visual editor migration usually take?
The duration depends mainly on how many components and content types you have, how many locales need content and preview, and how much of your front end must be rebuilt to render live preview. No supplied figure sets a timeline for this work, so ask for one only after a schema inventory. A small set of components with one locale is a very different project from dozens of nested components across several languages. Ask the partner to state the milestones in writing, including the schema inventory, preview build, content import, editor acceptance and cutover, so the scope and timeline can be agreed before work starts.
What must our team provide before an implementation partner can start?
Your team needs to supply a complete schema inventory, a list of every component, its fields, its nesting and where it appears on the site. You also need editor access to Storyblok so the partner can review how content is actually created, and a staging environment where preview and imports can be tested without touching production. Provide the front end repository, hosting accounts, and the names of the people who approve editorial sign-off. Missing any of these usually moves work into discovery and changes the scope, so agree on the list in writing before kickoff.
Does the Drupal 12 release timing affect a visual editor migration?
It matters only if Drupal is part of your shortlist for the visual editor. The Drupal core release schedule places Drupal 12 in the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Drupal Canvas, the visual page builder in Drupal CMS, is a separate evaluation from Payload's live preview, so confirm its current status and fit with your editors before choosing it. If you move to Drupal, plan for a supported major version and check the PHP requirements for that version, since Drupal 12 requires PHP 8.5 or later.
Is a fixed-scope engagement a good fit for this kind of replacement?
A fixed-scope engagement fits well when the schema inventory, locales and preview requirements are clear enough to write down. DeployOpen plans, implements, customizes and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. If editing needs are still uncertain, start with a discovery phase that produces the inventory and a written scope, then decide on the build. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.
Can we do this replacement ourselves without an outside partner?
Yes, if your team has developers comfortable with Next.js, TypeScript and a database, and enough time to build live preview and rebuild components. Payload's MIT license means no license fee applies to the software itself, and you own the code. The work that usually surprises internal teams is preview wiring, asset and rich text import, and the upkeep of hosting, backups and upgrades after launch. Estimate the time your developers can give over the coming months, and ask whether a partner would take on specific parts, such as the import scripts or hardening, while your team keeps ownership of the editorial experience.
Moving stories, components and editors without losing the visual workflow
This sequence moves Storyblok content into a self-hosted CMS while keeping editors on a visual, preview-driven workflow. Each step ends with a check that tells the team whether it can move on. Roles and workflows are rebuilt by hand, so they get their own step and a pilot before cutover.
Inventory components, presets and editor habits
The content lead and a developer list every Storyblok component, its groups, nestable children, presets and the datasources they rely on. They also note which pages editors build most often and which blocks they reuse across pages. Storyblok's export guide describes what the CLI can pull, so the inventory should match that scope. The step is done when the team has a written component map that lists each block, its fields and the pages that use it.
Export stories and assets with the Storyblok CLI
A developer runs the Storyblok CLI against the source space to pull stories, components, datasources, languages and assets, following the steps in the export guide. Roles, workflows and any scheduled publishing settings are not carried over, so the team records them separately before the export. The step is done when the export files are stored in a version-controlled or access-restricted location and a sample of stories and asset files opens correctly.
Rebuild components as Payload blocks or Drupal Canvas components
Developers translate each component map entry into a Payload block inside a collection, with fields defined in TypeScript, or into a Drupal Canvas component if the team has chosen Drupal. Nestable Storyblok components usually become blocks with nested fields, and presets become default values or templates. The team confirms the target platform's current support for its block features before committing to a design. The step is done when every component in the inventory has a matching block or component and a review sign-off from the editors who use it.
Import content, locales and assets
Developers write import scripts that map exported stories to collections, convert rich text into the target editor format, recreate locales and upload assets to the new storage. Each import runs first against a staging database. The step is done when record counts match the export, sample pages render with their images and translated versions appear under the correct locale.
Rebuild preview routes and secrets
Developers implement draft and preview routes in the Next.js application, configure live preview for each block-driven page, and set preview secrets through the team's secret manager rather than in code. Editors must be able to open a draft from the admin panel and see changes in context, which is the main visual workflow Storyblok users depend on. The team confirms the preview behaves the same for each locale and that unpublished content is not visible on public routes. The step is done when a test editor can edit a draft and see it in the page layout.
Recreate roles, permissions and approval steps
Because roles and workflows do not come across in the export, an administrator recreates each role and its access rules in the new CMS. The security or content governance lead checks that each role grants only the editing, publishing and translation rights the business approved. The step is done when a written role matrix matches the test accounts, and a reviewer has confirmed that restricted content cannot be reached by the wrong group.
Test with a pilot group of editors
A small group of editors who use the Storyblok visual editor daily works in the new system on staging for a fixed period agreed by the project team. They build and publish real pages, use localization and check preview on mobile and desktop layouts. The team logs every gap, such as missing field types, slow preview or differences in how blocks are reordered, and the developers fix them before cutover. The step is done when the pilot group signs off on a list of known differences and every blocking issue has a fix.
Cut over and retire the Storyblok space
The team freezes publishing in Storyblok, runs a final export and import, updates DNS or routing, and switches editors to the new admin panel. The Storyblok space stays read-only for an agreed retention period so the team can compare content if a question comes up. The step is done when public pages serve from the new platform, editors can publish from it and the final export has been archived.
What can go wrong with editors and content during the move
The most damaging failures are the ones editors notice only after launch. Layout nesting is the first risk to check. Storyblok's nestable components let editors place blocks inside blocks, and a flat or partially nested import into Payload's block-based layout builder can silently drop or reorder children. Rich text is the second risk: Storyblok's rich text fields are stored as structured JSON, and converting them into Payload's Lexical editor can lose custom marks, embedded components, links and table formatting. Asset URLs are the third. Any stored link that still points at Storyblok's asset host will break once the space is retired, so the team should confirm whether the Storyblok export includes asset files and whether every reference has been rewritten to the new storage location.
Drafts are the risk editors are least prepared for. Storyblok's draft and published states do not map automatically onto Payload's versions and drafts, and a preview that reads the draft while the live site reads the published version will show content that never reaches visitors. Build a checklist that compares, for a representative set of pages in each locale, the live preview, the draft state and the published render. Include pages with scheduled releases, pages with nested blocks, pages using shared or global content, and pages with localized assets. Confirm export completeness against the Storyblok export guide before any import, and record what was not carried over, such as roles, workflows and any preset configuration, so editors know what must be rebuilt by hand.
Plan a parallel run before Storyblok is retired. For an agreed period, keep both systems current for a small editorial group, have editors publish the same changes in each, and compare the rendered output. Track every mismatch in a defect log with its root cause, and do not close the migration until the team has agreed the exit criteria in writing. The length of the parallel run is a decision for the organization, based on release frequency and the number of locales, and should be confirmed with the implementation partner before the work is scoped.
Trade-offs to weigh before choosing an open-source editor
Each card is a decision with a test you can run before committing. Together they show what changes when editing moves from a managed Storyblok space to software your team hosts and maintains. Use them to decide whether Payload or Drupal Canvas fits your editors, developers and operating model.
Who runs the hosting
Storyblok's hosting, uptime work and upgrades sit with the vendor. With Payload, the preview server, database, CDN and backups belong to you or your partner, so the editing experience depends on your infrastructure. Test: write down who gets paged when preview is down at 9 a.m. on a launch day, and confirm that person exists before you migrate.
Developer dependency for editor changes
In Storyblok, a marketer can often adjust component fields in the UI. In Payload, new blocks, fields and preview layouts are code-defined in TypeScript and deployed through your pipeline. Test: list the five most common editor requests from the last quarter and mark which ones need a developer. If most do, budget for that ongoing work.
Pre-release Payload v4 or stable v3
The stable Payload line is v3.91.0, released on October 15, 2026. A v4.0.0 beta line is in progress, with v4.0.0-beta.2 published on October 16, 2026. A beta is not a supported production release for most teams. Test: start on the stable line and confirm your preview, plugin and upgrade path against the release notes before any beta adoption.
Drupal PHP version requirements
Drupal Canvas sits inside Drupal CMS, and each Drupal major version sets its own PHP floor. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. Test: check your current PHP runtime and hosting image against the target Drupal version, and confirm that every contributed module you need supports it.
Loss of managed uptime and support
Storyblok's managed service removes the need to run a preview environment, patch the CMS or handle database failover yourself. Self-hosting shifts those duties to your team or a support retainer. Test: compare the uptime and response commitments in your current Storyblok contract with what your own on-call rota and your implementation partner's written support scope will actually cover.
Licensing and what open source does and does not give you
The first thing to settle is which license governs the code you will run, because the three realistic options differ. Payload is MIT licensed, so you can install it in your own Next.js application, modify it and run it for internal or commercial sites without a license fee to the Payload project. Drupal and its contributed modules are licensed under GPL version 2 or later, and there is no paid edition of Drupal itself, so the software cost is zero but any Drupal module or theme you distribute beyond your own organization carries GPL obligations. Strapi is open core: its Community Edition is MIT, but code in the ee/ directories is under the Strapi Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Check the Strapi LICENSE file and your own feature list before you assume every component is free to use.
Open source gives you the right to run, change and host the software, but it does not give you support, indemnity, a service level or a roadmap commitment. The GPL does not require you to publish code that is used only to run a website, which matters for a marketing team that customizes the preview and editor experience privately. It does apply when you distribute a modified Drupal module or theme to another party, and it is a separate question for a proprietary Payload plugin or Strapi enterprise feature. Ask the vendor or community which components they rely on, and document the license of every package in the build.
Because these terms interact with your contracts, your procurement rules and your data processing obligations, have your legal counsel review how your organization will use the chosen software before the migration starts. Ask counsel to confirm the Storyblok contract terms you are leaving, any restrictions on exporting content, and whether any enterprise component is needed for the visual features you expect to keep. This review is a one-time cost, but it should be repeated when you upgrade major versions or add paid extensions.
How DeployOpen scopes and delivers a visual editor replacement
This sequence turns a Storyblok visual editing workflow into a scoped, tested and documented preview setup in your own environment, with editors trained to use it before the work is closed.
Inventory the editing workflow and content model
DeployOpen reviews which pages, components and editorial roles depend on in-context editing, which locales are in use and which Storyblok components are actually edited visually. The team also confirms which features the replacement must match, such as drafts, scheduled publishing and preview links for reviewers. The output is a written inventory that lists every page template and component in scope, with the editing behavior each one needs. You know this step is done when the client has signed off on that list.
Agree the scope and deliverables in writing
Before any build work, DeployOpen and the client agree a fixed scope that names the target platform, the preview architecture, the hosting location, the training sessions and the acceptance tests. Cost components are clarified at this stage: the client carries hosting, database, CDN and any internal staff time, while DeployOpen's fee follows from the written scope. The output is a signed scope document with explicit exclusions, such as any content migration or personalization rebuild that is handled under a separate statement of work. The step closes when both parties have approved the document.
Build the preview path inside your environment
Engineers implement live preview in the client's own cloud account or data center, typically inside the frontend application that renders the pages. This includes the preview route, draft fetching, authentication for editors and the mapping between block types and the front-end components they render. Work is done in the client's repositories and pipelines so the code remains theirs. The output is a working preview environment that an editor can open from the CMS admin panel. The step is complete when a sample page renders unpublished changes through that route.
Test preview and the editing paths
DeployOpen tests the preview across the page templates from the inventory, including localized variants, nested layouts and assets. Testing covers access control, so that draft content is visible only to authorized users, and checks how the preview behaves after publish and unpublish. Known gaps against the previous Storyblok workflow are recorded, such as any difference in inline editing or how fields are highlighted. The output is a test report with each failed case, its owner and its resolution. The step closes when the agreed acceptance tests pass.
Harden the editor access and deployment
The team configures editor roles, single sign-on where the client requires it, secrets handling for preview tokens and deployment pipelines that separate preview from production. Logs, backups and rollback steps for the CMS and its database are documented so the client's operations team can run them. The output is a hardening checklist and a deployment runbook stored in the client's repositories. The step is complete when the client's security reviewer has confirmed the configuration matches the approved design.
Train editors and hand over the workflow
DeployOpen runs training sessions for editors and reviewers on the new preview, publishing and scheduling flow, using the client's own pages as examples. Editors are shown where the replacement differs from Storyblok, so expectations are set before go-live. The client's team receives written guides and recordings of the sessions. The output is a set of editor guides and a short list of known differences that the marketing team has accepted. The step closes when the agreed sessions have been delivered and the handover checklist is signed.
Support upgrades through an optional retainer
After handover, the client can choose a retainer that covers upgrades of the CMS, its framework and preview dependencies, along with security patch review and periodic re-testing of the editing flow. Retainer scope, response expectations and fees are set out in writing, and the client's internal staff time is treated as a separate cost. The output is a documented upgrade calendar and a test suite the client can rerun. The step is complete when the retainer terms are signed or the client confirms it will maintain the platform itself.
