Storyblok

Privately held, venture-backed company headquartered in Linz, Austria.

Founded 2017 by Dominik Angerer and Alexander Feiglstorfer in Linz, Austria.

Hosted headless CMS whose signature differentiator is a real-time Visual Editor (iframe live-preview with click-to-edit) layered on top of a standard headless content API. It still requires a developer-built frontend (Next.js, Astro, Nuxt, etc.) wired to the Storyblok Bridge to enable that visual editing; it is not a page builder that ships its own renderer.

The core CMS platform is closed-source, proprietary SaaS with no self-hosted/on-premises option. Storyblok does publish MIT-licensed open-source SDKs, CLI tools, and field-plugin libraries on GitHub, but the product itself is not open source.

No license applies to the hosted product itself since it isn't distributed software; the license note covers the open developer tooling only.

Reflects Storyblok's stated positioning around its component-based Visual Editor bridging marketer and developer workflows.

"Starter" free plan: 1 space, 1 user seat (up to 2 with a paid add-on seat), 100GB traffic/month, 100k API requests/month, 2 locales, 25k AI credits, no uptime SLA. Positioned for testing and personal projects, not production business use.

Explicitly framed by Storyblok as for testing/personal projects rather than production business sites.

Growth plan: $99/mo billed monthly, or $90.75/mo-equivalent billed annually ($1,089/yr). This is the cheapest paid tier with a custom domain and production-grade SLA (97%); the free Starter plan also supports a custom domain but has no SLA and is positioned for testing, not production.

Growth Plus plan: $349/mo billed monthly, or $319.91/mo-equivalent billed annually ($3,839/yr). Positioned by Storyblok as the plan for businesses needing custom workflows and release management, treated here as the most-popular self-serve tier since Premium/Elite are custom-quoted enterprise plans.

Not applicable as a distinct tier. Storyblok has no native ecommerce product; official commerce-platform integrations (Shopify, BigCommerce, commercetools, etc.) are field plugins gated to higher-tier plans, not a separate "ecommerce plan" with its own price.

Unlike hosted site builders, there is no "powered by Storyblok" badge to remove because Storyblok only serves content via API; it does not render the public-facing site.

Published pricing shows a standard monthly vs. annual-billing discount (annual roughly 8% cheaper per month), not an introductory-rate-that-jumps-at-renewal structure; no evidence of a distinct "renewal price" separate from the listed annual/monthly rates.

No money-back guarantee window is stated on the official pricing page; Storyblok instead offers a 45-day free trial (try-before-you-buy) rather than a post-purchase refund period.

The 'per-seat plus overage' structure means realistic team cost is often meaningfully above the sticker price once seats and traffic scale.

Content is authored as nested, reusable Blocks/components (Bloks) assembled into Stories; the Visual Editor overlays this on a live iframe preview of the developer-built frontend. Categorized as section-based rather than freeform-canvas because layout is bounded by developer-defined component schemas, not free positioning.

Editors drag and drop Bloks/components into Stories to compose and reorder pages within the Visual Editor.

Marketers can click directly on rendered elements in the live preview to jump to and edit the corresponding field, via the Storyblok Bridge's click-to-navigate and context-menu behavior.

Every space includes page/version history showing a git-style diff of current and previous saved/published versions, with one-click restore to any prior version.

Could not verify a specific continuous-autosave claim from official Storyblok documentation; the editor relies on an explicit save/publish action pattern per the Bridge docs (the bridge reacts to 'save' and 'publish' events), which suggests save is a deliberate action rather than confirmed silent autosave. Left null rather than guessed.

No dedicated native iOS/Android app for content editing; the Visual Editor is web-based only, accessed through a browser (including on mobile browsers), though Storyblok is commonly used as the content backend powering separately-built native mobile apps.

Content lives inside component (Blok) schemas defined and maintained by developers; swapping to a differently-structured template/component library is not a safe, content-preserving operation without developer migration work, since rendering is entirely custom-built rather than tied to a platform-provided template system.

Editorial judgment: for the content-editor role, the Visual Editor's live click-to-edit interface is genuinely close to a page builder's ease of use, better than most headless CMS editors. But the platform overall requires a developer to build and wire up the frontend, define every component schema, and connect the preview bridge before an editor can use it, which is real technical overhead compared to hosted builders like Wix or Squarespace where there's nothing to build. Rated moderate as a blend of editor-friendly UI with developer-dependent setup.

Storyblok ships no official pre-built site templates/themes. It is a content backend, not a site builder; "design" is entirely the responsibility of the developer building the frontend. Set to 0 rather than null since this is a confirmed structural fact, not an unknown.

Fonts are controlled entirely in the developer-built frontend's code/CSS; no platform restriction exists since Storyblok does not render the site.

Responsive behavior is fully determined by the custom-coded frontend framework (Next.js/Astro/Nuxt/etc.); Storyblok imposes no responsive constraints of its own since it only supplies content via API.

Full custom CSS is standard since the frontend is entirely developer-built code; not a platform toggle or plan-gated feature.

Full custom JavaScript is standard for the same reason: the frontend is custom application code, not a hosted renderer.

No native no-code animation/interaction authoring tool ships in Storyblok itself; any animation is implemented by the developer in frontend code (e.g., with Framer Motion, GSAP), not configured inside the CMS.

Storyblok has no built-in design-token/global-styles system of its own; any design tokens live in the developer's frontend codebase (e.g., a Tailwind config or CSS variables), not as a CMS-native feature. Distinct from Storyblok's content-modeling "component groups," which organize component schemas rather than visual styling.

Editorial judgment: because the rendered frontend is fully custom code with no platform-imposed theme or renderer, design has no structural ceiling. The tradeoff, as with any headless CMS, is that this flexibility requires a developer to build and maintain the frontend rather than being available to a non-technical user out of the box.

Storyblok hosts the CMS backend/API itself, but the public-facing frontend site is not hosted by Storyblok; developers deploy it separately (e.g., Vercel, Netlify, AWS). Distinct from page-builder platforms where the whole site is hosted end-to-end.

Storyblok is SaaS-only for the CMS backend. There is no on-premises deployment or Docker image for self-hosting the CMS itself. (The separately-built frontend, being ordinary application code, can of course be hosted anywhere.)

Content Delivery API responses and the Image Service are served through a CDN (AWS CloudFront) for cached/asset delivery, at up to 1000 cached requests/second on paid plans.

The Storyblok-hosted API and admin app are served over HTTPS; SSL for the separately-hosted frontend is provided by whichever hosting platform the developer chooses (typically free via Vercel/Netlify/Cloudflare).

These are API traffic/request limits for the headless backend, not disk storage caps like a traditional web host.

Not applicable in the traditional sense (Storyblok has no 'site' of its own to export), but because content is delivered via API, the developer-built frontend can freely use static-site generation (Astro, Next.js SSG/ISR, Gatsby, etc.) to pre-render fully static output at build time.

May 2026 CrUX data via HTTP Archive CWV Technology Report API: 55.2% combined pass rate across 2,205 desktop and 1,995 mobile origins tagged 'Storyblok' (desktop 59.3%, mobile 51.2%). Caveat: as a headless CMS, this reflects real-world sites' full custom frontend stack (framework, hosting, developer implementation choices), not a Storyblok-controlled rendering layer. Unlike page builders, Storyblok itself does not determine the site's runtime performance.

The Image Service API automatically resizes, compresses, and converts images to WebP (when supported by the browser) on demand via URL parameters, then caches the result on CloudFront CDN. Requires the developer to construct the parameterized URLs, so it is not automatic without any implementation.

Lazy loading of images is standard practice in Storyblok frontend tutorials and framework integrations, but this is implemented by the developer in the frontend code (e.g., native loading="lazy" or framework image components) rather than a feature the Storyblok platform itself ships or enforces. Could not verify a platform-level automatic lazy-loading guarantee from official docs, so left null rather than asserting it as a CMS feature.

Content Delivery API responses are CDN-cached with configurable cache-busting on publish; developers additionally control caching at the frontend/hosting layer (ISR, CDN headers, etc.) since the frontend is self-hosted.

Every Story has built-in SEO metafields (title/description) plus the official SEO app for structured meta-tag fields; rendering them into HTML is a frontend implementation task.

Story slugs are directly editable per-entry in the content editor.

No built-in redirect-management app ships by default; the standard pattern is storing redirect rules as content entries (a Story/datasource) and having the developer implement the actual 301/302 response in the frontend or hosting layer (e.g., a Netlify _redirects file or framework middleware). There is also a community-built app in the App Directory but no first-party redirects app confirmed in official docs.

Canonical URLs are fully controllable since the developer renders all <head> tags in the frontend from CMS field data; no platform restriction.

robots.txt is served by the frontend/hosting layer (a static file or route the developer controls), fully editable since Storyblok imposes no restriction on it. It is simply not a CMS-managed asset at all.

Storyblok has no automatic or built-in sitemap generator. Because the CMS doesn't know which URLs exist on the developer-built frontend, sitemap generation is a frontend implementation task (e.g., via framework sitemap packages querying the Content Delivery API), not a CMS feature.

No automatic schema.org generation; JSON-LD structured data is added by the developer in frontend templates using CMS field data as input.

Storyblok's internationalization model (field-level, folder-level, or space-level translation) stores per-locale content, but hreflang tag output is implemented by the developer in the frontend head, not automatically generated by the CMS.

The official SEO app (requires Growth plan) provides dedicated Open Graph fields (title, description, OG image) plus a Google snippet preview; free-tier spaces can still add equivalent custom fields manually.

Achievable via a custom robots-meta field on the Story schema, rendered into a <meta name="robots"> tag by the developer; not a built-in one-click toggle in the base product but fully controllable.

Alt text is a standard field on Storyblok's Asset object; the platform additionally offers an AI Alt Text feature that auto-suggests descriptions on upload, including in configured non-English locales.

No pre-built blog engine ships out of the box. A blog is built by the developer defining an "Article" content type/component schema and building the corresponding listing/detail frontend templates, per Storyblok's own blog-setup tutorials.

Custom content types ("Content Type" Blocks) with arbitrary field schemas and nestable component composition are Storyblok's foundational, signature capability.

Tags and folder-based organization are native; category-like taxonomies are typically modeled via Datasources (reusable key-value option sets) or reference fields to other Stories, both native mechanisms.

Native scheduled publishing lets editors set a future publish date/time for a Story; the Releases app extends this to scheduling coordinated batches of content changes together.

Native version history with git-style diffs and one-click restore to any prior saved or published version.

Multiple collaborators per space with role-based permissions are core to Storyblok's collaboration model; seat count is plan-gated (1 on Starter up to custom on Premium/Elite) but multi-author support itself is native.

No built-in RSS feed generator; Storyblok's own tutorials show RSS feeds implemented by the developer in the frontend framework (Astro, Nuxt, etc.) using the Content Delivery API, not a CMS-native feature.

Two APIs: the Content Delivery API is read-only (for the live frontend to fetch published/draft content), while the separate Management API provides full read-write CRUD over stories, components, assets, and space configuration. Counted as read-write overall since full programmatic write access exists.

Storyblok has no native product catalog, cart, or checkout. It offers official field-plugin integrations (BigCommerce, Shopify, commercetools, Salesforce Commerce Cloud, SAP Commerce Cloud, Shopware, Spryker, Sylius, Vendure, Saleor, CommerceLayer, Centra) that let editors reference products/categories from an existing external commerce backend inside the Visual Editor; actual commerce data and transactions remain on the connected platform.

No native digital-product/download delivery mechanism; this would be handled entirely by the connected commerce platform, not Storyblok.

Storyblok has no billing/subscription engine of its own; recurring payments are entirely a function of the connected commerce backend.

Not a Storyblok capability. Currency handling belongs to the connected commerce platform; Storyblok only stores content references, not pricing logic.

No point-of-sale capability; entirely out of scope for a headless content layer.

No cart functionality exists in Storyblok at all, so there is nothing to recover from; this lives entirely in the connected commerce platform.

Full content export via the Management API (all stories, components, assets references, datasources) or the official S3 backup app; no artificial export cap.

Note that the official S3 Backups app does not include story version history, presets, or actual asset binaries (only asset references); the Management API is needed for full version-history export.

The "design" (frontend site) is entirely developer-owned application code living outside Storyblok from day one. There is no platform-side design/theme to export because Storyblok never held it.

Domains are managed independently via standard DNS at the frontend-hosting layer (Vercel, Netlify, etc.), entirely outside Storyblok's control.

The frontend can be hosted anywhere and moved freely since it's ordinary application code; only the content backend (API) remains on Storyblok's SaaS infrastructure, which has no self-hosted alternative.

The Management API exposes complete read-write access to all content, components, assets, and configuration; the Content Delivery API separately provides full read access to published/draft content for the live site.

Editorial judgment: content itself exports cleanly via a full-access API with no proprietary rendering to unwind (a structural advantage over page builders). But the component-schema/Blok data model, workflows, and roles are Storyblok-specific constructs that require remapping to migrate to another CMS, and the backend itself is SaaS-only with no self-host escape hatch, landing this between Drupal/WordPress's low lock-in and closed hosted builders' high lock-in.

The App Directory count is an approximation from browsing the live storefront (pagination showed roughly 3 pages); no official single published total was found.

Both a REST-style Content Delivery API (read) and Management API (read-write), plus a GraphQL API alternative for content queries.

Native webhooks trigger on story publish/unpublish, asset upload, workflow changes, user management, datasource changes, discussions, and more; paid plans can add a signing secret for payload verification.

Not applicable as a plan-gated CMS toggle. Since the entire frontend is custom-built code, arbitrary embedded scripts/widgets are simply part of normal development, with no platform restriction at any tier.

The official Storyblok CLI supports space management, component/schema sync, migrations, and login/scaffolding tasks; open source and MIT-licensed.

Native Zapier integration is listed among Storyblok's documented integrations, alongside webhook-based connections to Make and similar automation tools.

No feature generates a full site or page layout from a prompt; Storyblok's AI Suite (Ideation Room, AI Translations, AI Alt Text, AI SEO) assists with content within an existing developer-built component structure, not site/page scaffolding.

The Ideation Room lets editors draft, extend, shorten, improve, and brainstorm article copy and headlines with AI directly in the editor.

AI Alt Text automatically generates accessibility image descriptions on upload, including in configured non-English locales; this is accessibility-description generation, not AI image creation/editing.

The AI SEO app/field (requires at least Growth plan) auto-generates SEO meta tags from page content analysis.

AI features are opt-in and credit-metered rather than unlimited; several (AI SEO, custom workflows-adjacent AI) require at least the Growth plan.

Default roles (Owner, Admin, Editor) plus fully custom roles with fine-grained permissions across stories, components, fields, assets, languages, datasources, tags, and apps.

Real-time collaborative editing lets multiple users work on the same content simultaneously, with component-level comments for contextual feedback.

A default 3-stage workflow (drafting, reviewing, ready-to-publish) ships out of the box; custom workflow stages with per-content-type rules and assignable approvers/due dates are a premium feature on higher tiers.

Pipeline Stages let teams define named environments (e.g., Preview to Staging to Production) each with its own API token, with content frozen outside the editable Preview stage until explicitly deployed forward: a full staging-environment model, not just a preview link.

Component-level discussions/comments let editors leave contextual feedback directly within the editor.

Activity/version history tracks changes with a git-style diff per story; broader organization-wide audit logging (e.g., AI usage history filterable by provider/feature/user/space) is available in organization settings.

Could not verify a specific 24/7 support commitment from official documentation; support is described as tiered by plan (community, email-with-SLA, dedicated live chat) without a stated round-the-clock guarantee at any tier. An optional paid "Extended Support Package" exists for Enterprise customers but its hours were not confirmed.

Editorial judgment: Storyblok's documentation is unusually deep for a headless CMS, with framework-specific guides (Next.js, Astro, Nuxt, React, Vue, Remix, SvelteKit), a dedicated API reference, tutorials, and an active Discord/community layer supplementing official docs, comparable to best-in-class developer-tool documentation rather than typical CMS help centers.

Could not find an official, current published figure for Discord/community member count or registered developer accounts; Storyblok references an active Discord community but no authoritative size metric was located in official sources.

Not automatic by default across all plans. The official S3 Backups app configures daily or weekly automated backups to a customer-owned AWS S3 bucket (depending on plan), covering stories, releases, component schemas, roles, and asset references (not story version history, presets, or asset binaries themselves, which require the Management API). Manual restore via the app or Management API/community CLI tools.

Multilingual content is a core, native capability with three configurable approaches (field-level, folder-level, or space-level translation) that can be combined; locale count is plan-gated (2 on Starter, unlimited on Growth+).

AI Translations (Labs/beta) can auto-translate content into 35+ languages; translation also integrates with third-party localization platforms (Lokalise, Localazy) via official connectors, and folder/field-level structures support human translation workflows.

Per-locale content and URL structure is natively supported (folder- or field-level translation with locale-specific slugs); hreflang tag output itself must be implemented by the developer in the frontend rather than auto-generated, but the underlying localized-URL data model is native.

Could not verify a specific statement about right-to-left language rendering support (in the admin editor UI or as a documented frontend consideration) from official Storyblok documentation. Since the rendered frontend is fully custom-built, RTL display would ultimately depend on developer implementation regardless, but no official confirmation of editor-side RTL support was found.