What to run yourself, and what to pay for

The comparison people make is the wrong one

A managed Postgres costs perhaps $25 a month at small size. The same database on a VPS you already rent costs nothing extra. So self-hosting saves $300 a year, and people take that deal without writing down the other side of it.

The other side is a list, and it is the same list every time: installing and configuring it, taking backups, testing a restore, applying security patches, upgrading major versions, monitoring disk and connections, tuning when it slows down, and being the person who fixes it at 2am. Put an hour a month against that (which is optimistic) and at any realistic hourly value the managed service was cheaper before you finished reading this paragraph.

That is not an argument for buying everything. It is an argument for comparing the same two columns each time: money and hours of your attention, where attention is the scarcer one for a small team.

The three questions that decide it

1. Is this thing stateful? Stateless services are easy to run yourself: if one dies, start another. Stateful ones (databases, queues with durable state, object storage, search indexes) carry backup, restore, replication and upgrade obligations that dominate the work. Buy state, run stateless is the single most useful heuristic here.
2. What happens at 3am if it breaks? If the answer is “I do not know how to fix it”, either learn before you depend on it, or pay somebody whose job that is.
3. Would running it teach you something you need? A genuine reason. Running Postgres yourself for a year teaches you more about databases than any course. Do it on a side project, not on the thing with users.

What is usually worth paying for, at small scale

• The database. Backups, point-in-time recovery, failover and version upgrades, for the price of two coffees a week. This is the best value on the list.
• Email delivery. The deliverability lesson explained why running your own mail server is a losing fight.
• TLS certificates and DNS. Free or nearly, and automated.
• Error tracking and uptime checks. Free tiers are generous, and self-hosting your monitoring on the machine being monitored is a known trap.
• Object storage. Durability you cannot easily reproduce.

What is usually fine to run yourself

• Your own application. Obviously.
• A cache. Redis or Valkey on the same box, treated as disposable, is low-maintenance because losing it is survivable by design.
• A reverse proxy. Caddy or nginx. One config file, rarely touched.
• Batch jobs and workers. Stateless, restartable, cheap.
• Small internal tools. Metabase, a status page, a wiki.

The middle ground people forget

Between “my own machine” and “a hyperscaler” is a large and underrated space: a €5 to €20 VPS from Hetzner, OVH, Contabo or DigitalOcean, with generous bundled bandwidth and predictable pricing. A single 4-core box with 8 GB of memory serves a surprising amount of traffic (tens of thousands of daily visitors for an ordinary application) and costs less per month than the free tier’s overage on a serverless platform.

The honest trade is that you own the operating system. Given the first module of this course, that is now within your reach, and for many projects it is both the cheapest and the most understandable option.

Read the exit before the entry

Before adopting anything managed, ask three questions:

• Can I get my data out, in a usable format, without asking permission? A database with a standard dump command, yes. A proprietary store with an export queue and a support ticket, be careful.
• What is the egress cost of leaving? Sometimes thousands of dollars, entirely by design.
• Is there a compatible alternative? S3-compatible storage, standard Postgres and standard Redis protocols mean the switch is configuration. A vendor-specific service means a rewrite.

Lock-in is not automatically bad (a service that saves you a hundred hours a year has earned some) but it should be entered knowingly, and written down in the decisions document from the handover lesson.

The rule of thumb

Buy the thing whose failure would ruin your weekend. Run the thing whose failure means restarting a process. Revisit once a year, because both your traffic and the prices move, and a decision that was right at fifty users is not automatically right at fifty thousand.