Cloudflare development
A local Wrangler recipe is the first target for persistent core environments and isolated data forks.
Local bindings, persistent project data
Planned managed recipe. The core environment runs your Worker project through Wrangler, follows main and retains local application state between code updates. Its optional dev command starts the application; sleep and wake retain that state.
Local D1, KV, R2 and SQLite Durable Objects are the initial data targets. Connected Workers need their service bindings and startup configuration captured together. DuckDB is not required.
The current template catalog installs native development tools. It does not yet provide this managed Cloudflare environment or a main-tracking staging service.
Use one persistence directory per environment
Wrangler's local state normally lives under .wrangler/state; --persist-to selects an explicit location. The environment's runtime and local data-management commands must agree on that location. Pin the Wrangler, Miniflare and workerd versions used to create and consume a revision.
Every fork gets private writable state. Separate ports or Git branches do not isolate two runtimes pointed at the same database files. Remote bindings remain external services; a local filesystem snapshot does not clone them.
For current Wrangler behavior, consult Cloudflare's local-data documentation.
The earlier prototype did exercise data forks
A local experiment passed 15 checks on October 18, 2026. It ran two connected Workers per environment, copied a stopped parent's state, then ran the parent and two forks concurrently. Seeded D1, KV, R2, SQLite Durable Object and auxiliary Worker D1 data diverged independently and survived restart.
That test used an approximately 1.7 MB fixture and ordinary directory copies on macOS, with Wrangler 4.151.1, Miniflare 5.20261012.1-beta and workerd 1.20261012.1. It was not a LayerFS benchmark or an online snapshot implementation.
The evidence record identifies the adjacent research checkout and its saved results. It supplies a useful starting point for integration.
The next step is consistent online publication
The managed core should publish an immutable data revision while remaining a persistent service. A database-aware adapter must capture complete state and use a brief write barrier where several bindings need one consistent application point. Publication must fail safely without replacing the previous baseline.
Agent forks can then reuse that revision while keeping their own live data. Code returns through review; data changes require explicit migrations or imports. Queues, alarms, scheduled work and external side effects need their own restart and capture contracts.
LayerFS checkout tests do not yet qualify workerd, SQLite WAL/locking or database recovery over its Incus mount. Authoritative core data stays on separately qualified persistent storage. See the environment design and storage scope.