How do you put your app on your own server?

Rent a small virtual machine for **$5 to $20 a month**, install nothing but a container runtime, and
use a deploy tool that builds your app into an image, ships it to the box, and swaps it in with no
downtime. Setup takes an afternoon the first time and one command every time after. For most products
before serious scale, this is cheaper, faster, and less surprising than a managed platform.

Here is what is actually involved, and when you should not do it.

## What "your own server" means now

It does not mean a rack, and it does not mean configuring web server software by hand. The modern
shape is:

1. Your app builds into a **container image**, which contains the app and everything it needs.
2. A **deploy tool** builds that image, pushes it to a registry, pulls it on the server, starts the
   new container, waits for it to report healthy, and only then routes traffic to it.
3. A **proxy** in front handles TLS certificates automatically.

You do not manage the machine so much as replace what runs on it. If the box is ever damaged in a way
you cannot explain, the answer is to make a new one and deploy again, which takes minutes.

## What you actually need

**A server.** One virtual machine. Two shared cores and 2 to 4 GB of memory handles far more traffic
than most people expect. $5 to $20 a month.

**A domain**, pointed at the server. $10 to $15 a year.

**A container registry** to hold your images. Free tiers cover a small app comfortably.

**TLS**, which is free and automatic. Nobody should be paying for a certificate.

That is the entire bill. Compare with a managed platform, where the equivalent setup with a managed
database and a worker process usually lands somewhere between $50 and $200 a month for the same
traffic.

## The database question

The one that generates the most argument, so here is the direct answer: **for most products, at most
stages, SQLite on the same server is genuinely fine.**

Not a compromise, not a starter tier. Fine.

It is fast, because there is no network between your app and its data. It is simple, because there is
no second service to run, secure, or pay for. And modern setups handle concurrent writes far better
than the old reputation suggests.

You need a separate database server when you need multiple application servers sharing one dataset,
or when your working set genuinely outgrows one machine. Both are real, and both are much further
away than people assume. Until then, a separate database is a bill and an operational burden that
buys you nothing.

The same logic applies to your job queue and your cache. If they can live in your database rather
than requiring a separate service, that is one less thing to run, monitor, and pay for.

## The deploy itself

What a good deploy does, in order:

1. Build the image.
2. Push it to the registry.
3. Pull it on the server.
4. Start the new container alongside the old one.
5. **Wait for a health check to pass.**
6. Switch traffic over.
7. Stop the old container.

Step five is the one that matters. Without it, a deploy that fails to boot takes your site down and
you find out from a customer. With it, the new container never receives traffic and the old one keeps
serving, so a broken deploy is a non-event.

## What you actually have to think about

Being honest: running your own server is not zero work. It is a small amount of specific work.

**Backups.** Nobody else is doing this for you. Automated, off the machine, and **restored at least
once as a test**. A backup you have never restored is a hypothesis. This is the single most important
item on the list and the most commonly skipped.

**Operating system updates.** Unattended security updates handle most of it. Reboot occasionally.

**Monitoring.** At minimum, something that tells you when the site is down. A free uptime checker
covers it.

**Logs.** Know where they are before you need them at two in the morning.

**Secrets.** Environment variables on the server, never in the repository. Somebody should check for
committed secrets automatically, because everyone commits one eventually.

That is the list. It is perhaps an hour of setup and very little ongoing attention.

## When a managed platform is genuinely better

Not never. Specifically:

- **Nobody on the team wants to own a server.** A platform is a real answer, and the premium buys a
  thing you would otherwise resent.
- **You need to scale to zero**, or you have spiky and unpredictable traffic.
- **Compliance requires** managed infrastructure with a certification you cannot produce yourself.
- **You are pre-launch and optimizing for speed**, and an afternoon matters more than the monthly
  cost.

Otherwise the arithmetic favors the small server, and it keeps favoring it for a long time.

## The thing that makes this pleasant

Whatever you choose, the property worth insisting on is that **deploying is one command** and that it
is safe to run at any time.

The moment deploying becomes a checklist, people deploy less, changes pile up, and every release
becomes bigger and riskier than the last. That is a much more expensive problem than any hosting bill,
and it is the real argument for setting this up properly at the start rather than "once things are
working".

## The summary

- One small server, $5 to $20 a month.
- Containers, so what runs in production is what you built.
- Health-checked, zero-downtime deploys, one command.
- Automatic TLS.
- SQLite on the same box until you have a concrete reason otherwise.
- Backups, off the machine, restored once as a test.
- Uptime monitoring.

The costs sit alongside everything else in [what it actually costs to start an
app](/blog/what-it-costs-to-start), and the short version is that hosting is not where your money
goes.