Maintenance & Recovery

Open /system/operations for Worker configuration, database lifecycle tools, backups, and administrator recovery. These tools use an IP allowlist and an Operations token, independently of ordinary Studio permissions.

Enable the Operations Boundary

Both values must be valid before protected Operations actions are available:

Setting	Storage	Requirement
STUDIO_OPERATIONS_ALLOWED_IPS	Plaintext Variable	Comma-separated exact IPv4 or IPv6 addresses; CIDR ranges are not supported
STUDIO_OPERATIONS_TOKEN	Secret	32–256 printable ASCII characters from ! through ~, without spaces

Generate the token independently, for example with openssl rand -hex 32. The setup guide can also generate it in the browser. Add it to Worker configuration yourself; the guide does not save it to Cloudflare.

Configuration and caller	Entry behavior
Either value missing or invalid; non-operational site mode	Setup guide
Either value missing or invalid; operational mode and active administrator session	Setup guide
Either value missing or invalid; operational mode without that session	Not found, without a sign-in prompt
Both values valid; caller outside the allowlist	Not found before any credential form
Both values valid; allowed IP	Token entry, subject to the site mode’s session and operation requirements

In operational mode, protected Operations also requires a signed-in Studio administrator. Maintenance and recovery do not require a normal session; specific actions may still re-verify an administrator’s password.

Entered Operations credentials stay in page memory. Reloading or leaving the area locks it again. Remove the allowlist variable to disable protected access when it is no longer needed. Setup guidance remains subject to the rules above.

The environment display validates values but cannot distinguish Cloudflare Secrets from plaintext Variables at runtime. Store the token as a Secret.

Client IP

Deployed Studio uses the validated CF-Connecting-IP address and ignores X-Forwarded-For. Operations matches the normalized address against its exact allowlist.

Vite development and preview use the socket peer for direct connections. For a loopback connection with a single <name>.trycloudflare.com Host, Studio accepts one valid CF-Connecting-IP from Quick Tunnel. This assumes trusted local processes. A missing or malformed tunnel IP is rejected rather than replaced with the relay’s loopback address. LAN requests cannot obtain loopback privileges by supplying a localhost or tunnel Host header.

This development policy covers the Cloudflare Vite Quick Tunnel, not Named Tunnels or arbitrary reverse proxies. In Vite, press t + Enter to start or stop the Quick Tunnel. Refresh the setup guide’s current IP after changing a network or VPN.

Studio Database Upgrade

When the database reports upgrade_required:

1. Switch Studio to maintenance and open Operations.
2. Retain a Studio SQL backup.
3. Open the highlighted Studio database page and Upgrade Studio database section.
4. Review the available steps, re-verify an administrator, acknowledge the backup, and confirm UPGRADE STUDIO DATABASE.
5. Wait for the ready result, then return to operational.

The runner applies supported consecutive schema steps. Each committed step is a retry boundary: after interruption, reopen Operations and continue the remaining steps. An upgrade does not change site mode automatically. Use the supported workflow instead of applying SQL artifacts or Wrangler D1 migrations.

If administrator credentials also need recovery, complete MFA Recovery first in recovery mode, then return to maintenance for the upgrade.

Worker Rollback and Database Compatibility

DATABASE_NEWER_THAN_CODE means the stored schema is newer than the running Worker supports. A Worker rollback does not undo a database upgrade.

The entry screen shows the available release and schema information. Deploy compatible Studio code and verify that DB points to the intended database, then check again. Keep the database; do not reinstall it or edit its version number to bypass compatibility checks.

Edge Database Lifecycle

Studio and Edge have independent schemas and backups. Studio’s default installation initializes an empty Edge catalog, but preserves a non-empty one and starts with integration disabled.

After installation, Operations offers actions according to the inspected state:

Action	Studio mode	Purpose
Install	Maintenance	Initialize an empty Edge application catalog
Adopt	Maintenance	Register an exact supported unversioned catalog and seeds
Upgrade	Operational or maintenance	Apply supported consecutive Edge schema steps
Reconcile targets	Maintenance	Align comment targets with Studio content and review orphans

These actions require the reported Studio/Edge prerequisites and administrator re-verification. Pause public Edge traffic with EDGE_MAINTENANCE_MODE=true and preserve an Edge backup before changing existing data. Consider pending mail Queue work when upgrading incompatible contracts; a schema upgrade does not migrate messages already in the Queue.

A successful operation does not enable Studio integration or reactivate the public Worker. Restore those settings explicitly after verifying readiness.

Edge Target Reconciliation

Reconciliation processes pending projections, upserts Studio Posts and Pages, and identifies targets present only in Edge. Review those orphans before purging them: target deletion also deletes its comments. Changed or revived targets are skipped.

Resume interrupted work from its saved state. Cancelling removes reconciliation state but keeps completed projections. Completion requires no pending or unreviewed work and verified target parity. Enable integration after Edge Services reports readiness.

Search, Backup, and Access Recovery

• Content Search explains Dashboard rebuilds and Operations-only forced restart or recovery.
• Backups & Restore covers supported SQL artifacts, interrupted restores, R2, and Secrets.
• MFA Recovery covers account setup links and last-administrator recovery.
• Cloudflare Access covers recovery from a saved requirement bound to an old origin or policy.

Destructive Operations

Action	Mode	Main effect
Clear Content	Operational or maintenance	Remove content and Media metadata while preserving accounts, settings, Widgets, and audit records, with content-reference adjustments
Reset Studio	Maintenance	Remove content and site configuration; preserve the verified administrator’s credentials, Studio-level settings, and audit records
Uninstall Studio	Maintenance	Remove the Studio application schema and accounts; leave Cloudflare resources, R2 objects, and Edge DB
Uninstall Edge	Maintenance	Remove a matching managed Edge schema while Studio integration is disabled

Clear Content resets a deleted Page front page to the theme index and clears branding Media selections. Reset additionally removes other accounts and sessions. Both preserve public content-ID counters so deleted IDs are not reused.

When Studio Edge integration is enabled, Clear and Reset perform their specified Edge cleanup first. With integration disabled, Edge is skipped. These are separate database writes: an Edge success followed by a Studio failure is not rolled back across databases. Read the result and retry the same supported workflow as directed.

Clear and Reset queue managed R2 keys for cleanup; failed cleanup remains pending for retry. External files are not physically removed. Uninstall leaves R2 objects in place and removes pending cleanup records with the schema.

Destructive actions require re-verification and the displayed confirmations. They do not create backups automatically. Active rebuild, restore, upgrade, or reconciliation work can block incompatible operations until completed.

Audit Log records major outcomes. After Studio uninstall, completion is available through Worker logs. To install again, use initial mode and a new installation token while preserving the intended resources.