Self-Hosting on a Raspberry Pi: 10 Tools That Actually Work

A Raspberry Pi 4/5 with 4-8 GB RAM is a surprisingly capable home server. But not every self-hosted tool runs well on ARM. Here are 10 that genuinely work — tested, ARM-native, and light enough for Pi hardware.

Hardware Recommendations

Pi Model	RAM	Use Case	Price
Pi 4 Model B	4 GB	Light (3-5 tools)	~$55
Pi 4 Model B	8 GB	Medium (5-8 tools)	~$75
Pi 5	8 GB	Full stack (8-10 tools)	~$80

Essential accessories:

MicroSD card (32 GB minimum, 64 GB recommended)
USB SSD (strongly recommended over microSD for reliability)
Case with fan (Pi 5 runs hot under load)
Ethernet cable (faster and more reliable than WiFi)

The 10 Best Tools for Raspberry Pi

1. Uptime Kuma — Monitoring

RAM: ~100 MB | ARM: Native | Docker: ✅

docker run -d --name uptime-kuma --restart unless-stopped \
  -p 3001:3001 -v uptime-kuma:/app/data \
  louislam/uptime-kuma:latest

Perfect Pi workload — lightweight, always-on, benefits from local network access.

2. Vaultwarden — Password Manager

RAM: ~50 MB | ARM: Native (Rust) | Docker: ✅

docker run -d --name vaultwarden --restart unless-stopped \
  -p 8080:80 -v vw-data:/data \
  -e DOMAIN=https://vault.yourdomain.com \
  vaultwarden/server:latest

One of the lightest self-hosted tools. Runs flawlessly on any Pi.

3. Pi-hole — DNS Ad Blocking

RAM: ~50 MB | ARM: Native | Docker: ✅

docker run -d --name pihole --restart unless-stopped \
  -p 53:53/tcp -p 53:53/udp -p 80:80 \
  -e TZ=America/New_York \
  -e WEBPASSWORD=your-password \
  -v pihole_etc:/etc/pihole \
  -v pihole_dnsmasq:/etc/dnsmasq.d \
  pihole/pihole:latest

The original Pi self-hosting use case. Blocks ads network-wide.

4. Home Assistant — Smart Home

RAM: ~500 MB | ARM: Native | Docker: ✅

docker run -d --name homeassistant --restart unless-stopped \
  --privileged --network host \
  -v ha_config:/config \
  -e TZ=America/New_York \
  ghcr.io/home-assistant/home-assistant:stable

The most popular home automation platform. Excellent ARM support.

5. PocketBase — Backend

RAM: ~30 MB | ARM: Native (Go) | Docker: Not needed

wget https://github.com/pocketbase/pocketbase/releases/latest/download/pocketbase_0.25.0_linux_arm64.zip
unzip pocketbase_*_arm64.zip
./pocketbase serve

Single binary, SQLite backend, 30 MB RAM. Ideal Pi backend for small apps.

RAM: ~50 MB | ARM: Native (Go) | Docker: ✅

docker run -d --name listmonk --restart unless-stopped \
  -p 9000:9000 \
  -v ./config.toml:/listmonk/config.toml \
  listmonk/listmonk:latest

Go binary, minimal resources. Can send thousands of emails from a Pi.

7. Gitea — Git Hosting

RAM: ~200 MB | ARM: Native (Go) | Docker: ✅

docker run -d --name gitea --restart unless-stopped \
  -p 3000:3000 -p 222:22 \
  -v gitea_data:/data \
  -e GITEA__database__DB_TYPE=sqlite3 \
  gitea/gitea:latest

Lightweight GitHub alternative. SQLite mode keeps resource usage minimal.

8. Plausible — Analytics

RAM: ~500 MB | ARM: Native | Docker: ✅

Plausible runs on ARM but needs more memory due to ClickHouse:

git clone https://github.com/plausible/community-edition.git
cd community-edition
# Configure .env
docker compose up -d

Works on Pi 4 (4 GB) for small sites (under 100K pageviews/month).

9. Syncthing — File Sync

RAM: ~100 MB | ARM: Native (Go) | Docker: ✅

docker run -d --name syncthing --restart unless-stopped \
  -p 8384:8384 -p 22000:22000/tcp -p 22000:22000/udp \
  -v syncthing_config:/var/syncthing/config \
  -v /mnt/data:/var/syncthing/data \
  syncthing/syncthing:latest

Continuous file synchronization. Replace Dropbox for personal use.

10. Mealie — Recipe Manager

RAM: ~200 MB | ARM: Native | Docker: ✅

docker run -d --name mealie --restart unless-stopped \
  -p 9925:9000 \
  -v mealie_data:/app/data \
  -e ALLOW_SIGNUP=true \
  -e TZ=America/New_York \
  ghcr.io/mealie-recipes/mealie:latest

Self-hosted recipe manager. Import from URLs, meal planning, shopping lists.

What Doesn't Work Well on Pi

Tool	Why Not	Alternative
Mattermost	2-4 GB RAM, Java-heavy	Use on a VPS
Nextcloud	Sluggish with multiple users	Fine for 1-2 users
Keycloak	JVM needs 2+ GB	Use Authelia instead
Supabase	10+ containers, 4+ GB	Use PocketBase
Metabase	JVM, needs 2+ GB	Use Grafana (lighter)
GitLab	4+ GB RAM minimum	Use Gitea
n8n	Works but slow with complex workflows	Fine for simple automations

Performance Tips

Use a USB SSD — microSD cards are slow and wear out:

# Format and mount USB SSD
sudo mkfs.ext4 /dev/sda1
sudo mount /dev/sda1 /mnt/ssd
# Move Docker data directory to SSD
sudo systemctl stop docker
sudo rsync -a /var/lib/docker/ /mnt/ssd/docker/
# Update /etc/docker/daemon.json with "data-root": "/mnt/ssd/docker"

Enable swap (for Pi 4 with 4 GB):

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

Monitor temperature:

vcgencmd measure_temp
# Keep under 70°C — use a fan or heatsink

Limit Docker logging:

// /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Example Stack for Pi 5 (8 GB)

A practical home server stack that fits comfortably:

Tool	RAM	Purpose
Uptime Kuma	100 MB	Monitor all services
Vaultwarden	50 MB	Family password manager
Pi-hole	50 MB	Network ad blocking
Home Assistant	500 MB	Smart home
PocketBase	30 MB	Personal app backend
Syncthing	100 MB	File sync
Gitea	200 MB	Personal Git repos
Total	~1 GB	Leaves 7 GB free

Cost: Pi vs VPS

Option	Monthly Cost	Pros
Pi 5 (8 GB)	~$5/month electricity	One-time $100, no subscription, local network, data stays home
Hetzner VPS	€4.50/month	More powerful, static IP, better uptime, remote access built-in
DigitalOcean	$6/month	Managed, backups included, global access

Use a Pi when: Privacy matters, you want LAN access, you enjoy tinkering. Use a VPS when: You need uptime guarantees, remote access, or more power.

Find the best self-hostable tools on OSSAlt — ARM compatibility, resource usage, and deployment guides side by side.

Monitoring and Operational Health

Deploying a self-hosted service without monitoring is running blind. At minimum, set up three layers: uptime monitoring, resource monitoring, and log retention.

Uptime monitoring with Uptime Kuma gives you HTTP endpoint checks every 30-60 seconds with alerts to Telegram, Slack, email, or webhook. Create a monitor for your primary application URL and any API health endpoints. The status page feature lets you communicate incidents to users without custom tooling.

Resource monitoring tells you when a container is leaking memory or when disk is filling up. Prometheus + Grafana is the standard self-hosted monitoring stack — Prometheus scrapes container metrics via cAdvisor, Grafana visualizes them with pre-built Docker dashboards. Set alerts for memory above 80% and disk above 75%; both give you time to act before they become incidents.

Log retention: Docker container logs are ephemeral by default. Add logging: driver: json-file; options: max-size: 100m; max-file: 3 to your docker-compose.yml to limit log growth and retain recent logs for debugging. For centralized log search across multiple containers, Loki integrates with the same Grafana instance.

Backup discipline: Schedule automated backups of your Docker volumes using Duplicati or Restic. Back up to remote storage (Backblaze B2 or Cloudflare R2 cost $0.006/GB/month). Run a restore drill monthly — a backup that has never been tested is not a reliable backup. Your restore procedure documentation should live somewhere accessible from outside the failed server.

Update strategy: Pin Docker image versions in your compose file rather than using latest. Create a monthly maintenance window to review changelogs and update images. Major version updates often require running migration scripts before the new container starts — check the release notes before pulling.

Raspberry Pi hosting is best suited for specific workloads — low-traffic internal tools, home automation hubs, DNS filtering, and media servers. Uptime Kuma runs well on a Pi 4 with 2GB RAM and is a natural fit for home lab monitoring. AdGuard Home on a Raspberry Pi is the classic Pi use case — network-level ad blocking and DNS filtering for all devices on your network. Syncthing runs efficiently on a Pi and provides reliable device-to-device file sync without cloud storage.

Network Security and Hardening

Self-hosted services exposed to the internet require baseline hardening. The default Docker networking model exposes container ports directly — without additional configuration, any open port is accessible from anywhere.

Firewall configuration: Use ufw (Uncomplicated Firewall) on Ubuntu/Debian or firewalld on RHEL-based systems. Allow only ports 22 (SSH), 80 (HTTP redirect), and 443 (HTTPS). Block all other inbound ports. Docker bypasses ufw's OUTPUT rules by default — install the ufw-docker package or configure Docker's iptables integration to prevent containers from opening ports that bypass your firewall rules.

SSH hardening: Disable password authentication and root login in /etc/ssh/sshd_config. Use key-based authentication only. Consider changing the default SSH port (22) to a non-standard port to reduce brute-force noise in your logs.

Fail2ban: Install fail2ban to automatically ban IPs that make repeated failed authentication attempts. Configure jails for SSH, Nginx, and any application-level authentication endpoints.

TLS/SSL: Use Let's Encrypt certificates via Certbot or Traefik's automatic ACME integration. Never expose services over HTTP in production. Configure HSTS headers to prevent protocol downgrade attacks. Check your SSL configuration with SSL Labs' server test — aim for an A or A+ rating.

Container isolation: Avoid running containers as root. Add user: "1000:1000" to your docker-compose.yml service definitions where the application supports non-root execution. Use read-only volumes (volumes: - /host/path:/container/path:ro) for configuration files the container only needs to read.

Secrets management: Never put passwords and API keys directly in docker-compose.yml files committed to version control. Use Docker secrets, environment files (.env), or a secrets manager like Vault for sensitive configuration. Add .env to your .gitignore before your first commit.

Production Deployment Checklist

Before treating any self-hosted service as production-ready, work through this checklist. Each item represents a class of failure that will eventually affect your service if left unaddressed.

Infrastructure

Server OS is running latest security patches (apt upgrade / dnf upgrade)
Firewall configured: only ports 22, 80, 443 open
SSH key-only authentication (password auth disabled)
Docker and Docker Compose are current stable versions
Swap space configured (at minimum equal to RAM for <4GB servers)

Application

Docker image version pinned (not latest) in docker-compose.yml
Data directories backed by named volumes (not bind mounts to ephemeral paths)
Environment variables stored in .env file (not hardcoded in compose)
Container restart policy set to unless-stopped or always
Health check configured in Compose or Dockerfile

Networking

SSL certificate issued and auto-renewal configured
HTTP requests redirect to HTTPS
Domain points to server IP (verify with dig +short your.domain)
Reverse proxy (Nginx/Traefik) handles SSL termination

Monitoring and Backup

Uptime monitoring configured with alerting
Automated daily backup of Docker volumes to remote storage
Backup tested with a successful restore drill
Log retention configured (no unbounded log accumulation)

Access Control

Default admin credentials changed
Email confirmation configured if the app supports it
User registration disabled if the service is private
Authentication middleware added if the service lacks native login

Getting Started

The best time to set up monitoring and backups is before you need them. Deploy your service, configure it, and immediately add it to your monitoring stack and backup schedule. These three steps — deploy, monitor, backup — are the complete foundation of a reliable self-hosted service. Everything else is incremental improvement.

A Raspberry Pi 4 with 4GB or 8GB RAM is a capable home server for a specific category of workload: low-traffic internal tools, always-on home automation, media organization, and network-level services. The ARM architecture is supported by most Docker images, and the power consumption (5-7 watts) makes it economical for always-on operation. The limitations are real: SD card storage is slower and less reliable than SSDs for database workloads; the Pi 4's Ethernet connection tops out at 1Gbps; and the ARM architecture occasionally causes compatibility issues with older or less maintained container images. Use a USB3 SSD for anything with significant disk I/O to avoid the SD card as a performance bottleneck.

Self-Hosting on a Raspberry Pi 2026