Platform · Environments

Test on a copy, then swap it in

Copy the environment your site runs on, make the risky change on the copy, check it, then point the production alias at it. The copy holds the content model, the entries, the page tree, redirects and the asset library. The swap is one atomic step: the CDN is purged, and keys scoped to the alias keep working. Everything you put in, your content, model and files, exports in one archive, any time, from the admin.

Book a walkthrough →Uniwoven comes with Sonklar's team, not as a standalone licence.
The alias swap

Production is a name, not a place

Before

production points at main.

Your site and its keys ask for production. The alias decides which environment answers.

Copy

Fork main into release-nov.

The copy starts identical: model, locales, entries, page tree, redirects, assets and Throughlines. Asset files aren't duplicated; the copy points at the same stored files. From here the two change independently.

Change

Do the risky thing on the copy.

Restructure the page tree, roll out a locale, rehearse a migration. Production doesn't notice. Point a preview site at the copy and check it.

Swap

Move production to release-nov.

One atomic step. The CDN cache is purged, and keys and webhooks scoped to production follow the alias without a config change.

After

main stays where it was.

Nothing is deleted. If the release is wrong, point production back at main with the same one-step move. Edits made on release-nov after the swap stay there, because environments don't merge.

What a swap touches

Boring where it counts

A swap changes which environment answers, and handles what depended on the old one in the same step.

01

Caches.

The swap purges the CDN, so the old environment's cached responses stop being served. Your frontend doesn't redeploy.

02

Keys and tokens.

Scope a key to an alias and it follows the swap. Scope it to an environment name and it stays put. A token scoped to staging can never write to main, because scopes are checked on every request.

03

Sync.

A sync cursor names a concrete environment, so after a swap your mirrors run one full sync, then carry on with deltas. Locales live per environment, so a swap can ship a locale rollout in one step.

04

Who can do it.

Forking and swapping need an admin, or a management token with no environment scope. Editors keep editing content; they don't move production.

05

No plan gate.

Environments and aliases come with the content platform. There are no plan tiers and no environment count to negotiate. Our view, October 2026: on Contentful the number of environments depends on the plan. Corrections welcome.

Export

Leaving takes one archive

Everything you put in, your content, model and files, exports in one archive, any time, from the admin. The archive is a .zip with one readable JSON file per kind of record, plus the raw files. Large environments stream to disk instead of loading into memory. The same export runs from the CLI and the SDK, and an import replaces a target environment in one step.

One .zipAdmin, SDK or CLIStreamedReadable JSON
Export an environment, import it elsewhere
# Export an environment to a .uniwoven.zip (streamed, never buffered in memory)
uniwoven env export --base-url https://api.example.com --space my-space \
  --environment main --out backup.uniwoven.zip

# Replace ALL content of an environment from an archive
uniwoven env import --base-url https://api.example.com --space my-space \
  --environment staging --file backup.uniwoven.zip --replace
Both commands use a management token (--token or UNIWOVEN_MANAGEMENT_TOKEN). --no-files exports JSON only. Import refuses to run without --replace.
Honest limit

There's no environment merge. You branch, change, and swap forward. If two people change two copies, one carries their changes over to the other, by script or by hand. If your process depends on merging parallel branches, say so on the walkthrough. A DXP Assessment (€7,900) puts a cost on it, on your current platform and on Uniwoven, and ends with a written go or no-go.

See the DXP Assessment →
Questions

What technical owners ask about environments

Fork the environment that production points at, make the change on the copy, and check it with a preview site. Then move the production alias to the copy in one atomic step. The CDN is purged, keys and webhooks scoped to the alias follow it, and the old environment stays where it was, so rolling back is the same move.

See a release go live by alias swap

A free walkthrough. We shape the sample space like your site, fork it, change it, and swap it in front of you. There's nothing to prepare.

Book a walkthrough →