Apps auf einem VPS selbst hosten: Architektur, RAM-Verbrauch und womit anfangen
Entscheidungshilfe für das Self-Hosting von Apps auf einem VPS mit Docker. Echte Speicherverbrauchsdaten für über 10 Apps, Stacking-Kombinationen für 4-GB- und 8-GB-Pläne sowie ein Framework zur Auswahl Ihrer ersten App.
Sie haben einen VPS. Vielleicht gerade erst bekommen, vielleicht laufen schon ein paar Dienste darauf und Sie wollen mehr. So oder so ist die Frage dieselbe: Was soll ich darauf betreiben, und passt das?
Dieser Guide beantwortet das. Er behandelt die Architektur eines selbst gehosteten App-Stacks, liefert echte Speicherverbrauchswerte gemessen auf einem 4-vCPU/8-GB-VPS und bietet eine Entscheidungsmatrix, um Ihre erste (oder nächste) App auszuwählen. Voraussetzungen: Dieser Guide setzt voraus, dass Docker und ein Reverse Proxy bereits laufen. Falls nicht, beginnen Sie mit Docker in Produktion auf einem VPS: Was schiefgeht und wie Sie es beheben, um Docker, Docker Compose und Caddy oder Traefik auf Debian 12 oder Ubuntu 24.04 einzurichten. Für Docker-Compose-Grundlagen siehe [-> docker-compose-multi-service-vps].
Warum auf einem VPS statt auf einem Homelab selbst hosten?
Ein VPS bietet Ihnen Always-on-Hosting mit einer öffentlichen IPv4-Adresse, kein CGNAT, keine Stromrechnung und keine Hardware-Wartung. Vom Anbieter verwaltete Snapshots übernehmen die Disaster Recovery. Ein 4-vCPU/8-GB-VPS betreibt 5-8 Docker-Apps komfortabel für wenige Euro pro Monat. Ihr Internet zu Hause fällt aus; Ihr VPS nicht.
| Faktor | VPS | Homelab |
|---|---|---|
| Öffentliche IP | Inklusive, statisch | Oft hinter CGNAT. Erfordert Tunnel-Workarounds. |
| Verfügbarkeit | 99,9 %+ SLA, redundante Stromversorgung | Abhängig von Ihrem ISP und Stromnetz |
| Bandbreite | Symmetrisch, typischerweise 1 Gbit/s+ | Asymmetrisch. Upload ist der Flaschenhals. |
| Hardware-Wartung | Sache des Anbieters | Ihr Problem. Festplattenausfälle, Lüftergeräusche, Hitze. |
| Strom | Im Preis enthalten | 20-60 EUR/Jahr für einen kleinen Server im Dauerbetrieb |
| Snapshots/Backups | Ein Klick, vom Anbieter verwaltet | Sie bauen und testen die Backup-Pipeline selbst |
| Anfangskosten | Ab ~4 EUR/Monat | 200-500+ EUR für einen Mini-PC oder NAS |
| Physischer Zugang | Keiner. Nur SSH. | Voller Zugang. Gut für USB-Geräte, ZFS-Arrays. |
Ein Homelab ergibt Sinn, wenn Sie lokalen Speicher (ZFS-Arrays, NAS), USB-Hardware (Zigbee-Sticks, SDR-Dongles) brauchen oder Bare-Metal-Administration lernen möchten. Für alles andere ist ein VPS einfacher und günstiger zum Einstieg.
Die meisten Privatkunden-ISPs verwenden mittlerweile Carrier-Grade NAT, was bedeutet, dass Sie sich eine öffentliche IP mit Dutzenden anderer Kunden teilen. Port-Forwarding ist unmöglich. Eingehende Verbindungen sind unmöglich. Ihre selbst gehosteten Apps sind aus dem Internet unsichtbar. Workarounds gibt es (Cloudflare Tunnels, WireGuard-Relays über einen VPS), aber sie fügen Komplexität und eine Abhängigkeit von einem externen Dienst hinzu. Ein VPS umgeht das Problem komplett: Sie bekommen eine dedizierte öffentliche IPv4, Sie kontrollieren das DNS, und eingehender Traffic funktioniert einfach.
Wenn Sie beides wollen, nutzen Sie einen VPS als öffentlichen Edge und einen WireGuard-Tunnel zurück zu Ihrem Homelab für private Dienste. Aber für die meisten selbst gehosteten Apps reicht ein VPS allein aus.
Wie sieht ein selbst gehosteter App-Stack aus?
Ein selbst gehosteter Stack auf einem VPS folgt einer Schichtarchitektur: Ein Reverse Proxy steht davor und leitet HTTPS-Traffic an Anwendungscontainer weiter. Jede App verbindet sich mit ihrer eigenen Datenbank (oder nutzt eingebettetes SQLite). Eine Backup-Schicht erstellt planmäßig Snapshots.
Internet
│
▼
┌─────────────────────────────┐
│ Reverse Proxy (Caddy) │ Port 443 ← only public port
│ TLS termination + routing │
└──────┬──────┬──────┬────────┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│App 1│ │App 2│ │App 3│ Docker containers
└──┬──┘ └──┬──┘ └──┬──┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│ DB │ │ DB │ │SQLite│ PostgreSQL, Redis, or embedded
└─────┘ └─────┘ └─────┘
│
▼
┌─────────────────┐
│ Backup Layer │ Restic, borgmatic, or provider snapshots
│ (scheduled) │
└─────────────────┘
Zentrale Entscheidungen:
- Reverse Proxy: Caddy provisioniert TLS-Zertifikate automatisch ohne Konfiguration. Traefik integriert sich mit Docker-Labels zur Auto-Discovery. Beides funktioniert. Caddy ist einfacher für Einsteiger.
- Datenbank: Viele leichtgewichtige Apps (Vaultwarden, Uptime Kuma, Beszel) nutzen eingebettetes SQLite. Schwerere Apps (Immich, Plausible, Gitea) brauchen PostgreSQL.
- Backup: Anbieter-Snapshots decken die gesamte Festplatte ab. Für App-Level-Backups verwenden Sie Restic oder borgmatic zu einem Offsite-Ziel (S3-kompatibler Speicher oder ein zweiter VPS).
- Netzwerk: Alle App-Container befinden sich in einem internen Docker-Netzwerk. Nur der Reverse Proxy exponiert die Ports 80 und 443. Apps binden sich nie direkt an öffentliche Interfaces.
Diese Architektur wird im Detail unter Docker in Produktion auf einem VPS: Was schiefgeht und wie Sie es beheben behandelt.
Wie viel RAM verbrauchen selbst gehostete Apps wirklich?
Weniger als Sie denken. Die meisten beliebten selbst gehosteten Apps liegen im Leerlauf unter 200 MB. Ausnahmen sind Apps mit Machine-Learning-Funktionen (Immich) oder eingebetteten Analytics-Engines (Plausible mit ClickHouse).
Die Zahlen unten sind RSS-Speicher im Leerlauf/bei leichter Nutzung aus docker stats, gemessen auf einem Virtua Cloud 4-vCPU/8-GB-VPS mit Debian 12. Die Spitzenwerte repräsentieren typische Peaks bei aktiver Nutzung (Foto-Upload, Dokument-OCR, Workflow-Ausführung).
| App | Was sie ersetzt | RAM Leerlauf | RAM Spitze | Speicher/Monat | Datenbank |
|---|---|---|---|---|---|
| Vaultwarden | Bitwarden, 1Password | ~25 MB | ~50 MB | Minimal | SQLite |
| Uptime Kuma | UptimeRobot, Pingdom | ~100 MB | ~170 MB | Minimal | SQLite |
| Beszel | Datadog (Basis) | ~50 MB | ~80 MB | Minimal | Eingebettet |
| Gitea | GitHub (private Repos) | ~150 MB | ~300 MB | ~50 MB/Repo | PostgreSQL oder SQLite |
| n8n | Zapier, Make | ~100 MB | ~500 MB+ | Variiert je nach Workflows | PostgreSQL |
| Paperless-ngx | Aktenschrank | ~300 MB | ~1 GB | ~5 MB/Dokument | PostgreSQL + Redis |
| Nextcloud | Google Drive, Dropbox | ~250 MB | ~512 MB | Variiert je nach Dateien | PostgreSQL + Redis |
| Coolify | Vercel, Railway | ~500 MB | ~1,2 GB | Variiert je nach Deployments | PostgreSQL (gebündelt) |
| Plausible | Google Analytics | ~400 MB | ~1,5 GB | ~100 MB/1M Seitenaufrufe | PostgreSQL + ClickHouse |
| Immich | Google Photos | ~800 MB | ~2,5 GB | ~3 GB/1000 Fotos | PostgreSQL + Redis |
Einige Anmerkungen zu diesen Zahlen:
- Immich mit aktiviertem Machine Learning (Gesichts-/Objekterkennung) braucht 4-6 GB insgesamt. Die obigen Zahlen gelten bei aktiviertem, aber ruhendem ML. Während eines großen Foto-Imports rechnen Sie mit 3-4 GB. Sie können ML deaktivieren, um auf ~400 MB zu kommen, verlieren aber die intelligente Suche und Gesichtserkennung.
- Plausible: Der RAM-Verbrauch hängt vom Traffic-Volumen ab. ClickHouse liebt Arbeitsspeicher. Für eine Website mit unter 100.000 Seitenaufrufen/Monat gelten die obigen Zahlen. Hochfrequentierte Seiten brauchen mehr.
- n8n ist im Leerlauf leicht, aber komplexe Workflows mit großen JSON-Payloads oder KI-Integrationen verursachen heftige Spitzen. KI-Agenten-Workflows können 200 MB+ pro Ausführung verbrauchen.
- Paperless-ngx hat Spitzen während der OCR. Setzen Sie
PAPERLESS_WEBSERVER_WORKERS=1in Docker, um ~150 MB zu sparen, wenn Sie der einzige Nutzer sind.
Welche App sollte ich zuerst auf meinem VPS selbst hosten?
Beginnen Sie mit Vaultwarden. Die App verbraucht 25 MB RAM, lässt sich in unter 10 Minuten deployen, ersetzt einen kostenpflichtigen Passwort-Manager, den Sie täglich nutzen, und zwingt Sie dazu, TLS korrekt einzurichten. Dieses TLS-Setup (Reverse Proxy + DNS + Zertifikate) ist das Fundament, das jede weitere selbst gehostete App braucht. Eine App, drei Gewinne: Privatsphäre, Kostenersparnis und wiederverwendbare Infrastruktur.
| App | Privatsphäre-Relevanz | Setup-Komplexität | Ersetzter SaaS-Dienst | Min. RAM |
|---|---|---|---|---|
| Vaultwarden | Sehr hoch (Passwörter) | Niedrig (10 Min.) | Bitwarden/1Password | 128 MB |
| Immich | Hoch (persönliche Fotos) | Mittel (30 Min.) | Google Photos | 2 GB (4 GB mit ML) |
| Paperless-ngx | Hoch (Dokumente, Ausweise) | Mittel (20 Min.) | Aktenschrank + Scanner-Apps | 512 MB |
| Plausible | Mittel (Besucher-Analytics) | Mittel-hoch (25 Min.) | Google Analytics | 1 GB |
| Uptime Kuma + Beszel | Niedrig (Infra-Monitoring) | Niedrig (10 Min.) | UptimeRobot + Datadog | 256 MB |
| Gitea | Mittel (Quellcode) | Niedrig (15 Min.) | GitHub private Repos | 256 MB |
| n8n | Mittel (Workflow-Daten) | Mittel (20 Min.) | Zapier, Make | 512 MB |
| Coolify | Niedrig (Deployment-Tool) | Mittel (20 Min.) | Vercel, Railway | 1 GB |
Die Privatsphäre-Relevanz ist der stärkste Grund für Self-Hosting. Ihre Passwörter, Fotos und gescannten Dokumente sind die sensibelsten Daten, die Sie täglich handhaben. Diese auf fremden Servern zu hosten bedeutet, deren Sicherheit, Rechtsordnung und Geschäftskontinuität zu vertrauen. Auf Ihrem eigenen VPS in Europa bleiben diese Daten unter Ihrer Kontrolle und unter der DSGVO.
Die Setup-Komplexität berücksichtigt den gesamten Stack: App-Container, Datenbank, Reverse-Proxy-Konfiguration und erstes Backup. „Niedrig" bedeutet ein einzelnes docker compose up -d nach dem Schreiben einer Compose-Datei. „Mittel" fügt eine Datenbank und Storage-Volume-Konfiguration hinzu. „Mittel-hoch" umfasst mehrere voneinander abhängige Dienste (ClickHouse für Plausible, ML-Container für Immich).
Tutorials zu jeder App finden Sie über die Links am Ende dieses Guides.
Was kann ich auf einem 4-GB-VPS vs. einem 8-GB-VPS betreiben?
Ein 4-GB-VPS betreibt einen soliden persönlichen Stack. Ein 8-GB-VPS bewältigt alles, was ein Solo-Entwickler oder ein kleines Team braucht. Die folgenden Zahlen berücksichtigen den Reverse Proxy (~30 MB), Docker-Overhead und das Betriebssystem selbst (~300-400 MB belegt).
4 GB VPS (~3,2 GB verfügbar für Apps)
| Stack-Kombination | RAM Leerlauf gesamt | Reserven |
|---|---|---|
| Vaultwarden + Uptime Kuma + Beszel + Gitea | ~325 MB | ~2,9 GB |
| Vaultwarden + Paperless-ngx + Uptime Kuma | ~425 MB | ~2,8 GB |
| Vaultwarden + n8n + Beszel + Gitea | ~325 MB | ~2,9 GB |
| Vaultwarden + Nextcloud + Uptime Kuma | ~375 MB | ~2,8 GB |
Diese Kombinationen lassen reichlich Reserven für Spitzenlasten. Selbst wenn Paperless-ngx während der OCR auf 1 GB hochgeht, ist noch Platz. Vermeiden Sie Immich mit ML oder Plausible auf 4 GB, es sei denn, es ist die einzige App.
8 GB VPS (~7 GB verfügbar für Apps)
| Stack-Kombination | RAM Leerlauf gesamt | Reserven |
|---|---|---|
| Vaultwarden + Immich + Uptime Kuma + Beszel | ~975 MB | ~6 GB |
| Vaultwarden + Plausible + Gitea + Paperless-ngx + Beszel | ~925 MB | ~6 GB |
| Vaultwarden + Coolify + Uptime Kuma + n8n | ~725 MB | ~6,3 GB |
| Alle leichtgewichtigen (Vaultwarden + Gitea + Uptime Kuma + Beszel + n8n + Paperless-ngx) | ~725 MB | ~6,3 GB |
Mit 8 GB können Sie Immich mit ML komfortabel neben drei oder vier leichtgewichtigen Apps betreiben. Sie können auch Plausible mit ClickHouse laufen lassen, ohne sich Sorgen um Speicherdruck zu machen. Das ist der Sweet Spot für ein persönliches Self-Hosting-Setup.
Hinweis zu Spitzenlasten: Der Leerlauf-RAM ist das, wofür Sie planen, aber Spitzen sind das, was Ihren Server abstürzen lässt. Paperless-ngx hat Spitzen während der OCR. Immich hat Spitzen beim Foto-Import mit ML-Klassifizierung. n8n hat Spitzen bei der Ausführung von Workflows mit großen Payloads. Die Reserven-Spalte oben ist Ihr Sicherheitspuffer. Wenn die Reserven unter 1 GB fallen, riskieren Sie, dass der Linux OOM Killer einen Container im ungünstigsten Moment beendet. Halten Sie mindestens 1,5 GB Reserven für jeden Stack, der Immich oder Plausible enthält.
Für einen Virtua Cloud VPS mit 4 vCPU und 8 GB RAM auf NVMe-Speicher sehen Sie sich die aktuellen Pläne an. Der Standort Frankfurt platziert Ihre Daten in der EU unter deutschem Datenschutzrecht.
Welche selbst gehosteten Apps brauchen europäisches Hosting?
Jede App, die personenbezogene Daten speichert, profitiert von europäischem Hosting unter der DSGVO. Aber einige Apps verarbeiten Daten, bei denen die Standortfrage dringend wird.
Hohe Priorität für EU-Hosting:
- Vaultwarden speichert jedes Passwort, das Sie besitzen. Ein Datenleck hier ist katastrophal. Europäisches Hosting bedeutet, dass die Meldepflichten der DSGVO bei Datenschutzverletzungen gelten.
- Immich enthält persönliche Fotos, oft mit Gesichtern von Familienmitgliedern. Gesichtserkennungsdaten sind biometrische Daten nach Artikel 9 DSGVO. Besondere Kategorie. Zusätzliche Schutzmaßnahmen.
- Paperless-ngx speichert gescannte Ausweise, Steuerdokumente, Verträge. Einige der sensibelsten personenbezogenen Daten, die Sie haben.
Mittlere Priorität:
- Plausible erfasst Besucher-Analytics. Das Tool ist privacy-first by Design (keine Cookies, keine personenbezogenen Daten), aber die Daten gehören trotzdem Ihren Website-Besuchern.
- Gitea kann proprietären Quellcode enthalten. Keine personenbezogenen Daten im engeren Sinne, aber geistiges Eigentum, das Sie kontrollieren wollen.
- n8n-Workflows verarbeiten oft Daten aus mehreren Diensten. Die Automatisierungsschicht sieht alles.
Niedrigere Priorität:
- Uptime Kuma / Beszel speichern Monitoring-Daten. Keine personenbezogenen Daten, es sei denn, Sie überwachen Endpunkte, die solche enthalten.
- Coolify ist ein Deployment-Tool. Es verarbeitet Ihren Code, speichert aber keine Endnutzerdaten.
Wenn Sie ein europäisches Unternehmen sind oder Daten von EU-Bürgern verarbeiten, vereinfacht das Hosting dieser Apps auf einem VPS in Deutschland (oder einem anderen EU-Land) Ihre DSGVO-Compliance. Sie kontrollieren die Daten. Sie wissen, wo sie sind. Sie bestimmen, wer Zugriff hat.
Wie halte ich meine selbst gehosteten Apps sicher und aktuell?
Self-Hosting bedeutet, dass Sie der Systemadministrator sind. Das ist der Preis für die Kontrolle. Hier sind die nicht verhandelbaren Praktiken:
Firewall zuerst. Bevor Sie eine App deployen, konfigurieren Sie ufw, um nur SSH (Port 22) und HTTPS (Port 443) zuzulassen. Blockieren Sie alles andere. Das wird in Docker in Produktion auf einem VPS: Was schiefgeht und wie Sie es beheben behandelt.
TLS überall. Ihr Reverse Proxy (Caddy oder Traefik) übernimmt die TLS-Terminierung. Jede App bekommt HTTPS. Ohne Ausnahme. Kein „TLS kommt später". Caddy provisioniert Let's-Encrypt-Zertifikate automatisch.
Updates. Prüfen Sie wöchentlich auf Container-Image-Updates. Laden Sie neue Images herunter, erstellen Sie Container neu:
docker compose pull
docker compose up -d
Für kritische Sicherheitsupdates (Vaultwarden, jede internetexponierte App) abonnieren Sie die GitHub-Releases des Projekts oder den RSS-Feed. Vaultwarden Releases und Immich Releases sind gute Beispiele.
Backups. Testen Sie sie. Ein Backup, das Sie nie wiederhergestellt haben, ist kein Backup. Verwenden Sie Anbieter-Snapshots für die vollständige Festplattenwiederherstellung und Restic oder borgmatic für Offsite-Backups auf App-Ebene. Planen Sie sie mit cron oder einem systemd-Timer. Überprüfen Sie sie monatlich.
Secrets-Management. Schreiben Sie Passwörter nie direkt in docker-compose.yml. Verwenden Sie eine .env-Datei mit chmod 600:
openssl rand -base64 32 > /dev/null # example: generate a strong password
# docker-compose.yml
services:
app:
env_file: .env
# .env (chmod 600, owned by root)
DB_PASSWORD=<generated-password>
SECRET_KEY=<generated-key>
Monitoring. Betreiben Sie Uptime Kuma für externe Endpoint-Checks und Beszel für Container-Level-Metriken (CPU, RAM, Festplatte pro Container). Beide sind leichtgewichtig und geben Ihnen Einblick, bevor Probleme zu Ausfällen werden. Siehe Uptime Kuma und Beszel auf einem VPS mit Docker Compose selbst hosten.
Log-Bewusstsein. Wissen Sie, wo Ihre Logs sind. Docker-Container loggen standardmäßig auf stdout:
docker compose logs -f --tail=50 <service-name>
Für System-Level-Dienste (der Reverse Proxy, wenn er nativ läuft, SSH, Firewall) nutzen Sie journalctl:
journalctl -u caddy -f
Wenn etwas kaputtgeht, sind Logs Ihre erste Anlaufstelle. Nicht Stack Overflow. Nicht Reddit. Logs.
Wie geht es weiter?
Jede App in der obigen Entscheidungsmatrix hat ein eigenes Tutorial mit vollständigen Docker-Compose-Konfigurationen, Reverse-Proxy-Setup, Backups und Härtung:
| App | Tutorial |
|---|---|
| Vaultwarden (Passwörter) | Vaultwarden auf einem VPS mit Docker Compose selbst hosten |
| Immich (Fotos) | Immich auf einem VPS mit Docker Compose selbst hosten |
| Plausible (Analytics) | Plausible Analytics auf einem VPS mit Docker Compose selbst hosten |
| Uptime Kuma + Beszel (Monitoring) | Uptime Kuma und Beszel auf einem VPS mit Docker Compose selbst hosten |
| Coolify vs Dokploy (PaaS) | Coolify vs Dokploy: Welches selbstgehostete PaaS für Ihren VPS? |
| Paperless-ngx (Dokumente) | Paperless-ngx auf einem VPS mit Docker Compose selbst hosten |
| Gitea (Git-Hosting) | Gitea auf einem VPS mit Docker Compose selbst hosten |
Wenn Sie Docker und einen Reverse Proxy noch nicht eingerichtet haben, starten Sie hier: Docker in Produktion auf einem VPS: Was schiefgeht und wie Sie es beheben. Dieser Guide behandelt Debian 12 und Ubuntu 24.04, installiert Docker mit Compose, konfiguriert Caddy als Reverse Proxy mit automatischem TLS, richtet eine Firewall ein und erstellt einen Non-Root-Deploy-Benutzer. Alles in diesem Guide baut auf diesem Fundament auf.
Bereit, es selbst auszuprobieren?
Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD. →