Author preview-scoped bindings so preview deploys can own disposable infrastructure
Use for bindings that should belong to one preview scope. Devflare materializes names like , provisions or reuses the preview-only resources it can manage, and lets you clean them up by the same scope later without touching production resources.
Preview config in Devflare is not only “set and hope for the best.” The extra step is marking the bindings that should belong to a preview deployment. Devflare then materializes those names with a preview identifier, keeps production names separate, and on preview deploys can create or reuse the matching account resources for the binding types it manages locally.
- Authoring primitive
- from
- Typical result
- → for a preview scope
- Main lifecycle command
- Best for
- Previews that need their own disposable state instead of borrowing production infrastructure
Mark preview-owned bindings in config instead of mutating production names at deploy time
The point of preview-scoped bindings is not to make names look fancy. It is to keep preview infrastructure isolated from production infrastructure while still authoring one readable config.
returns an opaque marker around the base resource name. Devflare later materializes that marker into a real name for the active preview identifier, which means the authored config can stay stable while preview deploys resolve to preview-owned databases, buckets, queues, and other resources.
This is safer than repointing previews at production state
When the preview owns a distinct database or queue name, it can be created quickly, reviewed in isolation, and deleted cleanly later. That is much safer than hoping reviewers never touch a production binding in a preview session.
Author preview-owned bindings once, then let the scope decide the real names
The preview identifier is materialized into the binding target name
In normal local work and non-preview environments, a preview-scoped marker resolves back to the base name. In preview resolution, Devflare inserts the chosen preview identifier using the configured separator, which defaults to .
The identifier order is deliberate: an explicit identifier wins first, then , then PR or branch-derived env values, and only then the synthetic fallback for generic preview environments.
- The binding name in stays the same; it is the backing resource target that changes by preview scope.
- Production overrides can still point at explicit production resources when production naming should be fully separate from preview naming.
- This page is about resource naming and binding targets; preview worker topology is a neighboring decision covered by the preview strategy docs.
| Authored binding target | When it resolves | Resolved name | What that means |
|---|---|---|---|
| Local work or non-preview resolution | The base config stays readable and does not invent preview names unless a preview identifier is actually in play. | ||
| Plain or generic preview environment | The synthetic identifier keeps same-worker preview uploads separate from the base resource name. | ||
| Named preview like or | A named preview scope gets its own clearly-associated resource names and cleanup target. | ||
| Branch-derived identifiers are sanitized into safe resource-name fragments. | |||
| Custom separator plus preview identifier | You can change the separator when the resource naming convention needs it. |
Some preview-scoped bindings are lifecycle-managed resources, and some are not
| Binding lane | Preview naming story | Lifecycle behavior |
|---|---|---|
| KV, D1, and R2 | Author the resource name with . | Preview deploys can create or reuse the scoped resource, and cleanup can delete it later by the same scope. |
| Queues and DLQs | Producer, consumer, and dead-letter queue names can all be scoped. | Preview deploys can provision the queue resources and cleanup can remove them together. |
| Vectorize | Index names can be preview-scoped too. | Devflare can provision the preview index shape from the base index metadata and delete it during cleanup later. |
| Hyperdrive | Names can be materialized for preview scopes. | Devflare does not auto-clone stored credentials, so it warns and can fall back to the base Hyperdrive binding when the preview config does not already exist. |
| Analytics Engine and Browser Rendering | Dataset or binding names can be materialized. | Devflare reports warnings instead of provisioning or deleting account resources because those families do not follow the same managed lifecycle. |
| Service bindings, Durable Objects, and routes on dedicated preview workers | Isolation follows preview worker names and ownership more than account resource naming. | Deleting dedicated preview worker scripts also removes preview-only service bindings, Durable Object bindings, and routes attached only to those workers. |
Preview-scoped does not automatically mean Devflare can provision everything
Hyperdrive, Analytics Engine, and Browser Rendering each have their own lifecycle caveats. Devflare says that out loud instead of pretending every binding behaves like KV or D1.
The good preview loop is deploy, inspect, and clean up by the same scope
Preview-scoped bindings work best when the scope stays explicit from deploy through cleanup. The preview deploy resolves the config to preview-owned names, the binding inspection command shows exactly what that scope points at, and cleanup removes the same preview-only resources later.
That is what keeps previews fast to create and safe to tear down. The preview owns its own binding targets, so deleting it does not mean touching production databases or buckets just because the app used the same binding names in code.
Configuration
Need the overlay story too?
Open the environments page when the question is which config lanes differ by preview or production beyond resource naming.
Ship & operate
Need the preview topology decision?
Open the preview strategy page when the real question is same-worker uploads versus branch-scoped worker families.
Ship & operate
Need lifecycle and cleanup commands?
Open preview operations when the question moves from authoring config to registry inspection or cleanup policy.
- 1
Author preview-owned bindings with in the main config.
- 2
Deploy the preview with an explicit scope such as when the resource names should map to one known preview deployment.
- 3
Inspect that scope with when you want the resolved targets and worker associations spelled out clearly.
- 4
Clean up the same preview later with .
One scope in, the same scope back out
Previous
Typed env vars
Use descriptors inside , parse or default them in config, and read the resulting typed values at runtime with .
Next
Runtime & deploy settings
Use config for account context, compatibility posture, assets, deployment routes, WebSocket proxy rules, migrations, observability, limits, and preview cron behavior instead of rediscovering those settings in scripts later.