Use the preview registry commands to inspect, reconcile, retire, and clean up previews
The preview registry is D1-backed and gives Devflare a durable record of preview, alias, and deployment state so cleanup and reconciliation do not have to depend on fragile one-off scripts.
Once previews exist, lifecycle management matters as much as deployment. The preview registry commands are the public surface for understanding what exists, bringing state back in sync, and tearing down preview-only resources deliberately.
- Best for
- Preview lifecycle management after deploys already exist
- Registry backing
- D1 ( by default)
- Cleanup warning
- Dedicated preview workers may own more than just the worker script
Why the preview registry exists
Cloudflare discovery alone is not enough for a clean preview lifecycle story. The D1-backed registry lets Devflare track preview, alias, and deployment records in a way that supports reconciliation, retirement, and cleanup commands later.
creates or reuses the default database, and later deploy flows try to keep that registry synchronized as preview deploys happen. If that sync warns or falls behind, is the documented recovery path.
That is what lets preview operations stay a documented CLI surface instead of becoming a pile of CI-only command glue.
The core commands to remember
- Use for a summary view of preview scopes.
- Use when you want to understand which workers currently reference one named preview scope; otherwise the identifier comes from the same preview env vars your automation already set.
- Use when registry state needs to be synced against current Cloudflare state.
- Prefer explicit scope selectors when you know the target, and reserve broad cleanup runs for the moments when the whole preview fleet genuinely needs attention.
- Without , first respects , , or , and only then falls back to the synthetic scope. Use when you mean every discovered scope for the worker family, not just that resolved default.
Preview lifecycle commands
Cleanup should be specific
- retires matching registry records by branch, alias, version, or commit selector; it does not delete the underlying Cloudflare resources by itself.
- soft-deletes stale registry records after an age threshold instead of immediately pretending the historical metadata never existed.
- deletes preview-only resources and can also delete dedicated preview worker scripts for the targeted scope.
- Stable shared workers are not deleted by ; same-worker preview aliases only lose matching preview-scoped account resources.
- Analytics Engine datasets and Browser Rendering bindings are reported as warnings instead of deleted resources, and preview-scoped Hyperdrive cleanup only removes preview configs that already exist.
Good cleanup hygiene
Use the most specific selector you can. Cleanup is easier to trust when the target is obvious in the command itself.
Not every preview-looking thing is a deletable resource
Browser Rendering does not own an account-scoped resource, Analytics Engine datasets are created on first write, and Hyperdrive preview cleanup can only remove preview configs that already exist. The command tells you about those cases instead of pretending it deleted them.
Previous
devflare/cloudflare
The subpath exposes the same account-aware building blocks the CLI uses for auth, resource inventory, usage and limits, preview registry access, preferences, and managed token workflows.
Next
Testing & automation
Keep local harness detail on the dedicated testing pages, then promote only the right runtime-shaped checks into thin, observable automation.