Use the operator command families for account context, live production changes, renames, token bootstrap, and paid-test gates
Devflare’s deeper CLI families exist so account selection, live production inspection, Worker renames, token lifecycle, and remote paid-test gates stay documented instead of dissolving into ad-hoc command snippets.
The root CLI page maps these command families, but once you start operating real Cloudflare state, the important questions change. Which account is this command acting on? Is this a read-only production inspection or a dry-run rollback? Does this rename update the local config too? Should remote paid tests be enabled at all? This page keeps those answers in one place.
- Best for
- Teams operating live accounts, releases, and paid test flows instead of only building locally
- Read-only production view
- and
- Mutation safety habit
- Prefer dry runs first, then add only when the target is obvious
- Paid-test gate
- plus awareness
Choose account context before you operate on anything important
The safest operational habit in Devflare is to resolve account context first. The CLI can infer an account from several places, but when real inventory, preview cleanup, token management, or production control-plane changes are involved, you should know which lane won.
Not every command family resolves those lanes in the same order. Inventory-oriented commands, discovery, other config-backed operator commands, and token management each consult a slightly different subset of explicit flags, workspace settings, environment, config, and authenticated-account fallbacks.
, , and the global or workspace account selectors exist for this reason. They make the account story explicit before the deeper command families start reading or mutating Cloudflare state.
| Command family | How account choice resolves | Practical habit |
|---|---|---|
| wins, then workspace account selection, , resolved config , and finally the primary authenticated account. | Great for inventory, but still pass when a read or write must be unmistakable. | |
| wins. Otherwise Devflare may scan local configs for primary workers, stop with an explicit error if that scan finds more than one configured , and only then fall back to the narrower production account-resolution path. | In a monorepo or mixed-account tree, pass instead of asking productions to guess. | |
| Other config-backed families such as and | Explicit wins; otherwise Devflare can use resolved config or later fall back to effective-account preferences and the authenticated account. | Set in package config when that package genuinely belongs to one account. |
| Uses first, then workspace account selection, then the primary account visible to the bootstrap token. | Treat token management as its own lane and make the target account obvious in logs. |
Interactive account selection is a real workflow, not just a convenience extra
and exist so repeated operational commands can stay honest without pasting account ids into every invocation.
The workspace preference lives with the workspace metadata, while the global default is cached locally and mirrored best-effort to Devflare-managed Cloudflare state when you are authenticated.
Some command families consult those effective-account preferences directly, while others read a narrower lane first. That difference is why the docs call out the command family instead of pretending there is one universal resolution order.
is the strictest example here: if local config discovery turns up multiple configured account ids, it refuses to guess and asks for .
Fail an operator script when the expected account is not active
Use the same account helpers as the CLI when automation needs a hard preflight instead of a human-readable inventory page.
Get the account context visible first
Treat usage and limits as Devflare-managed guardrails, not Cloudflare billing dashboards
and expose the counters and ceilings Devflare uses for its own safety decisions. They are useful operator data, but they are not a full Cloudflare billing or quota dashboard.
Today that mostly means AI request counts, Vectorize operation counts, and related limits that help Devflare decide when remote or preview-heavy workflows should stay deliberate instead of accidental.
- Use these commands as guardrails for Devflare-managed flows, not as the final source of truth for account billing.
- If you need official product usage or invoice-level numbers, keep Cloudflare’s own dashboards and docs in the loop.
- Some limits are stored for future enforcement or reporting before every one of them becomes an active hard stop.
Operationally useful, intentionally narrower than billing
These numbers are here to help Devflare behave safely. They should inform operator decisions, but they are not a substitute for Cloudflare’s own product-level accounting.
Inspect and change live production deliberately
is the control-plane surface for live production state. It reads Cloudflare deployment data directly, lists current Workers and stored versions, and only mutates production when you move from the read-only views into or .
That split matters because production inspection and production mutation are not the same job. Keep nearby when you need context, keep dry runs as the default posture, and add only when you are already confident about the target.
| Command | What it is for | Safety rule |
|---|---|---|
| Inspect live production Workers and the active deployment shape. | Read-only by default. | |
| Inspect recent stored production versions and see which version is active. | Read-only by default. | |
| Create a fresh production deployment that points at a previous or specific version. | Dry run unless you add . | |
| Delete one live production Worker script. | Dry run unless you add , and it does not delete independent account resources automatically. |
Production versions are a focused view, not the entire deployment history
focuses on the recent non-preview versions that matter operationally, and the latest production deployment can still reference more than one active version when Cloudflare is splitting traffic.
Production deletion is intentionally narrow
removes the Worker script only. Review KV, D1, R2, queues, and other account resources separately instead of assuming the control plane will clean them up for you.
Use documented commands for renames, token bootstrap, and pricing context
Renames the remote Worker when needed, updates the matching local config name when it can resolve that config safely, warns about remaining local references, and may leave existing preview URLs showing the old worker name until fresh preview uploads exist.
Creates, rolls, lists, and deletes Devflare-managed account-owned API tokens using a bootstrap token that already has token-management permissions. Created tokens include the selected account and all zones in that account so deploys can manage Worker route and custom-domain state. Cloudflare returns token secrets only once, so the first output matters.
Prints the built-in Workers AI pricing snapshot bundled with the current Devflare build. It is a reference command, not a live account-state query, so confirm current rates in Cloudflare docs when the numbers matter.
- Prefer over hand-editing config names and remote Worker names separately.
- Keep bootstrap tokens out of transcripts and remember that returned managed-token secrets are a one-time output.
- Use the built-in AI pricing command when the question is cost reference, not model invocation.
Keep these control-plane jobs explicit too
Gate paid remote test flows explicitly
Remote mode exists so paid Cloudflare features like AI or Vectorize do not get exercised casually by every local or CI run. The command family is deliberately small: inspect current status, enable it for a bounded window, or disable it again.
That keeps the cost story visible. If remote tests are going to hit real infrastructure, the activation should be reviewable in command history or workflow logs instead of quietly implied.
- The default action is , so the current gate is easy to inspect before you run a paid test suite.
- defaults to 30 minutes when you do not pass a valid duration.
- can keep effective remote mode active even after you run , so environment context still matters.
Remote mode is a cost gate, not a convenience toggle
Remote tests hit real Cloudflare services. Use the shortest useful enable window and keep the activation visible in automation when cost or quotas matter.
Make remote mode a deliberate choice
Use the neighboring docs when the job becomes preview lifecycle or CI policy
Ship & operate
devflare/cloudflare
Open the library API page when a script or tool should use the same auth, inventory, registry, usage, or token helpers that the CLI command families use internally.
Ship & operate
Preview operations
Open the preview lifecycle page when the job is inspection or resource cleanup for preview scopes.
Ship & operate
GitHub workflows
Open the workflow page when those operator commands need to become reviewable CI jobs with feedback, cleanup, and permissions.
Ship & operate
Production deploys
Open the production deploy page when the question is the deploy target itself rather than the later control-plane inspection or rollback flow.
Previous
Preview strategies
Same-worker uploads, named preview scopes, and branch-scoped worker families serve different needs.
Next
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.