The doze family · a short manifesto
On rest
Why doze is built the way it is, in six short chapters. Quote any of it.
A stack should sleep.
Most of the day your stack does nothing. The database waits for a query that comes every few minutes. The queue holds three messages. The search index was last asked something before lunch. Everything is ready all the time, and you pay for that readiness in memory, battery and fan noise, from the moment you log in until you close the lid.
A service that sleeps when nobody calls and wakes when someone does isn’t a trick. It’s what you’d ask of any good colleague. doze keeps the rule short:
Asleep means no process.
Not paused, not throttled, not “idle”. Gone, with its data kept on disk, and back when your code calls. Rest is a feature. It’s the one we built everything else around.
Native processes, not a VM.
The usual way to run a database you’d rather not install is to run a computer inside your computer, and run the database in that. It works. It also means a second operating system, a second filesystem, a network between you and your own code, and the fan.
doze runs the real engines as ordinary processes on your machine. Postgres is postgres in your process list. A debugger attaches because nothing is in the way. The file you save is the file the service reads. And when something is asleep, pgrep finds nothing. You can check; that’s the point.
Your laptop is fast enough to run your stack. It always was. It just never got to rest.
Your machine is where development belongs.
When local development got painful, a lot of teams stopped fixing it and moved it: remote dev boxes, run by a platform team. For a while it felt like progress.
Then the debugger wouldn’t attach through the tunnel. The ports needed forwarding, again. The logs lived in another tool. And on the day the dev environment was down, no ETA, the platform team in another timezone or busy with production, nobody wrote any code. You needed a platform team just to write code.
Local development didn’t get fixed. It got moved.
All the while, the fastest computer most of us have ever owned sat on the desk, idle except for the fan. It never needed Kubernetes to run your code. It needed a stack that knows when to work and when to sleep.
We think it can be fixed where it lives. Your code, your services and your debugger on one machine. A breakpoint that just hits. Nobody’s pager involved. Platform teams have a platform to build, and babysitting dev boxes shouldn’t be it.
No account, no telemetry.
A tool that runs on your laptop has no business knowing who you are. doze has no account to make and nothing to sign in to, and it sends nothing home. Neither does this website: no cookies, no analytics.
That isn’t a setting you have to find. It’s how doze is built, and it’s open source under Apache-2.0, so you can read it and check. Your data stays on your disk, kept while it sleeps, and goes nowhere unless you move it.
One file.
A stack is a list of things and how they start: this database at that version, this app on this port, that one after the migration. The list belongs in the repo, in one file a person can read. Ours is doze.hcl.
Because the file is what runs, it can’t drift from what runs. A new teammate clones the repo and types doze up. You, back after three months, type doze up. The page called “Getting started (2023)” can finally retire.
One file is also one thing to review, one thing your agent can read, and one thing the app can draw as a map.
Rest is for people too.
We called it doze because the machines were the easy part. The harder part is the person in front of them: the low hum of things left running, the terminal tab you’re scared to close, the stack you’re not sure you can bring back tomorrow.
Close the lid with nothing still running and you get back something that isn’t measured in megabytes. You can stop. The work will be there in the morning, and it will start when you do.
Work hard. Then close the lid.