Versions

Every change you save in the console edits your organization’s draft. Your sites never read the draft. They read the deployed document: the configuration in your newest deployment. A deployment is one numbered entry in your organization’s log, and Delivery › Deployments › Versions lists them.

The log, the draft and the preview live in your organization’s own database. No other organization’s deployments share it.

Draft, preview, deployment

• Draft: your settings and records as the console shows them now. There is one draft per organization, shared by everyone who edits it. Saving changes the draft, never the deployed document.
• Preview: a frozen copy of the draft, made by staging. There is one preview at a time, and staging again replaces it. EdgeKit stages automatically about 30 seconds after the last saved change; you can also stage by hand.
• Deployment: the preview, appended to the log as the next version. Version numbers start at 1 and have no gaps.

Staging also runs the gate, the checks a draft must pass before it can become a preview.

What your sites read

Every request is answered from the deployed document, never from the draft. There are two exceptions: trait collection, and a few catalog fields that decisions read. There is no branch, no per-request override and no rollback. In practice:

• A record you edit, disable or delete keeps answering as it was deployed until the next deploy.
• A request for a site no deployment includes yet answers 404 with code not_found until one does.
• Decide answers 503 with code service_unavailable while it has no deployed configuration for your organization. EdgeKit makes your organization’s first deploy when it opens your account.

See Error codes for the error body.

What deploying does

• It deploys the preview, never the draft. What you reviewed is what ships, byte for byte. A change saved after the preview was staged is not in it.
• It ships the whole preview: every pending change in the draft, from everyone who edited it, not only yours.
• It refuses a stale preview. If any version was added to the log after the preview was staged, the deploy is refused and you stage again.
• It adds one version and clears the preview. The log records the new version at once, and your sites start answering from it shortly after.

To undo a change, you edit the draft back and deploy it as a new version. See Undo a change.

The gate checks structure, not effect

The gate refuses a draft that cannot be deployed as it stands, for example:

• a decision record that references something missing or reads a fact that does not exist;
• a catalog record that references something missing;
• configuration that needs a newer EdgeKit release than the one your organization runs;
• event schemas, analytics settings or identity settings that are invalid;
• an offer whose discount or billing setup cannot work as configured.

Some checks only warn. A canvas or rule that can never be reached, because an earlier canvas or rule matches everyone, is a warning, and the preview shows how many warnings the gate found.

The gate does not check what a change does to your users. A valid edit can change which outcome many users get, and the gate passes it with no warning. Moving one canvas above another is enough. The preview lists every changed record and says whether each change is behavioural; reading that list and working out its effect is the only check between the draft and production.

What a version records

Field	What it holds
Deployment	The version number, unique and contiguous in your organization’s log
Moved	Configuration (what your staff authored and deployed) or Components (an EdgeKit release)
Deployed by	The person who deployed. EdgeKit deploys a Components entry
Deployed	When the version was added
Changes	Each changed record: new, removed, or its version move such as v3 → v4 (a presentational-only change keeps its number, such as v3 → v3)
Components live	The EdgeKit versions running with this configuration
Schema version	The version of the document format
Id	The deployment’s identifier

Each record (a feature, an outcome, a product, a site and so on) also has its own version number. It goes up by one in each deployment where the record’s behaviour changed, and stays the same otherwise. A record’s behaviour includes the records it reads, so a change to one record can move the version of another that depends on it. A presentational change, such as renaming an offer or a site, appears in the list of changes and moves no version.

What a deployment contains

A deployment carries everything your staff author:

• organization settings;
• sites: name, domain, status, allowed and redirect origins;
• products, offers, capabilities and coverage;
• features, outcomes, segments, meters and experiments;
• profile resolution, profile sets and profile fields;
• traits, the identity provider and billing provider settings;
• newsletter lists;
• event schemas.

It does not carry what users and systems produce, and none of this waits for a deploy: users, grants, records synced from your billing provider, meter counts, device state and the audit log. API keys are not in a deployment either. A key you create or revoke takes effect without one.

Configuration and Components entries

The log holds two kinds of entry, and version numbers count both:

• A Configuration entry is a deploy of your draft. It carries the EdgeKit versions that were already running.
• A Components entry is an EdgeKit release. It carries your configuration forward unchanged and shows Running until it finishes, then Live or Failed.

A Configuration deploy is often followed shortly by a Components entry with the same configuration and the same EdgeKit versions. Exactly one entry is marked Live: the newest one serving now.

What reads your settings as saved

Two things follow your current settings without a deploy:

• Trait collection: the list of traits a site asks users for, the check on a trait value a user saves, and whether a user has answered every required trait all follow your current trait settings. Anything that uses a trait’s value to make a decision still waits for the next deploy.
• Some catalog fields: decisions read a product’s sites, slug and rank, and an offer’s audience, as saved. See Products and Offers.

Who can stage and deploy

Role	Read the log	Stage	Deploy
Owner	Yes	Yes	Yes
Admin	Yes	Yes	Yes
Developer	Yes	Yes	No
Editor	Yes	No	No
Member	Yes	No	No

A button you lack the permission for is disabled, and the request is refused if it is sent anyway.

Next: Stage and deploy a change.