v0-alpha · not production ready · free, and never a business
Run ten side projects
on one cheap computer.
Hobbyist gives you databases, websites and background jobs on a machine you own, with the one-command setup you would get from a paid cloud service. The trick is that anything nobody is using switches itself off, and switches back on by itself the moment someone connects. Idle projects cost you nothing, so they all fit.
curl -fsSL https://hobby.sh/install | bashRuns on Ubuntu, Debian or macOS. Needs Docker. What the installer does.
This database is switched off. Press connect and watch it come back, at the speed a real one does.
$ hobby connect blogNot a live server. Real recorded timings
Every project wants a database. Nobody wants ten bills.
If you build things for yourself, you probably have a folder of half-finished projects, and each one wants a database, somewhere to run, and a web address. There are two normal ways to solve that, and both of them are annoying.
Pay a cloud service
Neon, Supabase, Fly.io and Cloudflare all host this for you, and they are good at it. But you are renting: free tiers cap how many projects you can keep, some pause your project after a week of quiet and make you turn it back on by hand, and past that you are paying every month for ten things you touch occasionally.
Run it yourself
A server and some Docker containers cost you almost nothing and you own all of it. The catch is that everything you start keeps running forever. Ten databases sitting idle still eat the memory of ten databases, so a small machine fills up long before your ideas run out.
Things switch off when nobody needs them, and nobody notices
This is the one idea the whole project is built around. Here it is, start to finish.
Nothing is using it, so it stops
Your blog gets no visitors overnight. After five minutes of quiet, Hobbyist shuts its database down completely. It now uses no memory and no processor time at all, exactly as if you had never started it.
Someone shows up, and the connection waits
In the morning you load your blog. That connection reaches Hobbyist before it reaches the database, and Hobbyist simply holds it open, without answering yet, while it starts the database back up.
It answers, a fraction of a second late
The database finishes starting, and the connection completes normally. Your app never got an error and never had to retry. From the outside, one request was slightly slow. That is the whole trick.
Because an idle project genuinely costs nothing, you stop rationing them. Ten projects fit on a machine that could never run ten of them at the same time, because they are almost never all awake at the same time.
Switching off is easy. Switching back on is the hard part.
Plenty of tools will stop something idle. The difficult half is starting it again fast enough that whoever showed up never finds out. That second half is missing almost everywhere, and it is the reason this exists.
Supabase, self-hosted
You can run Supabase on your own server, and it is a genuinely good product. It just never switches anything off: the whole stack runs at full cost whether or not a single person is using it.
Xata’s open-source version
It can put a database to sleep, and then cannot wake it up again. Their own documentation says so. Waking it back up is the part they kept for the paid product, which tells you which half was hard.
Coolify and Dokploy
Both are lovely for deploying apps to your own server, and neither sleeps what it deploys. Everything you launch keeps running until you stop it.
Hobbyist
Sits in front of your databases and apps, notices a request arriving for something that is switched off, and quietly holds that request open while it starts things up. Both halves, which is the only arrangement that is actually useful.
So how slow is that first request?
Fast enough that nothing gives up waiting. The target is under a second, and three seconds is the point where database libraries start reporting a timeout, so anything slower than that counts as broken rather than slow.
| Starting up | Usually | In plain terms | Worst of 20 | Measured on |
|---|---|---|---|---|
| A database | 170ms | about a sixth of a second | 186ms | Apple silicon laptop |
| A website or API | 121ms | about an eighth of a second | 133ms | Apple M5 Pro |
| A serverless function | 299ms | about a third of a second | 321ms | Apple M5 Pro |
The number that is missing
Every measurement above came from a laptop, which is the easy case.Nobody has ever run this on a cheap five dollar server, which is exactly the machine it is meant for. So treat these as proof that the idea works, not as a promise about your hardware. If you try it on one, sending the numbers back is the most useful thing you could do for this project.
Four kinds of thing, grouped into projects
A project is just a named box you keep related things in. A blog might hold a database, the site itself, and a queue for sending email. Everything in it switches off and on the same way.
postgresDatabases
A real PostgreSQL database. Not a fork, not a lookalike, nothing custom bolted on. Anything that speaks Postgres connects to it.
appWebsites and APIs
Anything you can put in a Dockerfile. Point the command at a folder and you get a build, a web address and an HTTPS certificate.
workerServerless functions
Cloudflare Workers, running on your machine instead of theirs. Your existing wrangler.toml works as it is.
queueJob queues
A place to put work that should happen later. Messages are kept safely on disk, so nothing is lost while the thing that handles them is switched off.
People who build things for themselves
With the rise of AI came a lot of new hobbyists, people who build stuff for themselves. Hobby is for them. Deploy it on your own server. Mine runs on my home server, reachable through Tailscale and a Cloudflare Tunnel, and it hosts my demo environments.
If you have a spare laptop, a home server, or a cheap rented one, and you build more things than you want to pay monthly for, this is aimed squarely at you. If you are running something other people depend on, it is not, and the next section is why.
This is an early version, and some of it is broken
Version zero, alpha. Databases are the part that genuinely works and gets used every day. The rest ranges from young to openly broken, and it is all listed here so you can decide for yourself rather than find out later.
Works
- DatabasesThe solid part. This is the piece that has actually been used day to day.
- Websites and APIsDeploy from a Dockerfile, get a web address. Tested against real Docker.
- Serverless functionsIncluding stored state that survives being switched off and on again.
- Taking your data outOne command hands you your files and a docker-compose.yml that runs them anywhere.
- The dashboardBrowse tables, run SQL, read your schema. It works, and it is the newest part here. Reach it over Tailscale or a tunnel rather than putting it on the open internet.
- AI agent toolsFourteen tools so Claude or another agent can manage your projects. Databases only for now.
Broken, and we know why
- Sending jobs to a queue, on LinuxReading jobs works everywhere. Sending one from inside a container fails on Linux because of a networking flag that never got passed. It is written down and unfixed, not undiscovered. The details.
- HTTPS certificates get re-issuedCertificates are not saved between restarts of the web front door, so restarting it asks for new ones. Let’s Encrypt limits how often you can do that. The details.
- Cheap copies need the right disk formatCopying a project is nearly instant on XFS, ZFS or a Mac, and slow on ext4, which is what many cheap servers come with. You get a warning at setup, not a failure. The details.
Not built yet
- BackupsWritten and tested inside the daemon, and not yet connected to any command you can type. Until it is, back up with pg_dump.
- Instant project copiesClone a whole project to experiment against real data. Designed, not built.
- Deploying from your laptopToday the commands have to run on the machine itself. Log in over SSH, or use the dashboard.
- File storageAn S3-style bucket for images and uploads. Planned, not started.
The full status page goes into more detail and links each item to the place it is recorded.
You can take your things and go, at any time
Your database is stored as ordinary PostgreSQL files, in a normal folder, in the standard format. Nothing is locked up in a private format and nothing needs Hobbyist installed to be read.
hobby eject blog --releaseThat gives you a folder containing your data and a docker-compose.ymlfile. Copy it to any computer with Docker, run docker compose up, and your project is running again with Hobbyist nowhere in sight. No export queue, no support ticket, no thirty day window.How it works.
Nothing. There is no paid version coming.
No hosted service, no pro tier, no per-project pricing, no usage tracking, no account to make. Nothing is held back to sell you later. The only thing you pay for is the computer, which might be one you already own.
That is worth stating because it changes what gets built. Not being a business means never needing to keep different customers safely apart, never counting what you use, and never enforcing a quota, and cutting all of that is what makes a project this size possible for one person to write at all.
It also means there is no warranty and nobody on call. The measure of success is that the person who wrote it is still using it daily in six months.See how it compares, and what a machine actually costs.
curl -fsSL https://hobby.sh/install | bash