Publishing

Publishing compiles an environment into two immutable JSON payloads, a public one with sensitive flags stripped, and a private one with everything, and writes them to Cloudflare’s edge under the next sequence number.

Your apps read those static objects. Reads never touch the database behind the dashboard, which is why a problem on our side does not become a problem in your app.

Restoring an earlier snapshot republishes its contents under a new number. History is append-only: rolling back to #41 creates #44 carrying #41’s payload, so the record of what was live and when is never rewritten, and your apps see a normal forward-moving sequence.

Each environment keeps its newest 100 snapshots, and every snapshot from the last 90 days, whichever is more. Older ones are removed once a day, payload and history row together, and can no longer be restored. The live snapshot is always among the newest, so it is never removed. Audit entries are kept for a year.

Each project can email its workspace, send a webhook, or both, whenever it publishes or rolls back, from the dashboard or the management API. Set it up under Notifications in the project’s sidebar, and choose which environments to hear about; production alone is the default.

Emails go to members with a confirmed address and list what changed. Webhooks are a JSON POST with the event type (snapshot.published, snapshot.rolled_back or test), the project, environment, sequence number, note, who published, the same list of changes the publish dialog shows, and a link. They are signed with Standard Webhooks, so any of its libraries verifies one with the secret shown on the Notifications page.

A flag’s change can be scheduled instead of published now: edit the flag, choose Schedule, and pick when. At that time the change is saved and published, for that flag only. Other unpublished edits in the environment stay unpublished, so a timer never ships somebody’s half-finished work.

A rule with a percentage rollout can be raised in planned steps, for example 25%, then 50%, then 100%, a day apart. Each step is published at its own time, and cancelling a step cancels the ones after it.

On the Free plan, scheduled changes run at 00:00 UTC on the chosen day. Pro and Team schedule to the minute. The environment needs to have been published once, since a scheduled change publishes one flag on top of what is live.

SDKs refresh on mount, when the app returns to the foreground, and on an interval, five minutes by default. Each refresh is a conditional request, so an unchanged snapshot costs a 304 with no body. Add up to thirty seconds of edge caching and a change is typically live within a minute, and immediately for anyone who backgrounds the app and comes back.

The dashboard keeps a banner in view whenever an environment has edits that are not live. The failure mode of a publish model is editing all day and never publishing, so it is deliberately hard to miss rather than a subtle dot.