Skip to content

Infrastructure

The self-hosting checklist: what to set up before you run anything important

A complete checklist for running your own apps: hardware or VPS, backups, domains and DNS, HTTPS, updates, monitoring, secrets and an exit plan. Use it before you move real data.

By · Published · 3 min read

Short answer: before you self-host something important, have six things in place: a server you can rebuild, a domain with working DNS, HTTPS through a reverse proxy, automatic updates, backups you have restored at least once, and monitoring that tells you when something breaks. Everything else is optional. These six are what separate a hobby that works from a service you can depend on.

What can you self-host?

Almost any common tool has a self-hosted option: file sync, photo libraries, password managers, note apps, RSS readers, git forges, wikis, analytics, automation (see self-hosting n8n), password vaults, media servers, smart-home control, and business software such as billing and point of sale. Start with something low-stakes. Learn the routine on an app whose loss would only annoy you.

1. Where will it run?

  • A VPS gives you a public IP, good uptime and no home networking problems. Cost is a few dollars a month for small workloads.
  • A home server or mini PC gives you more power per rupee and local storage. You need a stable internet connection and a plan for power cuts. A small UPS is worth it.
  • A Raspberry Pi is enough for light things. SD cards fail, so use an SSD for anything important.

Choose a boring, long-term-supported OS such as Debian or Ubuntu LTS.

2. Make the server rebuildable

  • Keep every service's configuration in a Git repository: Compose files, proxy config, scripts. Keep secrets out of it.
  • Put data in named volumes or a known directory so you know what to back up.
  • Write down the setup steps. If the machine died tonight, could you rebuild it from your notes by tomorrow?

3. Domain and DNS

Register a domain and keep its DNS at a provider with an API, so certificates can be issued automatically. Create records for each service. If you do not know what the record types mean, read DNS records explained.

4. HTTPS and a reverse proxy

Put Caddy, Nginx or Traefik in front, get certificates from Let's Encrypt, and expose only ports 80 and 443. See what a reverse proxy is and how to harden it. If your connection is behind carrier-grade NAT or you cannot open ports, compare Cloudflare Tunnel and port forwarding.

5. Security basics

SSH keys only, default-deny firewall, unattended security updates, strong unique passwords, admin tools behind a VPN. The full list is in the self-hosting security hardening guide.

6. Updates

  • OS security updates: automatic.
  • Containers: pin versions, update on a schedule, read changelogs for anything with a database migration.
  • Take a backup or snapshot immediately before a major upgrade.

7. Backups

  • Back up databases with a dump tool (pg_dump, mysqldump), not by copying live files.
  • Keep one copy off-site and encrypted.
  • Automate it, and make it alert you when it fails.
  • Restore it to a clean machine and check that the app works. The first restore always teaches you something. Read recovering from self-hosted data loss for how this goes wrong.

8. Monitoring

At minimum: an external uptime check (Uptime Kuma works well), disk space alerts, certificate expiry alerts and backup success alerts. Disks filling up and certificates expiring cause most small-server outages.

9. Secrets

  • Use a password manager for human credentials.
  • Store service secrets in .env files with restricted permissions (chmod 600), kept out of Git. Back them up separately, since losing an encryption key can make backups useless.
  • Rotate any credential that was ever pasted into a chat, a ticket or a public repository.

10. Know your exit

Choose software that can export your data in an open format. Record where the data lives and how to move it. A self-hosted service you cannot leave is the same trap as a SaaS you cannot leave.

A one-page version

  • Can I rebuild the server from the repository and notes?
  • Is HTTPS working and are only 80 and 443 open?
  • Are updates automatic or scheduled?
  • Have I restored a backup this quarter?
  • Will I be told when it goes down?

If you can answer yes to all five, go ahead and move something important.

Author

Raktim Ranjit is a software engineer and the founder of NodeDR Infotech. He builds and maintains the software described here.

Have something in mind?

Let’s build something useful.

Tell me about the idea, product, or workflow you’re working through.

Tap to say hello