[Head-to-head comparison]
Storyblok vs Payload
Storyblok vs Payload for visual editing, self-hosting, content modeling, governance, APIs, cost and migration.
:format(webp)){kind=small}
By Kalle Bertell
Direct answer
Choose Storyblok when editors should compose pages in a managed visual editor and the content API can stay vendor-hosted. Choose Payload when the team will run the CMS, admin and database itself and can work from a TypeScript config. Live preview exists on both. Payload’s on-page visual editor is an enterprise feature, and Storyblok does not offer a self-hosted content backend.
Choose Storyblok when
Managed visual page editing
Editors assemble approved blocks in the embedded editor. The content API and file delivery stay on Storyblok.
A vendor-operated content store
The team does not run a database for the CMS. Frontend hosting is still yours.
Localization patterns in the product
Field, folder and space localization are documented product choices rather than a schema you design first.
Choose Payload when
The content database on your side
Payload stores documents in the MongoDB, Postgres or SQLite database you operate.
Schemas in the application repo
Collections, access rules and blocks are TypeScript, reviewed with the rest of the app.
No per-seat CMS license
The MIT app has no documented seat fee. You pay for infrastructure, and for enterprise features if you need them.
Consider neither when
Managed editing and a private database
Storyblok keeps the content store. Payload makes you run it. Neither is a managed CMS that also hands you the database.
No engineering after launch
Both need a frontend and a maintained content model. Payload also needs database and hosting work.
A one-page site with rare edits
A simpler site builder can cost less when blocks, APIs and a custom frontend add little.
Criterion-by-criterion comparison
Marketer autonomy
Both depend on a component model developers maintain. The default editor is different.
Storyblok
Visual composition from governed blocks
Editors assemble approved blocks without changing frontend code; their independence depends on the component library and validation rules.
View sources (2)
- Storyblok Visual Editor: Documents embedded preview, click-to-edit and live editing, including HTTPS and iframe/CSP requirements.
- Storyblok content modeling: Explains fields, blocks and stories, plus schema management through the UI, API and CLI.
Payload
Admin follows the config developers ship
Editors create and publish documents in the generated admin, including blocks once those blocks exist. Changing fields, validation or who can publish means a config change.
View sources (2)
- Payload blocks field: Stores mixed blocks, such as a page builder, each with its own schema in config.
- Payload access control: Documents collection, global and field access functions, including locale-specific checks.
Choosing between them
Editors assemble blocks in a guided canvas when the library already covers the page.
Editors use the generated admin. A new field or permission is a config release.
Give marketers the same page task and count how often each task waits on a developer.
Content modeling
Storyblok models blocks for pages. Payload models collections and blocks in TypeScript.
Storyblok
Reusable content built from fields, blocks and stories
Reusable schemas can be managed in the UI or automated through the Management API and CLI.
View sources (1)
- Storyblok content modeling: Explains fields, blocks and stories, plus schema management through the UI, API and CLI.
Payload
Collections, fields and mixed blocks in code
The config defines collections, globals, relationships and blocks that editors can reorder. That same config generates the admin and the APIs.
View sources (2)
- Payload blocks field: Stores mixed blocks, such as a page builder, each with its own schema in config.
- Payload REST API: Generates CRUD routes from collections, including depth, locale and where queries.
Choosing between them
Fields, blocks and stories map to the components editors place on a page.
The config is the schema, the admin and the API contract at the same time.
Model one shared item and one landing page in each, and see which schema your reviewers can change safely.
Workflow and governance
Storyblok tiers workflows by plan. Payload puts drafts in code and approvals in enterprise.
Storyblok
Useful defaults; advanced controls are tiered
A default three-stage workflow is documented; custom workflows, roles, pipelines and retention depend on the selected plan.
Plan considerations: Governance and environment features depend on your plan and contract; confirm which capabilities are included.
View sources (3)
- Storyblok workflows: Documents the default publishing stages, with assignees, roles, dates and notifications.
- Storyblok roles: Details role-based permissions for content, schemas, assets, languages, workflows and releases.
- Storyblok pricing: Lists space-based plans and limits for seats, API requests, traffic, content, assets, locales and governance.
Payload
Drafts and access are code; approvals are enterprise
You can enable versions, drafts, autosave and scheduled publish, then restrict drafts with access functions. Approval workflows are described on the enterprise page.
Plan considerations: Localized draft status is documented as beta. Test it before relying on per-locale publishing.
View sources (3)
- Payload versions: Stores version history, diffs, restore, draft visibility and scheduled publishing when enabled.
- Payload drafts: Drafts require versions and can autosave or schedule publish and unpublish events.
- Payload enterprise: Lists visual editing, SSO, publishing workflows and vendor or self-hosted enterprise deployment.
Choosing between them
A default workflow exists. Custom roles, pipelines and retention follow the space plan.
Drafts, autosave and schedules are flags in config. Approval chains are an enterprise conversation.
Write the approval steps first, then match them to a Storyblok plan or a Payload enterprise quote.
Localization and multisite
Storyblok offers folder and space structures. Payload localizes fields in config.
Storyblok
Field, folder and space localization
Combine translated fields, market-specific folders and separate spaces to balance shared content with regional independence.
View sources (1)
- Storyblok internationalization: Explains field-, folder- and space-level localization and how each approach affects publishing.
Payload
Field locales in config, with fallback
Locales are listed in the Payload config and enabled per field. Fallback is on by default, and the docs state no limit on how many locales you add.
Plan considerations: Per-locale publish status is a beta option and is off unless you enable it.
View sources (1)
- Payload localization: Configures locales in code, with fallback on by default and no documented locale cap.
Choosing between them
Field, folder or space localization gives regional teams a visible publishing boundary.
Add locales in config, with fallback on by default. Per-locale status is still beta.
Decide whether a market is a folder, a space or a locale on one document before you pick the tool.
Developer experience
Storyblok integrates a hosted editor. Payload is the application.
Storyblok
Framework-agnostic APIs plus schema tooling
Component-based models and API/CLI tooling support schema automation and version control; preview still needs frontend integration.
View sources (3)
- Storyblok content modeling: Explains fields, blocks and stories, plus schema management through the UI, API and CLI.
- Overview of Storyblok APIs: Describes REST delivery and management, GraphQL delivery and the Image Service API.
- Storyblok Visual Editor: Documents embedded preview, click-to-edit and live editing, including HTTPS and iframe/CSP requirements.
Payload
One TypeScript app for admin, API and data
Developers own the Next.js app, config, migrations and deployment. Editors inherit the admin that config generates, including custom components the team chooses to build.
View sources (2)
- Payload production deployment: Says Payload runs anywhere Next.js runs, and that you still provide a database and file storage.
- Payload REST API: Generates CRUD routes from collections, including depth, locale and where queries.
Choosing between them
Developers automate schemas with APIs and CLI while the visual editor stays Storyblok’s app.
Developers own the Next.js process, migrations and the admin that editors see.
Name who will patch the CMS a year after launch. That answer is the decision.
APIs and extensibility
Both generate APIs from the model. Payload also runs inside the app as a local API.
Storyblok
REST, GraphQL, management, images and webhooks
Use delivery and management APIs, an image service and event webhooks; REST remains the broadest documented API surface.
View sources (2)
- Overview of Storyblok APIs: Describes REST delivery and management, GraphQL delivery and the Image Service API.
- Storyblok webhooks: Documents event webhooks and the paid-plan requirement for webhook signing secrets.
Payload
REST, GraphQL and a local API from one config
Collections generate REST routes and a GraphQL endpoint. Queries can filter, select fields and populate relationships to the depth you request.
View sources (2)
- Payload REST API: Generates CRUD routes from collections, including depth, locale and where queries.
- Payload GraphQL API: Exposes a GraphQL API from the same config, by default at /api/graphql.
Choosing between them
REST and management are the broad surface, with GraphQL, images and webhooks beside them.
REST and GraphQL are generated, and server code can call the local API without HTTP.
Implement the read path the site actually uses, including drafts, and compare the code you keep.
Hosting and operations
Storyblok runs the content platform. Payload runs where you deploy Next.js.
Storyblok
Managed delivery with CDN and regions
Storyblok runs the content platform and CloudFront delivery with region-specific endpoints; your team still owns frontend hosting, builds and runtime operations.
View sources (2)
- Storyblok Content Delivery API: Describes REST JSON delivery, CloudFront caching and region-specific API endpoints.
- Storyblok Trust Center: Documents AWS hosting, regional residency options, ISO 27001 and platform reliability controls.
Payload
You run the app, database and files
Payload deploys anywhere Next.js runs, including Vercel or your own servers. The database, permanent file storage and email provider remain your responsibility.
Plan considerations: Enterprise agreements can include Payload hosting. The documented default is to host the app yourself.
View sources (2)
- Payload production deployment: Says Payload runs anywhere Next.js runs, and that you still provide a database and file storage.
- Payload get started: States the MIT license, self-hosting on Node.js, and enterprise SSO, hosting and visual editing.
Choosing between them
Useful when managed CDN delivery and the vendor regions are acceptable.
Useful when the database and files must sit in accounts you control.
If the content database must be yours, shortlist Payload. If it must not be your job, shortlist Storyblok.
Security and governance
Storyblok sells a hosted control plane. Payload’s controls ship in the app you deploy.
Storyblok
Managed security; advanced controls vary by plan
Documented protections include AWS infrastructure, residency options and ISO 27001; SSO, access controls, backups and SLAs vary by plan or contract.
View sources (3)
- Storyblok Trust Center: Documents AWS hosting, regional residency options, ISO 27001 and platform reliability controls.
- Storyblok roles: Details role-based permissions for content, schemas, assets, languages, workflows and releases.
- Storyblok pricing: Lists space-based plans and limits for seats, API requests, traffic, content, assets, locales and governance.
Payload
App-level controls; compliance follows your host
Payload documents HttpOnly cookie auth, CSRF checks and field-level access in the app you deploy. SSO is enterprise, and a SOC report depends on the host you choose.
View sources (2)
- Payload security: Describes HttpOnly cookie auth, field access control, CSRF checks and enterprise SSO.
- Payload SSO: Describes SAML and OAuth 2.0 sign-in as an enterprise feature.
Choosing between them
ISO 27001 and residency options are documented, with SSO and the SLA on the plan.
Cookie auth and field access are in the app. SSO is enterprise, and the host owns the compliance report.
Map SSO, backups and the SLA to the contract. For Payload, include the database host in that map.
Pricing and cost drivers
Storyblok meters the space. Payload meters your infrastructure and any enterprise add-ons.
Storyblok
Space plans with seat, usage and locale limits
Budget per space for included seats, requests, traffic, content, assets and locales; extra capacity and advanced controls can increase total cost.
Plan considerations: Check current pricing in your billing currency, including fair-use terms and contract-specific allowances.
View sources (1)
- Storyblok pricing: Lists space-based plans and limits for seats, API requests, traffic, content, assets, locales and governance.
Payload
MIT app; you pay hosting and enterprise extras
The CMS is MIT-licensed and free to run. Budget the Node.js host, database and storage, and ask sales if you need SSO, visual editing or Payload-operated hosting.
View sources (2)
- Payload get started: States the MIT license, self-hosting on Node.js, and enterprise SSO, hosting and visual editing.
- Payload enterprise: Lists visual editing, SSO, publishing workflows and vendor or self-hosted enterprise deployment.
Choosing between them
Budget seats, traffic, API requests, stories, assets, locales and the governance tier.
Budget the Node host, database and storage. Add an enterprise quote only for SSO, visual editing or Payload hosting.
Compare two years of Storyblok invoices with two years of hosting plus the enterprise features you actually need.
Migration and exit
Storyblok exports stories. Payload’s copy is the database you already run.
Storyblok
APIs and JSON/XML export; plan for assets
APIs and CLI tooling support content and schema migration; separately plan the transfer of asset files, references, translations and application code.
View sources (3)
- Storyblok Management API: stories: Documents programmatic content management and JSON/XML story import and export.
- Storyblok CMS migration: Explains programmatic content and asset migration, including CLI dry-run guidance.
- Storyblok backups: Documents S3 backups on eligible plans and exclusions, including actual asset files.
Payload
Content stays in the database you operate
Leaving means exporting the database you already run and replacing the admin, hooks and API usage in the application. REST can also read documents out of a running app.
View sources (2)
- Payload production deployment: Says Payload runs anywhere Next.js runs, and that you still provide a database and file storage.
- Payload REST API: Generates CRUD routes from collections, including depth, locale and where queries.
Choosing between them
Story export helps, but assets, references and block structure still need a target model.
A database dump is the primary exit. The admin and hooks do not move with it.
Export a sample from Storyblok and from the Payload database, then map both into a neutral content model.
Marketing website fit
Storyblok is the more direct page builder. Payload fits a team that will own the CMS process.
Storyblok
Visual page composition from reusable components
Campaign and marketing teams benefit from visual composition, provided the component library stays flexible and well maintained.
View sources (2)
- Storyblok Visual Editor: Documents embedded preview, click-to-edit and live editing, including HTTPS and iframe/CSP requirements.
- Storyblok content modeling: Explains fields, blocks and stories, plus schema management through the UI, API and CLI.
Payload
Fits when the team will own the stack
Blocks and live preview can support campaign pages after the frontend URL and block components exist. The team keeps owning that app after launch.
View sources (2)
- Payload blocks field: Stores mixed blocks, such as a page builder, each with its own schema in config.
- Payload live preview: Renders the frontend in an iframe and sends document changes with window.postMessage.
Choosing between them
Campaign pages line up with visual composition when the block library stays current.
Blocks and an iframe preview work after the app is built, and someone must keep that app running.
For a typical marketing site with no self-hosting requirement, start with Storyblok.
Visual editing and preview
Storyblok includes the visual editor. Payload’s equivalent on-page editor is enterprise.
Storyblok
Embedded visual editor with click-to-edit
Editors work in the embedded frontend; setup requires an HTTPS preview URL and compatible iframe and content-security settings.
View sources (1)
- Storyblok Visual Editor: Documents embedded preview, click-to-edit and live editing, including HTTPS and iframe/CSP requirements.
Payload
Iframe preview; visual editing is enterprise
Live preview loads your frontend in the admin and posts each change to that frame. The separate visual editor is named as an enterprise feature, not as part of the MIT app.
Plan considerations: The open-source website template lists Live Preview. Enterprise materials add on-page visual editing.
View sources (3)
- Payload live preview: Renders the frontend in an iframe and sends document changes with window.postMessage.
- Payload get started: States the MIT license, self-hosting on Node.js, and enterprise SSO, hosting and visual editing.
- Payload enterprise: Lists visual editing, SSO, publishing workflows and vendor or self-hosted enterprise deployment.
Choosing between them
Click-to-edit composition is part of the product once the preview URL and blocks exist.
The MIT app can iframe the site. On-page visual editing is a separate enterprise feature.
Try one campaign page in Storyblok and in Payload’s live preview, and price the enterprise visual editor only if the iframe is not enough.
Recommendations by use case
[Marketing website]
Start with Storyblok
Use Storyblok when editors compose campaign pages from blocks. Choose Payload when the same team will also operate the CMS process and database.
[Structured content platform]
Favor Payload when you own the data
Payload fits content reused across apps when the schema and database should live in your stack. Storyblok fits when that content is mostly pages and components.
[Multilingual multisite]
Match the publishing boundary
Storyblok’s folder and space patterns suit markets that publish separately. Payload field locales suit translations on one document, with per-locale status still in beta.
[Ecommerce]
Split pages from the catalog
Storyblok fits storefront landing pages. Payload fits when product documents and the storefront should share one application and database.
[Enterprise governance]
Validate the contract
Check SSO, approvals, backups and the SLA on the Storyblok plan. On Payload, check which of those are enterprise features and which are your host’s job.
[Small team]
Choose the operations load you can keep
Storyblok removes the CMS host from the team’s list. Payload removes license fees and adds a database and deployment to run. A simpler builder may still fit a small site.
:format(webp)){kind=small}
