Skip to content

Versions FAQ

No. There is no rollback, no restore and no per-record revert. To undo a change, edit the draft back, stage it and deploy it as a new version. See Undo a change.

Why hasn’t my saved change reached my site?

Section titled “Why hasn’t my saved change reached my site?”

Saving changes the draft, and your sites read the deployed document. A change reaches requests after someone stages and deploys it. Once deployed, your sites normally start answering from the new version within seconds. Trait collection and a few catalog fields are the exceptions: see What reads your settings as saved.

No. A deploy ships the whole preview, which is every pending change in the draft, made by anyone. Before you deploy, read every change in the preview. If a change is not ready, change it back in the draft or leave it out of the next deploy where its screen offers that.

Will the gate warn me if a change locks users out?

Section titled “Will the gate warn me if a change locks users out?”

No. The gate checks structure: missing references, unknown facts, settings that cannot work, and whether your organization’s EdgeKit release can read the configuration. It does not measure how many users get a different outcome. A valid edit, such as moving one canvas above another, can change what many users get and pass the gate with no warning. The preview lists each changed record and whether the change is behavioural; deciding what that does to your users is up to the person who deploys.

Is there an approval step before a change goes live?

Section titled “Is there an approval step before a change goes live?”

Staging and deploying are separate permissions, so one person can stage and another deploy. There is no multi-step approval workflow. Anyone whose role holds the Deploy permission can deploy a preview.

Owner and Admin can stage and deploy. Developer can stage but not deploy. Editor and Member can read the log only.

Can I switch something off instantly in an emergency?

Section titled “Can I switch something off instantly in an emergency?”

No. Disabling a record is a draft edit: the record keeps answering until the next deploy, and that deploy ships everything else pending in the draft. There is no override that bypasses a deployment. The fastest fix is to edit, stage and deploy.

Can I take a site offline without a deploy?

Section titled “Can I take a site offline without a deploy?”

No. A site’s status is part of the deployment, along with its domain and its allowed and redirect origins. A change to any of them takes effect at the next deploy.

A site exists for requests only once a deployment includes it. Until then, requests for it answer 404 with code not_found. Stage and deploy once the site is in the draft. See Sites.

Do API keys, users or grants wait for a deploy?

Section titled “Do API keys, users or grants wait for a deploy?”

No. A deployment carries what your staff author. API keys take effect when you create or revoke them. Users, grants, records synced from your billing provider and meter counts are written as they happen.

I added a trait. Why are sign-up forms already asking for it?

Section titled “I added a trait. Why are sign-up forms already asking for it?”

Trait collection is one of two exceptions to the draft rule. Which traits a site asks for, the check on a value a user saves, and whether a user has answered every required trait follow your current trait settings as soon as you save them. A decision that reads a trait’s value still waits for the next deploy. The public trait endpoints can be cached for up to 5 minutes.

I changed a product’s sites. Why did access change before I deployed?

Section titled “I changed a product’s sites. Why did access change before I deployed?”

A product’s sites, slug and rank, and an offer’s audience, are the other exception. Decisions read them as saved, so a change to a product’s sites changes access for everyone holding it without a deploy. A browser sees it the next time its access cookie is refreshed. See Products.

Someone else staged. What happened to my preview?

Section titled “Someone else staged. What happened to my preview?”

It was replaced. There is one preview per organization, and each stage overwrites it, including the automatic stage that runs about 30 seconds after any saved change. The band shows who staged the current preview and when. Stage again if you need a fresh one, and read it before you deploy.

Why does the band say “a deployment landed since — stage again”?

Section titled “Why does the band say “a deployment landed since — stage again”?”

A version reached the log after the preview was staged, so its list of changes is out of date. That version can be another person’s deploy or an EdgeKit release. The Deploy button stays disabled until you stage again.

I saved a change, but the preview doesn’t include it. Why?

Section titled “I saved a change, but the preview doesn’t include it. Why?”

Automatic staging runs about 30 seconds after the last saved change, or after at most 5 minutes while changes keep arriving. If the draft fails the gate, nothing is staged and the earlier preview stays. Select Stage the draft (Re-stage the draft when a preview exists) to stage now and see any failures.

What are the Components entries in my log?

Section titled “What are the Components entries in my log?”

They are EdgeKit releases. A Components entry carries your configuration forward unchanged and changes only the EdgeKit versions your organization runs. A Configuration deploy is often followed shortly by a Components entry with the same EdgeKit versions. Both kinds take a version number, so your own deploys are not numbered consecutively. Open the Configuration edition to see only your organization’s deploys.

No. A deploy happens when someone with the Deploy permission selects Deploy #n.

Can I test a preview on my site before deploying it?

Section titled “Can I test a preview on my site before deploying it?”

No. A preview answers no requests. Your sites only ever get the deployed version.

It ships whatever the draft holds. A decision record you disable (shown as not in next deploy) is left out of the deployment, so keep unfinished features and outcomes disabled until they are ready. Any record the preview lists as new will ship with the deploy.

Why did a record’s version go up when I changed it back?

Section titled “Why did a record’s version go up when I changed it back?”

A record’s version counts the deployments in which its behaviour changed. Changing it back is another change, so the number goes up again. A record that a deployment removed and that you create again later starts at version 1.

Every version is kept in your organization’s log. The screen reads the 200 newest entries.