Development environments
The planned workflow: a persistent core environment and private data forks for agent tasks.
Keep a core environment for the project
Planned workflow. Each project has a persistent core environment following a branch, normally main. It records the applied code revision, runtime, configuration and data identity. Updating code preserves its application data and runs explicit migrations before the new version becomes ready.
The core can be your development or staging service. It is not an agent's disposable scratch space. Rolling back code does not automatically reverse a database migration.
An optional start command, with sleep and wake
A project will be able to declare its existing dev command, working directory, readiness check and exposed ports. For example, a repository may already use pnpm dev. Projects without a server can leave the command unset.
The managed service will retain files and application data when sleeping, then start or resume compute and check readiness on wake. The policy must distinguish retaining process RAM from restarting processes. These application settings are planned; they are not fields accepted by today's template manifest.
Current VM pause/resume is available. Pause keeps RAM allocated. A clean stop releases compute and requires a boot. LayerFS-attached VMs do not yet support coordinated RAM hibernation.
Publish a consistent revision from the online core
- Identify the code, schema, bindings and runtime versions to capture.
- Capture application data with a database-aware adapter and any required brief write barrier.
- Prepare and validate an immutable candidate outside the core's live writable data.
- Publish its versioned manifest only after every component succeeds.
The core remains the persistent service. “Online” does not promise zero write interruption: multiple databases and background writers may need a short coordinated barrier. An interrupted publication must leave the previous revision available.
Filesystem branching is one part of this design. Copying a live SQLite file alone does not capture its WAL or establish consistency across services.
Give every task its own writable data
An agent environment starts from an exact published revision, reusing prepared code and dependencies. Its databases, generated files, endpoint and native agent home are private writable state. Two independent runtimes must not share the same writable SQLite persistence directory.
Later core changes do not silently appear in an existing fork. Refresh deliberately by creating a new fork or using an application-specific import. Return code through Git review; return data through explicit migrations or imports. There is no automatic database merge.
Shared project services remain possible through explicit APIs and permissions. A shared service and an isolated data fork have different semantics.
What exists and what comes next
Native workspaces, templates, VM lifecycle and LayerFS checkout branching are implemented. An earlier local Wrangler experiment proved seed inheritance, independent writes and restart across two data forks.
The core registry, main-branch reconciliation, owned application startup, sleep/wake endpoint lifecycle and online publication adapters remain planned. Cloudflare local bindings are the first intended recipe. Read the Cloudflare guide or the full architecture contract.