Treat as one documented CLI, not a bag of one-off shell snippets
Start at : the root page already maps local dev, inspection, deploy intent, account inventory, preview lifecycle, production control, token management, AI pricing, and remote-mode operations in one place.
Devflare’s CLI is the public control surface for the same authored config model the docs site describes. Most packages live in the boring loop, but the CLI also owns the surrounding control plane. Learn the root commands once, then drill into or nested pages when one family goes deeper.
- Best for
- Everyday dev, config inspection, explicit deploys, and the Cloudflare control-plane work around those deploys
- Fastest orientation
- Help depth
- Safest habit
- Run commands from the package that owns the you mean to resolve
Start with the root help page, then drill down
The root help page is not just a banner and a couple of examples. It is the best quick map of the whole CLI: core dev commands, deploy intent, inspection tools, and the deeper control-plane families all show up there first.
From there, the CLI keeps the same shape all the way down. and resolve to the same detailed guide, and nested families such as or keep going with their own subcommand help instead of forcing you to remember a maze of ad-hoc commands.
- Use the root help first when you are not sure which command family owns the job.
- Use command-specific help when the job is already obvious but the option vocabulary is not.
- Use nested help for the control-plane families that have real subcommand trees instead of pretending one page can explain them all.
The docs page should mirror the help tree
If the built-in help already describes the command surface cleanly, the docs page should explain that structure instead of flattening everything back into four example commands.
Use the built-in help tree as the CLI map
Know what each root command family owns
| Command | Primary job | What the deeper help covers |
|---|---|---|
| Scaffold a new package. | Template choice and generated starter scripts. | |
| Start local development. | Worker-only defaults, Vite auto-detection, service workers, runtime-port selection, logging, and persistence. | |
| Compile deploy-ready artifacts. | Environment resolution and Wrangler-facing output. | |
| Ship explicitly to production or preview. | Target selection, dry runs, preview naming, messages, and tags. | |
| Generate and typed bindings. | Custom output paths plus entrypoint and Durable Object discovery. | |
| Check local project health. | Config, package, TypeScript, Vite, scope-aware local/deploy artifact diagnostics, and optional plugin guidance. | |
| Print resolved config. | , raw Devflare JSON, compiled Wrangler JSON, and build/local/deploy resolution phases. | |
| Inspect Cloudflare account inventories and limits. | Resource lists, usage limits, and interactive global/workspace selection. | |
| Authenticate with Cloudflare via Wrangler. | behavior and reuse of existing sessions. | |
| Operate on preview lifecycle state. | , , and . | |
| Inspect and mutate live production state. | , , and . | |
| Run Worker control-plane operations. | Currently , plus config-sync expectations. | |
| Manage Devflare-managed account-owned API tokens. | List, create, roll, and delete managed tokens. | |
| Print the bundled Workers AI pricing snapshot. | Read-only pricing surface; verify current rates in Cloudflare docs when it matters. | |
| Toggle remote test mode for paid features. | , , and . | |
| Render root or command-specific help. | Nested help resolution for command families and subcommands. | |
| Print the installed version. | Same information as the global flag. |
Learn the shared option vocabulary once
The root help page also teaches the common option vocabulary. That matters because not every command supports every option, but the meaning stays consistent when the option exists.
If you already know what , , , and mean, the command-specific help pages get much easier to scan.
- is meaningful only on commands that actually resolve config environments.
- is not a fallback after confusion; it is the intended first stop for a new command family.
- When in doubt about which config file is being resolved, make explicit instead of trusting directory luck.
| Option | What it means | Where it matters most |
|---|---|---|
| Pick the exact file to resolve. | , , , , , , , and . | |
| Resolve before the command runs. | , , preview-aware inspection, and production discovery flows. | |
| Print stack traces and extra debug output. | Build, deploy, type generation, and other failure-heavy paths. | |
| Disable ANSI color output. | CI logs, copied transcripts, or plain-text debugging. | |
| Show the detailed help page for the current command path. | Every root command and nested subcommand surface. | |
| Print the installed version and exit. | Root invocation when you need to verify the installed package quickly. |
Use the root page as the map, then let deeper pages own the sharp edges
The root CLI page should tell you which family exists and what it is broadly for. Once a command starts operating on preview lifecycle, live production, account context, tokens, or paid-test gates, the sharper behavior belongs on the dedicated operations pages instead of being re-explained here in parallel.
Use the built-in help for exact flags, then use the docs pages below for the operational safety rules and workflow context around those command families.
Ship & operate
Control-plane operations
OperationsOpen this page for account selection, live production inspection, rollback or delete posture, worker rename, token bootstrap, and remote-mode gates.
Ship & operate
devflare/cloudflare
Library APIOpen this page when a script or tool should use the same account, registry, usage, and token helpers the CLI builds on.
Ship & operate
Preview operations
Preview lifecycleOpen this page when the question is preview registry inspection or resource cleanup.
Ship & operate
Production deploys
Deploy targetsOpen this page when the question is the deploy target and preflight inspection rather than later control-plane changes.
- Use , , , , and when you are operating real Cloudflare state instead of just building locally.
- Use when the job is preview lifecycle rather than day-to-day package development.
- Treat nested flows as command families that deserve both built-in help and the dedicated docs page before you run them.
The sharp edges live one level deeper
, , and all carry behavior and safety notes that are too specific for the root CLI map. Read their help and the dedicated docs page before treating them as copy-paste habits.
Most packages still live in one boring, reliable command loop
The most useful Devflare loop is intentionally repetitive: refresh generated types when bindings move, run local dev, inspect build output when the shape changes, and deploy with an explicit preview or production target.
That loop stays the same whether the package is worker-only or Vite-backed. The config decides the host; the command vocabulary stays familiar.
When the job changes from building to operating, switch command families instead of inventing ad-hoc command snippets: and for inspection, for preview lifecycle, for live production state, and for inventory questions.
- Run after binding or entrypoint changes so stays honest.
- Use or when another local project already owns the default 8787 runtime port.
- Use when you want local config inspection without Cloudflare account lookups.
- Use service bindings for local full-stack packages; Devflare starts those referenced workers in CLI dev and exposes them as Vite auxiliary workers for framework dev.
- Run or when the compiled shape matters more than the dev server feeling healthy.
- Use when generated deploy artifacts are intentionally absent during a local-only loop.
- Keep preview and production intent explicit in the final deploy command instead of hiding it in a generic script name.
- Use the nested help pages when a lifecycle command reaches , account selection, rollback, or cleanup territory.
Map the everyday CLI loop into package scripts
Keep scripts thin and explicit so local developers and CI both call the same Devflare command surface.
A good everyday command loop
When the setup feels suspicious, inspect before you improvise
Use the inspection and lifecycle commands before you improvise command snippets
Best when you need to see the resolved Devflare config or compiled Wrangler-facing shape before trusting a build or deploy.
Best when config resolution, generated artifacts, or local Vite detection feel hard to trace and need a sharper diagnostic pass.
/
Best when the question is no longer “can I deploy?” but “what exists right now, and what should I clean up, roll back, or inspect?”
Keep commands package-local
Run Devflare from the package that owns the config you actually mean to resolve. In monorepos, Turbo can decide what changed, but package-local commands still decide what gets built, deployed, inspected, or cleaned up.
Previous
Deploy and Preview
Take the same starter worker, ship one named preview, then remove that preview scope cleanly.
Next
Project Architecture
This is the practical answer to “what does a real Devflare project look like on disk?” — from a small worker package, to a multi-surface app, to a hosted SvelteKit package, to a Bun monorepo with several deployable workers.