Your machine is powerful. Development should feel like it.

doze is docker-compose for local development, without the virtualization. The moment a VM enters the picture your fans spin up, your RAM is spoken for, and your debugger is on the wrong side of a boundary. doze runs Postgres, Valkey, a Mongo-compatible store, local S3/SQS/SNS — real, unmodified engines — as native processes on your machine. Declared in one file, booted when something connects, asleep when you walk away.

Get started Why doze?

# doze.hcl — your whole local backend, declared
postgres "app"   { version = 18 }
valkey   "cache" { version = 9 }

s3 "uploads" {
  port       = 9000
  versioning = true
}

$ brew install doze-dev/tap/doze
$ doze up
  ✓ app (postgres 18) ready   ✓ cache (valkey 9) ready   ✓ uploads (s3) ready
$ doze status
  ● app     postgres 18   active   127.0.0.1:5432   42.5M
  ○ cache   valkey 9      asleep   —                —      # zero cost until used

The point

Containerization is great — for shipping. For development, convenience made it acceptable to be resource-hungry: a VM holding half your RAM all day, the whole stack running while you edit one service, remote-k8s dev loops with latency where your inner loop should be. doze reverses that bargain.

Your fans stay off

No VM, no reserved slab of RAM. At rest, your entire backend is one ~15 MB daemon; engines boot on first connection and reap to zero when idle. The machine’s power goes to your build, not to virtualization.

Your debugger just attaches

Everything is a native process on your kernel. dlv/lldb attach directly, ps/lsof/Instruments see the real engine, core dumps land on your disk. No boundary, no port-forward mazes, no bind-mount heisenbugs. The debugger story →

Real engines, exactly

The actual upstream Postgres 18, the actual Valkey — not images, not emulations. Every extension and wire feature behaves like production, pinned to the byte in doze.lock for your whole team.

Pick your path

Use doze

Install it, declare your backend, get on with your app. Install → · Getting started → · Coming from docker-compose →

Understand it

The full case: native processes vs containers, why HCL, and an honest look at the alternatives. Why doze →

Build a module

Every engine is a plugin, and third-party modules are exactly as capable as official ones. Start from a working template. Author guide →

Run a registry

Modules arrive signed, key-pinned, and locked — and the registry is static files you can host yourself, air-gapped included. Operator guide → · Browse modules →