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 honestly.
- 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 on purpose
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 calmer 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.
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.
| 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.
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.
That is why 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
Devflare-managed entrypoints create a rich surface event, store , , , , , and the original event in , then expose that state through helpers such as , , , and the , , , and runtime proxies inside the same handler trail.