Build and deploy production on purpose, with explicit targets and inspectable output
Devflare keeps build and deploy flows inspectable, but deploys are intentionally explicit: production uses or , while preview is either a same-worker upload with plain or a named preview scope with .
The deploy story is simpler when the target is unmistakable. Devflare resolves config, generates Wrangler-facing artifacts, and then deploys against an explicit destination instead of guessing whether you meant production or preview.
- Best for
- Production deploys and preflight checks
- Required target
- , , plain , or named
- Best debug habit
- Inspect compiled output before you deploy when the setup changed
Keep the production lane small and reviewable
The CLI page already owns the broad command map. The production-specific habit is simpler: refresh generated types when the contract changed, build once, inspect when the setup changed, and only then deploy with an explicit production target.
That keeps this page focused on release posture instead of re-explaining command families that already have a better home on the CLI page.
- 1
Run when bindings or entrypoints changed and needs to catch up.
- 2
Run to materialize the production shape you actually mean to ship.
- 3
Use or when the compiled result needs inspection before release.
- 4
Run or only when the target is unmistakably production.
Need the full command map?
Open the CLI page when the question is what , , , or generally do. This page only covers how those commands fit the production release lane.
Production deploys should be explicit
Deploy requires an explicit target so production and preview destinations stay unmistakable. That means production is or , while preview is either plain for a same-worker upload or for a named preview scope.
Production deploys also clear preview-scope environment overrides such as , which helps keep stable production worker names pointed at the stable infrastructure you actually expect.
No target means no deploy
That rejection is intentional. It keeps production and preview intent visible in CI logs, scripts, and local command history.
Automation can make verification stricter than local deploys
The reusable deploy action exposes and so CI can fail when Cloudflare cannot confirm the expected version or keeps serving the existing active production deployment.
Production deploy commands
Use the inspectable tools before a risky change
- Run when you want to see the compiled deployment shape.
- Run when config resolution, Vite opt-in, or generated files feel suspect.
- Run before deploys when the package just gained new bindings, routes, or framework wiring.
Previous
GitHub workflows
This repository keeps GitHub workflows small on purpose: caller workflows own triggers, permissions, and package selection, while shared Devflare actions handle impact checks, deploy execution, and feedback publishing.
Next
Monorepos & Turborepo
In a Bun monorepo, Turborepo should own task orchestration, caching, and impact-aware validation, while still runs from the package that owns the Worker or app you are deploying.