How do you put your app on your own server?

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, and the short version is that hosting is not where your money goes.