The same bindings, not a copy
In dev mode the studio runs inside the same workerd process as your worker, wired to the same D1, KV, R2 and Durable Object instances. Not a mirror synced over disk — the same objects.
Local-first developer tooling
Attach to the dev server you already have running, or let local-cf boot your worker and the studio in one runtime — where the dashboard reads and writes the exact same D1, KV, R2, Durable Objects and Queues your code does.
$ npx local-cfRead-only, so a first run cannot break anything. To edit, runnpx local-cf dev
No Cloudflare account. No sign-up. Nothing leaves your machine.
Everything the studio shows comes from the runtime your worker is actually using.
In dev mode the studio runs inside the same workerd process as your worker, wired to the same D1, KV, R2 and Durable Object instances. Not a mirror synced over disk — the same objects.
A static build shipped inside the npm package and served by the sidecar itself. No hosted domain, no account, no network.
Attach mode shares files, not memory. Every binding says which it is, so you always know whether you are looking at live Durable Object state or yesterday's flush.
Apply and track D1 migrations, import and export KV, and snapshot the whole local state before a risky change.
The sidecar is a Hono app and the dashboard consumes it through hc<ApiType>. Routes and UI cannot drift, with no OpenAPI document in between.
Every write made through the dashboard is recorded, and the ones with a recoverable inverse can be undone.
Each one is honest about what it can and cannot reach. Pick the one that matches how you work.
$ npx local-cf devThe studio runs inside the same workerd process as your worker, wired to the same binding objects. Not a mirror synced over disk — the same objects.
Run either one in your worker’s directory and the studio opens on the state you already have.
$ npx local-cfBrowse$ npx local-cf devEdit