Pick the preview model that matches the app instead of forcing one preview story on every worker
Devflare supports both same-worker preview uploads and named preview scopes, but Durable Object-heavy apps often need a branch-scoped worker-family strategy instead of relying on preview URLs alone.
Preview complexity usually comes from choosing the wrong model, not from the commands themselves. This page helps you pick the right one before you start writing CI around assumptions that the platform will not actually honor.
- Best for
- Choosing preview strategy before building CI around it
- Same-worker mode
- Plain
- Named scope mode
There is more than one preview model
Both preview targets resolve and can materialize names. Bare keeps the same-worker preview upload flow and uses the synthetic identifier, while named swaps that identifier for an explicit scope and can pair naturally with branch-scoped preview workers when your config is wired for that pattern.
Plain can still derive alias metadata from , CI metadata, or the current git branch, but that alias is separate from the synthetic identifier used for preview-scoped resource names.
The action metadata in this repo still carries a input for same-worker uploads, and some live workflows still use it. Treat that as repo drift rather than a second CLI deploy target model. New automation should lean on -style alias derivation or just use named preview scopes directly.
| Preview style | Use it when |
|---|---|
| Plain | You want a same-worker preview upload and the synthetic identifier is enough for any resource names. |
| Named | You need an explicit preview identifier for resource names or branch-scoped preview workers. |
| Branch-scoped worker family | The app is Durable Object-heavy or otherwise needs stronger isolation than same-worker preview uploads can provide. |
Cloudflare caveats still matter
- Preview URLs must be enabled for the worker or the returned links may not be usable.
- Preview URLs are public unless you protect them with Cloudflare Access or another layer.
- Plain cannot be the first-ever upload path for a brand-new worker.
- Cloudflare does not currently generate preview URLs for workers that implement Durable Objects.
- does not currently apply Durable Object migrations.
- Same-worker preview uploads are also the wrong fit when branch isolation must cover cron or queue topology, not just the request path.
This is why DO-heavy apps need a different preview instinct
If previews must exercise real Durable Object behavior, reach for branch-scoped worker families and preview-scoped resources instead of hoping same-worker preview URLs will be enough.
Use preview-scoped resources only when the preview really owns infrastructure
Branch-scoped previews sometimes need their own KV, D1, R2, Queue, or Vectorize resources. That is where is useful: authored config stays stable while preview environments resolve preview-specific names.
Outside preview environments, those same authored markers resolve back to the base names so your config stays readable.
Inside preview deploys, bare usually materializes names like , while materializes names like .
Preview-scoped resource naming
Previous
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.
Next
Control-plane operations
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.