Storyblok with Astro: Setup, Visual Editor and Cost

Astro is fast because it normally ships finished HTML files. The catch rarely shows up in the technology. It shows up in the first editorial meeting after launch: content lives as Markdown files in the repository. For a development team that is convenient. For a marketing department that wants to change a headline between two appointments, it is a nuisance.

Storyblok answers that. What the vendor adds alongside Astro, and where it gets awkward, is below. One disclosure first: we have evaluated Storyblok and costed it for proposals, but we do not run it in production for any client. So this is an assessment, not a success story.

Why Storyblok alongside Astro

Briefly, in case the term is new: a headless CMS manages content and exposes it through an interface instead of delivering a website itself. The visible frontend is built by a separate tool, here Astro. There is a fuller explanation in What is a headless CMS?; which categories exist and which suits which team is covered in the headless CMS comparison.

Storyblok belongs to the dedicated SaaS category. What sets it apart from Contentful, Sanity or Hygraph:

The Visual Editor. Editors work on content in a preview of the real page rather than in a form. That sounds like a detail, but it often decides whether a team accepts the new system at all.

The head office. Storyblok is a Vienna company. For European businesses and public-sector clients that shortens the discussion about data processing and third-country transfers considerably, even if the actual storage location still needs checking separately.

There is also the pairing itself: Astro has an officially maintained Storyblok integration, and Storyblok maintains an Astro SDK in return. Both sides have an interest in the connection working, which is not a given with niche combinations.

The Visual Editor, and what it is not

Without this editor there would be little reason to pick Storyblok over Contentful or Sanity. An editor opens an entry and sees the page the way visitors will see it. Clicking a heading opens the matching input field, and changes appear in the preview straight away.

Compared with a classic headless CMS form, where you fill in fields and hope for the best, that is a noticeable difference. The standard objection to headless is “our people can’t see what they’re doing any more.” The Visual Editor answers it.

One limit needs stating clearly up front, otherwise it becomes an argument later: the Visual Editor is not a page builder. Editors can add, fill, reorder and remove blocks. They cannot drag columns around, change spacing or invent a new layout. Which blocks exist, and how they look, is decided in development.

That is a deliberate choice and usually the right one, because it keeps the design stable over years. Anyone coming from WordPress with Elementor, used to assembling every page freely, will still experience it as a restriction at first. That expectation belongs in the first conversation, not in the handover.

Content model: blocks instead of pages

Storyblok calls its content blocks “bloks”. A blok is a reusable building block with defined fields, for example a teaser with heading, text, image and link. Bloks can be nested, so a page becomes a list of building blocks rather than one large text field.

This modelling is the actual core of the project. It determines how pleasant the site is to maintain in two years, and it is harder to change later than the design. You can get it wrong in either direction:

• Blocks that are too coarse. A single “landing page” blok with forty fields is just a form with extra steps. The Visual Editor gains you nothing.
• Blocks that are too fine. If editors have to choose between twenty nearly identical building blocks, they will choose wrong. Fewer, clearly named bloks work better.

A workable starting point is somewhere between eight and fifteen blocks for a typical company website. More important than the number is that each block has a recognisable purpose you can explain in one sentence.

What implementation looks like

Technically the connection is modest. The integration is registered in the Astro config, and that is where bloks from Storyblok are mapped to Astro components in the project:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import { storyblok } from '@storyblok/astro';

export default defineConfig({
  integrations: [
    storyblok({
      accessToken: STORYBLOK_DELIVERY_API_TOKEN,
      components: {
        page: 'storyblok/Page',
        teaser: 'storyblok/Teaser',
        grid: 'storyblok/Grid',
      },
    }),
  ],
});

One note, because plenty of older tutorials online show it differently: the integration is imported as a named export, import { storyblok }, not as a default import.

Each Astro component then receives the matching blok as a prop. To make an element clickable in the Visual Editor, storyblokEditable marks it in the markup:

---
// src/storyblok/Teaser.astro
import { storyblokEditable } from '@storyblok/astro';
const { blok } = Astro.props;
---
<h2 {...storyblokEditable(blok)}>{blok.headline}</h2>

That is all the basic wiring takes. The effort is not in this plumbing but in what comes before it: the content model and the components themselves.

One thing trips up almost everyone on a first project: Storyblok distinguishes between a draft and a published version. The Visual Editor works against draft, the production build fetches published. Confuse the two and you either publish unreviewed content or wonder why your changes never arrive. Live preview inside the editor can be enabled on top of this, but it requires server-side rendering rather than a purely static build.

Publishing: a webhook, not click-and-live

This is where expectations diverge most. In WordPress a change is online the moment you save it. On a statically built Astro site it is not.

The sequence looks like this instead: an editor publishes in Storyblok, Storyblok calls a webhook, the webhook triggers a new build, and the result is deployed. How long that takes depends on the size of the site and the build environment, and for a modest company website it is usually a matter of minutes.

For most content that is entirely unproblematic. A blog post does not need to appear in the same second. It becomes critical for data that changes often and at short notice, such as prices, availability or appointment slots. Those areas belong in server-side rendering, not in the static build.

What you get for the delay is finished HTML with no database query on page load. We have covered what that means for Core Web Vitals separately.

Cost and data location

Storyblok bills by users, traffic and feature set. There is a free entry point that really does cover small sites with one or two editors. Above that, pricing steps up through team and enterprise tiers, where approval workflows, fine-grained roles and guaranteed EU hosting usually sit further up the ladder. The specific figures change too often to pin down here; check them with the vendor before you quote.

For budgeting, a different number matters anyway: the licence is rarely the biggest line item. The effort is in the one-off build, meaning the content model, the components, migrating existing content and getting the editorial team up to speed. Comparing monthly fees alone means comparing the wrong quantity.

On data protection: a Vienna head office is a good starting point, but not proof. Where your content is actually stored depends on tier and selected region, and that belongs in the conversation before you sign, along with the data processing agreement and the sub-processors involved. Static delivery does ease the picture: visitors to your site never talk to Storyblok, the connection only exists at build time. The full checklist is in GDPR-compliant headless CMS.

When Storyblok is the wrong fit

We would advise against it in these cases:

• Little content, technical team. If a handful of pages change rarely and the changes come from developers anyway, Astro’s own content collections are enough. No extra system, no licence, everything versioned in the repository.
• A settled WordPress team. If your editors know WordPress and like it, moving them to a new CMS is friction for nothing. You can keep WordPress as the backend and still deliver with Astro, as described in Headless WordPress with Astro.
• No budget for recurring cost. A SaaS CMS is a permanent budget line. If you want to avoid that, a self-hosted system or a file-based approach serves you better.
• An expectation of free layout. If your editors expect to assemble every page themselves, the Visual Editor will disappoint them. Settle that expectation beforehand, not after launch.

Our verdict

Storyblok alongside Astro makes sense when two conditions meet: your editors maintain content themselves on a regular basis, and they need an interface that shows them what they are doing. If only the first is true, there are cheaper routes. If neither is, content collections are the simpler answer.

The clearest thing to come out of our evaluation: wiring up the CMS takes a day. The content model takes weeks. That is the exact opposite of what the documentation leads you to expect.

---

Thinking about putting a CMS behind your Astro site? Tell us who maintains the content, how often it changes and how structured your content is today. We will tell you honestly whether Storyblok, WordPress as a backend, or no CMS at all is the right route. Drop us a line.