roadmap

What exists, and what does not

Two of the four phases are built and in daily use. This page says which is which, at the level of individual features, so you can tell what you would actually be installing.

How to read this

Done means you can use it today, and the note says how it was checked.
Partly done means some of it works and the missing piece is named rather than glossed over.
Planned means it does not exist. Designed or not, do not build anything on top of it.
There are no dates anywhere on this page, and there will not be. One person writes this in their spare time, and a date would be a promise rather than information.

Phase 1 · done

Databases, a dashboard, and a way out

The core. A project holding a Postgres database, the command line tool, the dashboard, tools for AI agents, and the command that hands you your data back.

done: Postgres databases that switch off and on by themselvesMeasured at 170ms to start, and the part used daily
done: The hobby command line toolSixteen commands
done: Taking your data outVerified end to end against real Docker
partly done: The dashboardBrowsing, SQL and schema all work. It cannot create a website or function yet
partly done: Tools for AI agentsFourteen of them. Databases only so far

Phase 2 · done

Running your code, not just your data

Websites, APIs, serverless functions and job queues, all switching off and on the same way a database does. Merged, and newer than Phase 1.

done: Websites and APIs from a DockerfileStarts in about an eighth of a second
done: Cloudflare-style serverless functionsYour existing wrangler.toml works unchanged
done: Stored state that survives being switched offIncluding timers that fire while the thing is stopped, which is the hard part
done: HTTPS and custom domainsOff by default. Certificates are not saved between restarts yet
done: Private access over TailscaleHow the author actually runs it
partly done: Job queuesReading jobs works. Sending one from inside a container is broken on Linux

Not phased · partly done

Backups, because losing data is the one unacceptable failure

Deliberately outside the phase order. Five kinds of thing now hold data nobody would accept losing, and the backup command is the piece still missing.

done: pg_dump works, and always willThis is the backup story today
done: Taking a whole project out as filesRuns anywhere with Docker
partly done: Project snapshotsWritten and tested inside the daemon, and connected to no command you can type. Genuinely unusable until that changes
planned: Point in time recoveryCut on purpose rather than postponed. It needs write-ahead log archiving and a restore path that deserves its own testing discipline

Phase 1.5 · planned

Copying a project instantly

Clone a whole project, data and all, in about the time it takes to press enter, so you can try something against real data without risking it. Numbered 1.5 because it was scoped before Phase 2 and built after.

done: The file copying underneath itAlready written, because snapshots needed the same thing
planned: Branching a projectNearly free on XFS, ZFS or a Mac. A real copy on ext4, which is what many cheap servers use

Phase 3 · planned

Files, disks and a client library

The last planned phase. Somewhere to keep uploads, disks that outlive a restart, and a library so a React app can talk to all of it without you writing the plumbing.

planned: S3-style file storageFor images, uploads, anything that is not a row in a table
planned: Disks for websites and functionsThey are deliberately stateless until this exists
planned: A React libraryOnly if it earns its place

What is actually being worked on

Not a phase, just the four things most worth doing next. Every one of them is something a contributor could pick up.

Measure it on a cheap five dollar serverEvery speed number this project publishes came from a laptop, and the cheap server is the machine it is actually for. This is the single most useful thing anybody could contribute.
Fix sending jobs to a queue on LinuxA networking flag that never got passed. The problem is fully understood and written down.
A command for taking backupsThe hard part is already written and tested. It needs a command and an API route so a person can actually reach it.
Let the dashboard create websites and functionsIt can only make databases right now. The groundwork that makes the rest possible has already landed.

How to contribute, including the two rules that will get a patch sent back.

never

Things that are deliberately not coming

This list matters more than the one above. The way a project like this dies is not competition and not running out of money, since there is none. It is being abandoned half finished because it tried to do everything. Each of these is a perfectly good idea, and that is exactly the danger.

Not coming	Why
Kubernetes, clusters, more than one machine	One box is the whole point. A feature needing a cluster is out of scope by definition.
Hosting other people’s workloads	Everything here assumes every project belongs to the same person. Keeping strangers safely apart is a different and much larger job.
A paid tier, billing, usage metering	There is no business here and there is not going to be one.
Login and accounts for your users	Supabase does this well. This will not compete.
Live updates, edge hosting, DNS management, secrets management	All reasonable. All individually a month of work, and collectively the thing that kills projects like this.

None of these is a locked door. Each one can be argued for by writing the case down as a decision record and opening it for discussion before any code gets written. The existing decisions show what that looks like, and a good number of them are records of something being turned down.