Storyblok alternative: when to keep Storyblok and when Payload fits
Keep Storyblok if your editors depend on its hosted visual editing and your organization prefers that the vendor runs the platform, hosting, upgrades and availability included. Move toward Payload if you have Next.js developers who can own the codebase, you want MIT-licensed code you can inspect and run, and data location or per-seat and per-locale pricing is now the constraint driving the decision. A renewal, a seat or locale increase, or a residency requirement is the usual trigger, but none of these settles the question by itself.
Payload fits teams whose front end is already Next.js. It installs directly into an existing /app folder, supports self-hosted MongoDB, PostgreSQL and SQLite, and gives you a block-based layout builder, localization, versions and drafts, and live preview in a React admin panel you can customize. Authentication is built in, so admin and customer users can live in the CMS. What it does not give you is Storyblok's ready-made visual editor on the page. Your team must build the preview wiring, and your editors must accept a different editing workflow. Confirm with a proof of concept that the block layout builder and live preview meet the editing tasks your marketing team performs every week.
The decision turns on four things: how dependent your editors are on visual preview, how much Next.js and TypeScript capacity you can staff for the build and the years after it, where your content must physically reside, and the total cost of running the platform. Storyblok's cost is mostly subscription fees that recur. Payload's cost is mostly one-time migration and build work plus recurring hosting, database, backups, upgrades and on-call effort, which you pay to your own staff or a partner. Ask any quote to separate these components, and ask what each one scales with, including locales, environments and traffic.
Which Storyblok alternative fits each buying scenario
This table matches common buyer situations to the option that usually fits best, based on editor workflow, developer ownership and hosting control. Read each row as a starting point, then test the fit against your own editors, developers and data residency rules before committing.
| Buying scenario | Better fit | Reason |
|---|---|---|
| Marketing team that edits pages visually all day | Storyblok, or Payload with a planned live preview build | Storyblok's visual editor is the core of its product. Payload offers live preview and a block layout builder, but developers must build the preview wiring and editors will see a different experience. |
| Product team with Next.js developers that wants code-defined schemas | Payload | Payload installs directly into a Next.js /app folder and generates TypeScript types from code-defined collections and fields, so schemas sit in the same repository as the front end. |
| Multi-locale organization with strict data residency | Payload or Strapi on infrastructure you control | Self-hosting lets you choose the region and database for content. Confirm locale setup, translation workflow and database hosting with your architects before design, since localization is built into each option differently. |
| Team that mainly needs a content API for a mobile app | Strapi or Payload, depending on developer skills | Both expose content through APIs you own. Strapi suits teams that want a managed admin panel with REST and GraphQL out of the box. Payload suits teams already writing TypeScript for the app backend. |
| Team that wants built-in customer authentication in the CMS | Payload | Payload includes authentication, so admin and customer users can be managed in the CMS itself. Confirm that this model meets your identity architecture before adopting it. |
| Organization that needs a single source of truth for both editors and developers | Payload | Collections, fields and access rules live in code, which suits review through pull requests. Editors work in the admin panel, and developers keep schema changes under version control. |
| Team with no in-house developers for the CMS | Storyblok, or a fixed-scope implementation partner for Payload | Running Payload means maintaining a Next.js application, a database and hosting. Without that capacity, budget for a partner or stay with a hosted product. |
| Organization that already runs its own Next.js and database estate | Payload | The CMS can sit beside existing hosting, database backups and monitoring, so operational tooling is reused instead of added as a separate SaaS dependency. |
How the editor experience differs in practice
Storyblok's visual editor is a feature of the hosted product. An editor opens a story, clicks into components on the page and edits them in context without anyone setting up the editing environment. The team that runs Storyblok does not have to build or maintain that experience, and new editors usually need little more than a login and a role. With Payload, the picture is different. Payload ships an admin panel built in React that you can customize, and a block-based layout builder where editors assemble pages from the blocks your developers defined. Live preview works inside the Next.js app your team builds and maintains, so the preview is only as good as the front end components and preview wiring behind it.
Developers must build the front end components and the preview wiring before editors see changes in context. Each block needs a React component that renders it on the live site, and the preview route must load draft content and refresh when an editor types. Editors will notice the gap most in day-to-day speed. Once blocks and preview exist, editors can publish layout changes without a developer, but any new block type, new field or change to the page template is a development task in your own repository. Confirm with Payload's current documentation what live preview requires for your rendering setup, and treat the preview work as scoped engineering rather than a checkbox.
Test both options with your own editors and a real page before you decide. Pick a landing page that your marketing team updates every month, rebuild it in a Payload prototype with the blocks it actually uses, and time how long an editor takes to make three typical changes, including adding a block, changing a localized field and previewing a draft. Run the same tasks in Storyblok's visual editor with the same editors. Record where they hesitate, which changes still need a developer, and how the preview behaves on mobile. The results will show whether the self-hosted editing model suits your team better than the hosted one.
How Storyblok and Payload compare on capabilities
This table sets Storyblok's hosted headless CMS against Payload, an MIT-licensed CMS that runs inside a Next.js app. Read the Payload column as supplied capabilities and the Storyblok column as areas to confirm with the vendor, since plan limits and terms change. The main takeaway is that Payload gives you code-owned schemas and self-hosting, while Storyblok gives you a managed editor and less operational work.
| Capability | Storyblok | Payload |
|---|---|---|
| Licensing | Commercial SaaS; confirm terms with Storyblok | MIT licensed |
| Hosting model | Vendor-hosted SaaS; data center options depend on plan | Self-hosted anywhere, or deployed to Vercel or Cloudflare Workers |
| Database options | Managed by Storyblok; not customer-selected | MongoDB, PostgreSQL and SQLite, self-hosted |
| Content modeling | Nestable components and content types in the visual schema | Collections and fields defined in TypeScript code |
| Block-based layouts | Nestable components for page building | Block-based layout builder in the admin panel |
| Localization | Available; confirm language limits and add-on costs for your plan | Built-in localization for fields and documents |
| Versions and drafts | Draft and published states; confirm version history depth | Built-in versions and drafts |
| Live preview | Visual editor with in-context preview | Built-in live preview; developers wire it into the Next.js front end |
| Admin and customer authentication | Editor accounts managed in Storyblok; confirm end-user auth options | Built-in authentication for admin and customer users |
| Access control | Roles and permissions per space; confirm granularity | Field-level access control in code |
| TypeScript types | Type generation available through tooling; confirm current support | Generated automatically from collections and fields |
How localization and content models work for each team
Editors work with locales and drafts through the editing interface, so their experience depends on how each platform shows translations, versions and approvals. Storyblok gives editors a visual editor with per-language views and a publish flow controlled by the space's roles and workflow settings. Payload uses its admin panel, where locale switching, drafts and versions are built into each document, and where approval steps are only what your team configures. Both can support a translator-review-publish sequence, but the approval rules are set in different places and need to be built or confirmed.
- Locale switching: Ask each platform how an editor moves between languages on the same entry and whether untranslated fields show a fallback value.
- Drafts and versions: Confirm how a draft in one locale affects the published version in another, and whether editors can schedule publishing per locale.
- Visual context: Storyblok's visual editor shows content in place. Payload's live preview depends on what your developers build, so test it with a real editor before you commit.
- Approval steps: Map who can publish each locale today and check whether that role model carries over without a second workflow tool.
- Permissions: Check whether translators can edit one locale without seeing or changing others.
Before you decide, run a short editor session in each platform using your three most common content types and your two busiest locales.
Developers define the content model, and that choice shapes how localization behaves in production. Payload's localization is configured in code alongside its collections, fields and blocks, so locale settings, field-level translations and layout blocks live in the same repository as the Next.js application. Payload also generates TypeScript types automatically from those code-defined collections and fields, which keeps the front end and the CMS schema in step. Storyblok's components are defined inside its space through its interface, and the front end consumes them through its delivery API.
- Code-defined locales: In Payload, locale configuration is versioned with the application, so reviews and rollbacks cover content model changes too.
- Generated types: Payload's generated TypeScript types catch missing or renamed fields at build time, which reduces surprises when a block changes.
- Blocks and components: Payload's block-based layout builder maps to code, while Storyblok's nestable components are defined in the space and changed there.
- Schema ownership: Decide whether schema changes go through pull requests, which Payload supports naturally, or through the Storyblok interface, which needs its own change control.
- Migration impact: Component and locale schemas must be translated into Payload configuration if you move, so plan that work with your content team.
Ask your developers to prototype one localized block with fallback and preview to see how much of the work lands in code.
Localization and operations leads own the cost and the risk. On hosted Storyblok plans, the number of locales and the number of seats are the main drivers of cost alongside API requests and traffic, so adding a language or a translator can change the bill. Self-hosted Payload removes per-locale and per-seat line items, but the work moves into your own budget: hosting, database administration, testing across locales, and the engineering time to keep builds and previews working as the language count grows. The right comparison is the total cost of your locale plan over the period you expect to run it, not the line items on either pricing page.
- Hosted line items: On Storyblok, ask which locales, seats and API volumes are included in each plan tier and what triggers an add-on.
- Self-hosted costs: On Payload, the recurring costs are your hosting, database, backups, CDN and the people who maintain the locale build and test pipeline.
- Testing effort: Each new locale adds translation review, layout checks and regression tests, which is the largest hidden cost in a self-hosted setup.
- Fallback rules: Confirm how each platform handles fallback between regional and base languages, and whether fallback can be set per field.
- Quote scope: Ask any implementation partner to price locale setup, testing and content migration as separate line items in a fixed-scope written quote.
Confirm your own fallback rules, including which fields may fall back and which must be translated, against each platform's documentation before you rely on either.
Where content, data and identity sit with each option
Storyblok and Payload differ most in where content and user accounts physically live and who controls them. Each card below covers one decision point, from hosting and database choice to backups and the work of leaving, so you can check each claim against your own data residency and compliance requirements.
Hosting model and deployment target
Payload installs directly into a Next.js /app folder and can be self-hosted anywhere, or deployed to Vercel or to Cloudflare Workers with R2 and D1. Your infrastructure team chooses the region, the network and the cloud account. Storyblok stores content in its hosted service, so the operating location of the content is set by the vendor's plan options. Confirm with Storyblok which data regions are available on your plan and whether a dedicated region is part of your contract.
Supported databases
Payload supports MongoDB, PostgreSQL and SQLite, so your database team can run the CMS on a platform they already operate and back up. Storyblok's content store is not something you can choose or host yourself. If your standards require a specific database engine, encryption configuration or replication topology, record those requirements before the proof of concept, because they determine how Payload is provisioned.
Identity inside the CMS
Payload includes built-in authentication, so admin users and customer users can be managed in the CMS itself without a separate identity product. This keeps account data in the same environment as the content. Ask Storyblok how its user roles, single sign-on options and account deprovisioning work on your plan, and whether the identity provider can be connected to your corporate directory.
Data access and logging
For Storyblok, content lives in a hosted service, so your visibility into who accessed what depends on the audit and access logs the vendor provides. Ask Storyblok for its access log retention, the log fields available to you, and whether logs can be exported to your SIEM. With Payload, access logs come from your own web tier, database and hosting platform, so the design of that logging is your decision and should be written down before go-live.
Backups and recovery ownership
With a self-hosted Payload stack, you own the backup schedule, the restore test and the retention period for both the database and the media store. Storyblok's backups are managed by the vendor, so ask what recovery point and recovery time it commits to, and how you would obtain a full copy of your content. Testing a restore on a schedule is the only way to confirm either model works for your recovery targets.
Compliance evidence and exit
A self-hosted stack puts the compliance evidence in your hands: configuration records, access reviews, change logs and backup test results. DeployOpen can prepare the controls and the evidence set, but it does not issue audit reports, and your independent auditor will assess the result. Before choosing a platform, ask Storyblok what export formats and asset files you can take out, and confirm the process with the vendor in writing.
What each option charges for, one-time and recurring
Storyblok bills most of its cost as recurring subscription that grows with plan tier, seats, locales, API usage and traffic. Self-hosted Payload removes the license line but moves hosting, data, maintenance and build work onto your budget. The cards below separate what is paid once from what recurs, so you can ask vendors and partners for the same scope.
Storyblok plan fees and tier
Storyblok charges a recurring plan fee that depends on the tier you buy. Check which features sit in each tier, including visual editing, workflows and higher API allowances, because moving tiers later can change the bill more than seat count does. Ask whether the plan includes the environments and spaces you need for staging and production, and whether it renews annually or monthly. Treat the plan fee as a line that repeats for as long as you stay on Storyblok.
Storyblok seats, locales and usage add-ons
Seats, extra locales, API requests and traffic can each add recurring charges on top of the plan. Count the editors, translators and reviewers who will work in the visual editor, not only developers, and count every locale that editors publish into. Model peak API traffic from your site, because campaign spikes often drive the add-on line. Ask for these add-on rates in writing and for the usage basis they are measured against.
Storyblok data-center choice
Data-center location is available only on higher Storyblok plans, so a residency requirement can force an upgrade in tier. Confirm in writing which regions are offered, which plan includes them, and whether the choice applies to stored content, assets and API delivery. If residency drives the decision, this line may be the reason the total cost rises, so it belongs in the quote from the start.
Payload software at no license fee
Payload is MIT licensed, so the CMS code itself carries no license fee to Payload. Your one-time costs are the work to install it into your Next.js app, define collections and blocks, and configure access control. Recurring costs come from running it, not from owning the code. Confirm with your legal team that the MIT terms fit any plugins or third-party packages your team adds.
Hosting, database, storage, CDN and backups
Self-hosted Payload recurs in compute for the Next.js app, a MongoDB or PostgreSQL database, object storage for media, a CDN for delivery and backup storage. Each has its own bill and its own owner, so assign them before you compare totals. Backups and restore tests are often omitted from early estimates, and they need their own retention and storage budget. Ask any partner to list each component, who pays for it, and how it scales with locales and traffic.
Build, migration and ongoing upgrades
Developer time is the largest one-time cost for Payload. It covers schema design, translating Storyblok components into Payload blocks, rebuilding live preview, importing content and assets, and testing editor workflows. Ongoing upgrades and security patching recur as hours each year. Request a quote that states the hours assumed for the build, the number of environments, the locale count and the hours assumed for upgrades, so that the one-time and recurring figures can be compared fairly.
What moving from Storyblok to Payload involves
The sequence turns a Storyblok space into a Payload project that you host, with content, locales, assets and a working visual preview checked against the original. Each step ends with a check that tells you whether the move can continue.
Inventory the space before exporting
Someone who knows the Storyblok space, usually a content lead with a developer, lists every component, content type, story folder, language, datasource, asset folder and integration that the site depends on. Confirm in the Storyblok documentation which of these the CLI exports and which must be recorded by hand, such as roles, workflows and scheduled publishing. The output is a written inventory with a count of stories per content type and the list of items that will be rebuilt manually. Do not start the export until the inventory and the documentation check agree.
Export components, stories and assets with the CLI
A developer uses the Storyblok CLI to pull components, stories, datasources, languages and assets with their metadata into local JSON and files. Keep the export in version control or a dated archive so you can rerun the comparison later. The check is that the story count and asset count in the export match the counts in the Storyblok interface for each language and folder. Record any gaps, including assets that fail to download, before moving on.
Translate component schemas into collections and blocks
A developer maps each Storyblok component to a Payload collection for pages and entries, or to a block in a layout field when the component is reused inside a page. Nestable components become blocks or nested fields, and component groups and presets are recorded as design decisions rather than copied. Payload generates TypeScript types from this code-defined config, so the schema is reviewed in pull requests like any other code. The output is a committed config and a mapping document that shows each Storyblok component and its Payload equivalent.
Import rich text, stories and assets
A script transforms exported stories into Payload documents, converting Storyblok rich text into the Lexical editor format and linking imported assets to Payload upload collections. Run the import against a staging database first, using the PostgreSQL or MongoDB instance you plan to use in production. The check is a sample review by editors of a set of representative pages, covering long rich text, embedded assets and linked entries. Expect the converter to need fixes, and log every story it could not transform.
Recreate locales and access rules
Configure Payload localization to match the Storyblok languages and fallback rules you recorded in the inventory. Recreate editor roles and field-level access in Payload's access control, because these do not come across in the export and must be designed again. Ask a translator or regional editor to confirm that each locale shows the right content, slugs and fallbacks. The output is a locale configuration and an access matrix signed off by the content owner.
Rebuild the front end and live preview
Developers build the Next.js front end that renders Payload content, then wire live preview so editors can see draft changes in the page layout. Storyblok's visual editor does not carry over, so the team must decide how preview URLs, draft access and layout rendering work. Test preview for each page template, including localized pages and any block that pulls data from another source. The check is that an editor can open a draft, change a block and see the update without publishing.
Test editor workflows with real tasks
Have a small group of editors complete their normal tasks in Payload, such as creating a landing page, translating a story, replacing an image and scheduling a publish. Record each task, the time it takes and each point where editors stop or ask for help, because the visual workflow differs from Storyblok. Fix the gaps the testing shows, then repeat the tasks with a second group if the first group reported large differences. The output is a list of accepted workflows and a set of open issues with owners.
Run parallel content checks and cut over
Before cutover, compare the Storyblok and Payload versions of the site page by page, checking text, links, media, metadata and each locale against the inventory. Keep Storyblok in read-only mode for the cutover window and write down the rollback plan, including who can switch the front end back and how content edits made in Payload are reconciled. Confirm the hosting, backups and monitoring are in place for the Payload database and the Next.js app before switching the production domain. The cutover is complete when the parallel comparison shows no unexplained differences and the rollback has been rehearsed.
Who runs Payload and what it asks of your team
Running Payload means someone on your side owns a Next.js application, its database, backups, upgrades, security patches and the TypeScript code that defines every collection, global and block. Unlike Storyblok, where the vendor operates the editing service and the content store, a self-hosted Payload install puts the payload.config.ts file, the collection definitions for stories and components equivalents, the database connection (MongoDB, PostgreSQL or SQLite) and the hosting target under your change control. A named owner for the schema code matters most, because editors will never see a field change until a developer ships it and runs any migration that goes with it.
Plan upgrades deliberately. The Payload GitHub releases page lists v3.91.0, released on October 15, 2026, and a v4.0.0 beta line in progress, with v4.0.0-beta.2 published on October 16, 2026. Treat the beta as a preview for planning, not a production target. Pin your version, read each release note for breaking changes to config, access control and database adapters, and rehearse every upgrade in a staging environment with a copy of production content before it reaches editors. Ask your implementation partner or in-house team to write that test routine down as part of the handover.
You can run this with in-house developers who already maintain a Next.js stack, or with an implementation partner working under a fixed written scope that covers deliverables, the environment, backup and restore testing and handover. DeployOpen is one such partner: it plans, implements, hardens, backs up and upgrades self-hosted platforms in your own cloud account or data center, and ongoing support, upgrades and continuous testing are available as retainers. Before you ask for a quote, confirm who will hold the database credentials, who approves a production upgrade and how long your team can take to absorb a major release.
What do buyers ask before moving from Storyblok to Payload?
How much does a move from Storyblok to Payload cost?
The cost is driven by the number of component types, the volume of stories and assets, how many locales you run, and how much custom preview work editors need. Storyblok plan fees and add-ons stop, but you take on hosting, database, CDN, and developer time for the build and the migration. No price figure is supplied here, so ask for a written scope that lists each cost component separately: one-time migration work, schema translation, preview build, testing, and recurring hosting and maintenance. Compare that against your current Storyblok invoices for the same period.
How long does a Storyblok to Payload migration take?
Timing depends on how many component schemas you must translate into TypeScript collection and block config, how much rich text and asset metadata you carry over, and how many locales must be recreated. Live preview is often the longest item because developers must wire the Next.js front end to draft content. Ask for a timeline tied to phases and acceptance tests, not a single date, and confirm which content types are in the first cutover.
Can editors keep a visual workflow in Payload?
Editors keep a visual workflow only if developers build it. Payload provides live preview and a block-based layout builder inside a Next.js app, but Storyblok's in-context visual editor is a different product, and the preview must be implemented against your front end. Test with real editors on representative pages, including nested blocks, draft states and localized content, before deciding the workflow is equivalent.
What developer skills does a Payload project need?
Payload is configured in code, so the team needs TypeScript, React, and Next.js experience, plus working knowledge of the database you choose: MongoDB, PostgreSQL or SQLite, as Payload's README lists. Payload generates TypeScript types from collections and fields, which helps keep the front end and schema aligned. Editors do not need code skills, but whoever owns schema changes does. Confirm that your team can maintain the application after handover.
Can our own team run the migration without an outside partner?
A capable in-house team can run the migration if it has the skills above and enough time away from product work. Storyblok's CLI can pull components, stories, languages and assets, but mapping them to Payload config, importing rich text and recreating roles and workflows are manual steps. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Weigh internal capacity against a written scope from any provider.
Does Payload's MIT license remove licensing risk?
Payload's MIT license lets you use, modify and host the software without per-seat or per-traffic license fees from Payload. It does not cover your content, your custom code, or third-party packages and fonts you add, so review those separately. Ask your legal team to confirm the license terms for every dependency in the build. Licensing risk is lower than with a source-available product, but it is not zero.
What happens to existing stories and assets during the move?
Stories become Payload documents in collections, components become blocks or fields, and assets are re-uploaded to storage you control. Storyblok's CLI can export stories, components, datasources, languages and assets, but roles, workflows and some metadata often need rebuilding by hand. Check the export before you start and keep the original Storyblok space available until you verify the new site. Confirm how asset URLs will change and whether redirects are needed for published pages.
How do we test before cutover?
Test by comparing the Storyblok and Payload outputs for a fixed sample of pages in every locale, checking rendered HTML, rich text, asset links, and draft and publish states. Run editors through their daily tasks in the Payload admin, including preview, and log every gap. Security and access rules also need testing: field-level access control and user roles must match the old permissions. Agree the pass criteria in writing before the test starts, and keep a rollback path until they are met.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Storyblok vs Payload, we start with a written scope that tests your editor workflow, locale model and hosting constraints before any build begins.
How we scope
- Inventory your Storyblok components, locales, roles and editor workflows before choosing a target design
- Confirm whether Payload's block layout builder and live preview meet your editors' in-context needs
- Agree the written scope, deliverables and timeline with you before any work starts, as engagements are fixed-scope
How we build
- Model Storyblok components as Payload collections, blocks and globals inside your Next.js application
- Configure localization, drafts and access control, then wire live preview to the frontend you choose
- Run security testing of the admin panel, APIs and access rules before content editors go live
How we hand over
- Document the schema, deployment, database and backup setup so your own team can operate the system
- Deliver runbooks for content migration checks, editor onboarding and preview troubleshooting
- Provide an evidence pack for your compliance team, noting that independent auditors issue any attestations
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan Payload version upgrades against the release line you choose, including any v4 changes
- Ask for a quote built from your written scope, since DeployOpen does not publish a price list
