Your apps need a computer that stays on. This guide compares a box at home with a rented server (a VPS), shows how to size either one, and lists the apps that need a particular place.
The two choices
A home server is a computer you own and keep running at home: an old laptop, a mini PC, or a Raspberry Pi. A VPS (virtual private server) is a small slice of a company's computer that you rent by the month. You log in over the internet and use it like your own machine.
Both run the same software. Docker, the apps, and the commands in later guides are identical. The differences are money, location, and who sits between your apps and the internet.
What each one costs
A home box costs money once, then electricity. A VPS costs rent every month and nothing else.
Three rules cover most of it:
- Old hardware is nearly free. A laptop or mini PC you already own costs only power.
- Electricity is easy to estimate. Multiply the watts the box draws by 24 hours and 30 days, divide by 1,000, and multiply by your price per kWh. A box that draws 10 W uses about 7 kWh a month. Check the real draw with a cheap plug-in power meter, because a box with a graphics card or spinning disks draws far more.
- Rent scales with RAM. A VPS with more memory costs more. A small one costs about what a streaming subscription does.
For one sourced example: as of October 2026, Hetzner lists a 2 vCPU, 4 GB RAM, 40 GB plan at 5.99 euros a month, excluding VAT. The page also showed that plan as unavailable when we checked, so stock changes. Other providers sell similar plans. Compare the RAM and disk, not the brand.
A VPS needs no spare hardware, and it keeps running through a power cut at your house. A home box gives you cheap disk space and a fast local network.
Size by RAM, not CPU
Small apps rarely run out of processor power. They run out of memory.
Each app needs RAM. Many also need a database, and the database needs its own RAM. Add them up. As a rough rule, add 1 GB for the operating system and Docker, then leave a quarter of the total free.
When a machine runs out of memory, Linux kills a process to recover. Docker says that by default the kernel kills processes in a container on an out-of-memory error. From the outside this looks like a random crash: the app vanishes, Docker restarts it if you set a restart policy, and it works for an hour. If an app dies without explanation, suspect memory first. Two checks:
free -h
docker inspect --format '{{.Name}} {{.State.OOMKilled}}' $(docker ps -aq)
The first line shows free memory. The second prints true next to any container that Docker recorded as killed for memory. If it prints false for a crashing app, read the kernel log: sudo journalctl -k | grep -i "out of memory".
Light and heavy apps
Docs state requirements for some apps and not for others, so treat these as rough guides:
| App | What its docs say |
|---|---|
| Navidrome | Very low resource usage, runs on a Raspberry Pi Zero |
| OpenPlate | 2 GiB RAM minimum, as listed on its SHW page |
| AnythingLLM | 2 GB RAM, 2 cores with AVX2, 5 GB storage as a minimum |
| AFFiNE | 4 cores, 2 GB RAM for basic use, 4 GB for documents over 10,000 words |
Uptime Kuma states no RAM figure in its install docs. Huginn also states none. It runs as a web process plus a background worker, backed by a database, so it has more parts to feed than a single-process app. Measure both on your own machine with docker stats --no-stream.
AnythingLLM's minimum assumes you call a hosted AI model. If you run the model on the same machine, memory needs jump. Self-hosted AI: local or API covers that.
Pick a machine for the sum of everything you plan to run, with room for the next app. Many apps, one server shows how they share it.
What fills the disk
Four things fill a disk, in this order:
- Media. Music, photos and video. A library only grows.
- AI models. A single local model file is a large download.
- Docker images. Old versions stay after each update. Run
docker system dfto see the space Docker uses. - Logs. Docker's default log driver has no size limit:
max-sizedefaults to unlimited. A noisy app can fill a small disk. Cap it per service in your compose file:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
A full disk stops databases and corrupts writes. Know when it breaks sets up an alert before that happens.
Pitfalls of a home box
ARM images. A Raspberry Pi uses an ARM processor, and most PCs and VPS plans use x86-64. Docker picks the matching variant of an image when one exists. Where none does, you cannot run a linux/amd64 container on an arm64 host without slow emulation. Before you buy a Pi, open the image's page on its registry and look for arm64 in the tags. Navidrome publishes images for arm (v6 and v7) and arm64. Check every app you want.
Sleeping laptops. A laptop suspends when you close the lid, and every app stops with it. systemd's HandleLidSwitch setting defaults to suspend. The same page recommends a small drop-in file over editing the main file. Create one that sets the value to ignore, then restart the machine:
sudo mkdir -p /etc/systemd/logind.conf.d
printf '[Login]\nHandleLidSwitch=ignore\n' | sudo tee /etc/systemd/logind.conf.d/lid.conf
sudo reboot
After the restart, systemd-analyze cat-config systemd/logind.conf | grep HandleLidSwitch shows your line at the end. Also check the power settings for automatic sleep.
A front door. Your router blocks inbound traffic, so outside devices cannot reach your apps. You must choose how they get in: a private network, a tunnel, or an open port. Choose your front door compares them. Read Why you should not open ports before you forward anything. The two easiest options are Tailscale and Cloudflare Tunnel.
Power and internet. A power cut or router restart takes everything down. Home internet may also give you no public address at all, which rules out an open port.
Pitfalls of a VPS
A VPS has a public IP address from the start. Automated scanners probe every public address all the time, as Why you should not open ports explains, so expect SSH password guesses soon after the server boots. Lock the server down before you install apps: First hour on a new server walks through it.
You also pay for every gigabyte of RAM. Disk space is usually small, and large media libraries cost a lot to rent.
Apps that need a particular place
Some apps care where they run:
- Collie. ColliePWA runs next to your agents, on the machine that already has them. A paired device gets full shell access to that host. It binds to loopback, and its docs say never to make it public with
tailscale funnel. Put Collie on the computer where your coding agents run, reached through a private network. A VPS only makes sense if your agents run on that VPS. - Navidrome. It reads your music from a folder mounted into the container. Run Navidrome where the music files are. Copying a large library to a rented server costs rent for disk and a long upload.
- Uptime Kuma. A monitor that dies with the server it watches reports nothing. Run Uptime Kuma on a different machine, and ideally in a different place, from the apps it checks. A cheap VPS watching your home box works well, and the reverse works too.
- GoAccess. GoAccess reads a web server's access log files. It is useful only where such logs exist. It can also read logs piped over SSH, but the simplest setup is on the machine that runs your web server.
Which to pick
- You own spare hardware and your apps are for your household: home server.
- Your media library is large, or the app reads files stored at home: home server.
- You want a public website, and your provider gives you no public IP: VPS.
- You want a monitor that survives a power cut at home: small VPS for Uptime Kuma alone.
- You have no hardware and want to learn: VPS. A new one costs little, and you can delete it.
- You want both: home server for data-heavy apps, small VPS for monitoring and public apps. A private network such as Tailscale joins them.
If you are unsure, start with whatever you already own. You can move later, and Backups you can restore covers how to move your data.
Next: First hour on a new server.