Publishing
Nothing reaches your apps until you publish. Here is what that actually does.
Snapshots
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.
Rollback
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.
A rollback restores the published payload, not the dashboard rows behind it. The edits that caused the problem are still there, now marked unpublished. That is deliberate, rollback stops the bleeding, and fixing forward should be a decision you make on purpose.
How quickly changes land
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.
Unpublished changes
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.