How do I create a preview environment in Storyblok?

Natively, create a pipeline stage and bind a delivery token to it — the token then serves that environment. This requires the Pipelines app on the space.

Can I duplicate a Storyblok space to make a staging environment?

You can, but the two spaces drift immediately and there is no promotion path between them. Story ids also differ, so internal links and relation fields break when content is copied by hand.

Will a separate preview environment break the Visual Editor?

Not if you route by access level. The Visual Editor needs draft content from Storyblok with the bridge script, so keep draft traffic pointed at Storyblok and send only published environment traffic elsewhere.

Do I need to change my frontend code to use a different environment?

Only the API base URL and the token. If the response format matches Storyblok’s Content Delivery API, your components, queries and data layer are unchanged.

Can I get preview environments without upgrading my Storyblok plan?

Yes. The stories and api_keys endpoints are available on every plan, which is enough to run environments and promotion outside Storyblok while authoring stays in your space.

Guide

Storyblok preview environments without upgrading your plan

Why space duplication and manual story copying fall apart, what a real preview environment needs, and how to give every team its own.

Last updated August 2026

A preview environment is somewhere content can be wrong without anyone noticing. Developers have had this forever — a dev branch, a staging deploy, a feature preview. Content teams frequently do not, and end up testing in the only environment there is.

What people try first, and why it breaks

Approach	Breaks because
Duplicate the space	Two spaces drift immediately. Editors forget which is real, and there is no way to promote changes between them.
Copy stories by hand	Slow, and one mis-click publishes untested content. Story ids differ, so internal links break.
A "draft" folder in the same space	Still one environment. Anything published is live, and the folder pollutes your content tree.
Upgrade for Pipelines	Works, and roughly doubles the CMS bill for a feature that is one primitive.

The manual approaches all fail for the same underlying reason: ids are stage-local. Copying a story between spaces without remapping parent_id, relation fields and internal links produces content pointing at the wrong entry or at nothing.

What a real preview environment needs

Isolation. Publishing in preview must not touch production.
Real data. An empty environment tests nothing; it needs the actual content tree, folders included.
A stable address. The preview site should not be reconfigured every time content moves.
A promotion path. Content that looks right must be able to move forward without a copy-paste ritual.

Token-per-environment is the mechanism

The token is the environment. A site holds one delivery token permanently and never names a branch; promoting content changes what that token returns, with no redeploy.

This is how Storyblok does it natively, by binding an access token to a stage:

POST /v1/spaces/:space_id/api_keys

{ "api_key": { "name": "Dev", "access": "public", "branch_id": 12345 } }

Environment	Token type	Sees
Visual Editor / local	preview	Draft and published
Dev site	public, bound to dev	What was promoted to dev
Live site	public, bound to production	What was promoted to production

Keep the Visual Editor pointed at Storyblok

One detail teams miss: Storyblok’s Visual Editor loads your site in an iframe and expects it to fetch draft content from Storyblok with the bridge script attached. Route by access level and it keeps working untouched — draft traffic to Storyblok, published environment traffic wherever your environments live.

Doing it without the Pipelines add-on

Storyblok’s own branches and deployments endpoints require the Pipelines app. Two endpoints stay open on every plan, and they are enough: /stories to read content and /api_keys to mint delivery tokens.

That is the approach Exacta takes:

Editors keep working in your Storyblok space — nothing about authoring changes.
Exacta mirrors the space’s published content, folders included, and keeps it in sync.
Environments and promotion live on our side, with a delivery token per environment.
Your frontend swaps api.storyblok.com for api.exacta.im — the response shape is identical, so components, queries and data layer stay exactly as they are.

// before
new StoryblokClient({ accessToken: 'storyblok_token' })

// after
new StoryblokClient({
  accessToken: 'tk_dev_...',
  endpoint: 'https://api.exacta.im/v2',
})

Common questions

How do I create a preview environment in Storyblok?: Natively, create a pipeline stage and bind a delivery token to it — the token then serves that environment. This requires the Pipelines app on the space.
Can I duplicate a Storyblok space to make a staging environment?: You can, but the two spaces drift immediately and there is no promotion path between them. Story ids also differ, so internal links and relation fields break when content is copied by hand.
Will a separate preview environment break the Visual Editor?: Not if you route by access level. The Visual Editor needs draft content from Storyblok with the bridge script, so keep draft traffic pointed at Storyblok and send only published environment traffic elsewhere.
Do I need to change my frontend code to use a different environment?: Only the API base URL and the token. If the response format matches Storyblok’s Content Delivery API, your components, queries and data layer are unchanged.
Can I get preview environments without upgrading my Storyblok plan?: Yes. The stories and api_keys endpoints are available on every plan, which is enough to run environments and promotion outside Storyblok while authoring stays in your space.