Keep runtime posture and deployment shape in authored config instead of scattered deploy conventions
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.
Devflare exposes several config lanes that are not about file discovery at all. These keys shape runtime identity, Cloudflare compatibility, deployment routing, assets, release behavior, and operational posture, so they belong in authored config where the team can review them accurately.
- Best for
- Projects that need explicit runtime posture and delivery shape beyond the basic file surfaces
- Forced compatibility flags
- and
- Routing split
- is app routing, while top-level is Cloudflare deployment routing
- Preview cron default
- defaults to
Set runtime identity and compatibility posture explicitly
Not every package needs the full advanced runtime section on day one, but once remote bindings, compatibility drift, or account-aware operations matter, these settings should move into config instead of living in loose scripts and remembered defaults.
The important habit is that runtime posture should be reviewable in source control. If a package relies on a specific compatibility date or a specific Cloudflare account, that fact should be obvious before the deploy step runs.
| Key | Use it when | Important behavior |
|---|---|---|
| Remote bindings, name-based resource lookup, or account-aware commands should target one Cloudflare account explicitly. | Remote AI and Vectorize flows need a clear account, and config-level becomes one resolution lane for account-aware operations and config-driven resource resolution. | |
| The package should pin runtime behavior instead of inheriting date drift. | Devflare defaults it to the current date when you omit it, so explicit pinning is the safer choice once the package is real. | |
| You need extra Workers compatibility flags beyond the default posture. | Devflare always includes and , so custom flags should be deliberate additions instead of copy-by-habit repetition. |
Do not restate the forced flags unless you are making a point
Devflare already includes and . Keep focused on the extra posture your package actually needs.
Choose the Cloudflare endpoint model first
Cloudflare documents three inbound endpoint models for Workers: Custom Domains, normal Workers routes, and the automatic route. They are not interchangeable, and Devflare keeps that distinction in the top-level config instead of inventing a second routing vocabulary.
Use a Custom Domain when the Worker is the origin for a whole hostname. Use a normal Workers route when a Worker should sit in front of an existing proxied hostname, match a wildcard host, or match a path prefix. Use for getting started or preview-style reachability, and disable it when production should only be reachable through your own domain.
| Goal | Devflare config shape | Cloudflare behavior |
|---|---|---|
| Worker owns every path on one hostname | Custom Domains match the exact hostname; paths and query strings do not participate in the match. | |
| Worker intercepts a path or wildcard host in a Cloudflare zone | Normal routes use route patterns, may include , and the most specific matching route wins. | |
| Worker remains reachable on the account subdomain | Default generated Wrangler config keeps . | Cloudflare assigns ; Cloudflare recommends routes or custom domains for production. |
Routes can sit in front of Custom Domains
Cloudflare treats a Worker on a Custom Domain as an origin. A more specific normal route on the same hostname can run first, then call to invoke the Custom Domain Worker behind it.
Same-zone fetch is different for routes and Custom Domains
Cloudflare documents that Custom Domains can be invoked by same-zone , while normal routes cannot be the target of same-zone and should use service bindings for Worker-to-Worker calls.
Custom Domain for a Worker-owned hostname
Workers route for path or wildcard matching
Disable workers.dev when only custom endpoints should serve production
Keep deployment shape in config, not in app routing or shell scripts
Several config keys answer deployment questions rather than application-routing questions. Keeping those lanes separate is what stops app URLs, Cloudflare routes, and dev-only WebSocket proxy behavior from collapsing into one blurry story.
If the package serves static assets, mounts a custom domain, or proxies Durable Object WebSockets in development, that shape should live in config beside the rest of the deployment contract.
Custom Domains are host-only: use with a bare hostname such as . For wildcard or path matching such as or , use a normal Workers route with or instead.
| Key | What it controls | Common use |
|---|---|---|
| Static asset directory plus optional binding name | Point Devflare at one static directory and keep asset delivery visible in source. | |
| Cloudflare deployment route patterns | Attach the Worker to host or zone patterns at deploy time. | |
| Dev-mode Durable Object WebSocket proxy patterns | Forward development WebSocket paths into Durable Object namespaces explicitly. |
Top-level is not the same thing as
controls your app route tree. Top-level controls Cloudflare deployment routing. Keep those ideas separate so the package stays reviewable.
Custom Domains are not wildcard routes
Cloudflare Custom Domains match the hostname exactly and ignore paths. Do not add when ; a request to any path on that hostname will already invoke the Worker.
One place for runtime posture and deployment-facing settings
Put release and operational controls in source control too
Once a package has Durable Object history, production traffic expectations, or explicit preview behavior, the runtime contract is no longer just “what files exist?” It also includes how that package should be migrated, sampled, and limited at runtime.
These settings belong in the same config as the Worker surfaces. They are part of the deployable contract, not just garnish around it.
| Key | Why it exists |
|---|---|
| Choose whether branch-scoped preview deploys keep cron triggers instead of omitting them to avoid shared-schedule conflicts. | |
| Declare CPU expectations in config rather than treating them as after-the-fact deploy tuning. | |
| / | Keep tracing or sampling posture explicit for the environments that need it. |
| Track Durable Object class lifecycle in the same source-controlled package that owns those classes. |
Durable Object migrations still deserve explicit release thinking
Keep migrations authored in config and remember that plain preview uploads do not apply Durable Object migrations. If the preview must exercise real Durable Object lifecycle changes, use the preview strategy that matches that reality.
Previous
Previews
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.
Next
Runtime context
Use explicit event parameters at handler boundaries, then use , , , , , , and inside helper code that runs during the same request or job.