A Starter Self-Hosting Stack for a Mini PC

You bought the mini PC, installed Debian, got Docker running. Now what? The most common mistake at this point is installing the exciting stuff first — a media server, ten apps you saw on a list — and ending up with a fragile box, no backups, and no clean way to reach any of it. This is the order I actually deploy services on a new low-power homelab box, why that order, and what each one costs in RAM so you can see it all fits.

This assumes an N100-class box with 16GB RAM running Debian + Docker, the machine from the $200 N100 build. Everything here fits comfortably with room to spare.

The principle: infrastructure before applications

A self-hosting stack is a pyramid. The exciting apps sit on top, but they’re only as good as the layers under them: a way to reach services cleanly, name resolution, safe remote access, and backups. Build bottom-up and every later service is easier and safer. Build top-down and you’ll be retrofitting a reverse proxy around six running apps and regretting it.

The order below is deliberate. Resist the urge to skip to step 5.

Step 1: Reverse proxy (do this first)

What: Caddy or Traefik, in a container, owning ports 80/443. Every other service stays unpublished on an internal Docker network and is reached through the proxy by name.

Why first: It defines how you’ll reach everything else. Set it up before you have services and each new app is three lines of config. Set it up after and you’re re-plumbing a running system. Caddy’s automatic HTTPS (via a DNS challenge for a wildcard cert) means every service gets a real certificate with no per-service work.

RAM: ~70–90MB. Pattern: one shared external Docker network (call it proxy); every service joins it and exposes its port only internally. The proxy is the single front door. The team at DockerHomeLab ↗ has clean Caddy/Traefik Compose templates for exactly this layout.

Step 2: DNS — Pi-hole (+ a resolver)

What: Pi-hole for network-wide ad/tracker blocking and local DNS, ideally with Unbound behind it as a recursive resolver.

Why second: Two payoffs. Network-wide blocking is the single highest-value self-hosted service for most households — every device benefits immediately. And local DNS lets you give services real names (vault.home.lan) instead of memorizing IPs and ports, which makes the reverse proxy above far nicer to use.

RAM: Pi-hole ~110MB, Unbound ~40MB. Note: if this box is your only DNS and it reboots, the house loses DNS. Plan for that — a lightweight secondary resolver (AdGuard Home on another box, or your router as fallback) is worth it before you depend on it. This is also a classic single-purpose role for a cheap second box like a Wyse 5070.

Step 3: Remote access — Tailscale or WireGuard

What: Tailscale (easiest) or a self-hosted WireGuard endpoint for reaching your services from outside the house.

Why third, and why before exposing anything: The safest homelab has zero public ports. A mesh VPN lets you reach every internal service remotely without forwarding a single port to the internet. Set this up before you’re tempted to port-forward something “just quickly” — that temptation is how homelabs get compromised. With Tailscale up, your reverse proxy and all services stay private and you still reach them from anywhere.

RAM: ~50MB. Rule: the VPN endpoint should be the only externally reachable thing you run. Everything else lives behind it.

Step 4: Backups (before the data you’d miss exists)

What: An automated backup of your Docker volumes and config. Restic or Borg to a separate disk and then offsite, or a simpler scheduled tar of your stack/ directory plus volume snapshots to the 2.5” SATA SSD and then to a NAS/cloud.

Why before the fun stuff: The first time you need a backup is the first time you didn’t have one. Set up backups while there’s almost nothing to back up, so the discipline exists before Nextcloud holds your family’s photos. A backup you’ve never restored is a guess — do one test restore now, while it’s trivial.

RAM: negligible (runs on a schedule). Targets: local SATA SSD for fast restores, plus an offsite copy. Storage tiering for this is covered in storage options for a mini PC homelab.

Step 5: Now the useful applications

With proxy, DNS, remote access, and backups in place, now add the services people actually self-host for. A sensible first batch on an N100/16GB:

Service	Role	Approx RAM
Vaultwarden	Password manager (Bitwarden-compatible)	~60MB
Uptime Kuma	Monitors your own services, alerts you	~110MB
Home Assistant	Home automation	~500MB+
Nextcloud	Files, photos, contacts, calendar	~1–1.5GB
Jellyfin	Media server (HW transcode via iGPU)	~400MB idle
Watchtower	Auto-updates containers (skip critical ones)	~30MB

Add them one at a time, each behind the proxy on the internal network, each with its volumes in the backup set. Vaultwarden first — it delivers value on day one and is small. Nextcloud and Jellyfin last of this batch — they’re the heaviest and benefit from you already being comfortable with the workflow.

The RAM budget, totalled

Adding it up on a 16GB box: proxy + DNS + resolver + VPN + monitoring ≈ 0.5GB. The full application batch above ≈ 3–4GB. The OS ≈ 0.5GB. Total in the 4–5GB of 16GB range, leaving comfortable headroom to add more later or to bump to 32GB if you go heavy on Frigate/Immich. This tracks with the reference $200 N100 build: on the order of eleven services fit well within 16GB on a box drawing roughly 8W idle.

If your ambitions clearly exceed this — many VMs, heavy databases, lots of camera AI — that’s the signal to look at an N305 instead, which I compare in N100 vs N305 vs N97. For most people, the N100 runs this entire stack and then some.

Deployment hygiene that pays off

A few habits that keep this maintainable years later:

• One docker-compose.yml per service, in its own folder. One giant compose file is miserable to debug and update. Keep a stack/ tree, one subfolder per service.
• Pin or deliberately float versions. Watchtower auto-updates are convenient but skip it for Nextcloud, databases, and Home Assistant — update those manually after reading release notes.
• unattended-upgrades on the host. OS security patches are the boring layer that prevents most compromises.
• Document nothing in your head. A README.md in the stack folder noting what runs where and how to restore it is worth its weight when you come back in a year.

Bottom line

• Build the pyramid bottom-up: reverse proxy → DNS → remote access (VPN) → backups → applications.
• The safest homelab has zero public ports — reach everything through a mesh VPN.
• Set up backups before the data you’d miss exists, and test one restore.
• The whole sane starter stack fits in 4–5GB on a 16GB N100, with room to grow.

Self-hosting goes wrong when people start at step 5. Start at step 1, and every service after it is easier, safer, and still fits on one quiet ~8W box. For the conceptual “what should I run and why” sequencing that complements this build order, SelfhostRealm’s beginner guide ↗ is the right companion, and TrueNASGuide ↗ covers the storage target your backups should eventually reach.