How changes stay safe

Every change Flarebox makes to Cloudflare, from a DNS record to a WAF rule, goes through one path. There’s no second way in.

The path

1. Plan. Flarebox reads the current state, builds the exact API calls and a field-by-field diff, and stores the plan in the Rust core under a random id. The window gets the diff, not the calls.
2. Review. You see the diff. Confirm buttons on destructive changes are never focused by default, so a stray Enter can’t apply one.
3. Apply that plan. Applying takes the plan’s id and runs that stored plan, never a payload from the window. A plan can be applied once, within 10 minutes. Script injected into the window could only apply a plan you’d already been shown.
4. Stale check. Just before writing, Flarebox reads the target again. If it no longer matches what you reviewed, it refuses: “changed since you reviewed it”. Without this, an undo could silently overwrite someone else’s dashboard change.
5. Write, with the write token, loaded only now.
6. Read back. Flarebox reads the result to check the change really landed.
7. History, with undo.

Undo

Every reversible change records its “before” state. Undo is that state applied again, through the same plan, review and stale check. Undoing a deleted DNS record recreates it with a new id, and Flarebox says so.

Irreversible actions

Some things can’t be undone: cache purges, deleting a tunnel, media or a Logpush job. They’re marked as irreversible, and they need the name typed before they run. HSTS is reversible in Cloudflare but not in browsers, which keep it for its max-age, so making it stronger needs the zone name typed too, with that warning.

Drift

Changes made in the dashboard show up as drift: Flarebox compares what it last read with what’s there now. The last state is kept for offline viewing.

Read-only mode

A switch that blocks every change from this machine. It’s enforced in the Rust core, not just in the window: with it on, every apply is refused.

Why the confirm rule exists

On 2026-10-14, an approved deploy ran twice during testing because a confirm dialog had its Deploy button focused and an Enter reached it. Since then, no confirm dialog focuses its destructive button, and a test checks every one.