Self-Hosting-Stack für einen kleinen VPS: Was in 2 GB und 4 GB RAM passt

Kurz gesagt: Ein VPS mit 2 GB betreibt bequem einen selbst gehosteten Kern aus Caddy (HTTPS-Reverse-Proxy), Vaultwarden (Passwörter), Uptime Kuma (Monitoring) und Forgejo (git) unter Docker Compose und braucht dafür etwa 0,6 bis 1 GB RAM. Kommt Nextcloud hinzu, sollten es 4 GB sein; mit leichteren Tools wie Syncthing oder File Browser reichen 2 GB weiterhin.

Diese Anleitung liefert eine funktionierende Compose-Datei, ein RAM-Budget pro Dienst und die zwei Dinge, die die meisten Self-Hosting-Setups auslassen, bis es zu spät ist: externe Backups und eine abgeschottete Netzwerkangriffsfläche. Die Befehle setzen Debian 12/13 oder Ubuntu 24.04 mit Docker Engine und dem Compose-Plugin aus dem offiziellen Docker-Repository voraus.

RAM-Budget pro Dienst

Die Werte sind typischer residenter Speicher im Leerlauf bis bei leichter Nutzung für ein bis fünf Nutzer, mit SQLite, wo unterstützt. Spitzen bei Upgrades, git-Klonen großer Repositories oder Nextcloud-Vorschauen können höher liegen — lassen Sie also mindestens 20 % Reserve und legen Sie eine Swap-Datei mit 1 bis 2 GB an.

Die VPS-Größe wählen

Der Kern-Stack (Caddy, Vaultwarden, Uptime Kuma, Forgejo) plus Basissystem landet bei etwa 0,6 bis 1 GB und passt damit auf einen Server mit 2 vCPU / 2 GB, mit Platz für Syncthing und Radicale. Nextcloud mit MariaDB und Redis treibt die Summe auf etwa 1,5 bis 2,2 GB, sodass 4 GB das realistische Minimum sind, wenn Sie die komplette Suite plus alles andere wollen. Auch die Disk zählt: Forgejo-Repositories und synchronisierte Dateien wachsen, während die Dienste selbst nur wenige GB brauchen.

Bei NoctisNode passt der Plan Pulse (2 vCPU, 2 GB RAM, 40 GB NVMe, $10 pro 28 Tage) für den Kern-Stack und Umbra (4 vCPU, 4 GB, 60 GB NVMe, $15 pro 28 Tage) für den Kern plus Nextcloud. Beide sind KVM mit vollem Root-Zugriff und einer dedizierten IPv4 und lassen sich mit Monero oder anderer Krypto bezahlen. Nichts in dieser Anleitung hängt vom Anbieter ab.

Docker-Compose-Datei

Nur Caddy veröffentlicht Web-Ports; die Apps sind ausschließlich über das interne Compose-Netzwerk erreichbar. Forgejo veröffentlicht zusätzlich Port 2222 für git über SSH, sodass das OpenSSH des Hosts auf seinem eigenen Port bleibt. Setzen Sie `FORGEJO_TAG` in einer `.env`-Datei auf die aktuelle Forgejo-Hauptversion und ersetzen Sie die Beispiel-Domains durch Ihre eigenen DNS-Records.

# /srv/stack/compose.yaml
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config

  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"   # set to "false" after creating your account
    volumes:
      - ./vaultwarden:/data

  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./uptime-kuma:/app/data

  forgejo:
    image: codeberg.org/forgejo/forgejo:${FORGEJO_TAG}
    restart: unless-stopped
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__service__DISABLE_REGISTRATION: "true"
    volumes:
      - ./forgejo:/data
    ports:
      - "2222:22"

# /srv/stack/Caddyfile
# vault.example.com {
#     reverse_proxy vaultwarden:80
# }
# status.example.com {
#     reverse_proxy uptime-kuma:3001
# }
# git.example.com {
#     reverse_proxy forgejo:3000
# }

Hochfahren

1. 01.Lassen Sie A- (und AAAA-)Records für `vault`, `status` und `git` auf die IP des Servers zeigen, damit Caddy beim ersten Start Zertifikate holen kann.
2. 02.Legen Sie `/srv/stack` an, platzieren Sie dort `compose.yaml`, `Caddyfile` und `.env` und führen Sie `docker compose up -d` aus.
3. 03.Öffnen Sie die Forgejo-URL und schließen Sie den Installer ab; das erste darüber angelegte Konto wird Admin, da die öffentliche Registrierung deaktiviert ist.
4. 04.Legen Sie Ihr Vaultwarden-Konto an, setzen Sie dann `SIGNUPS_ALLOWED` auf `"false"` und führen Sie erneut `docker compose up -d` aus. Lassen Sie das Admin-Panel deaktiviert, sofern Sie kein mit Argon2 gehashtes `ADMIN_TOKEN` setzen.
5. 05.Legen Sie den Admin-Benutzer von Uptime Kuma direkt nach dem Start an, denn die Setup-Seite ist bis dahin für jeden offen.
6. 06.Fügen Sie Monitore für jeden Dienst und für den Ablauf der Zertifikate hinzu, idealerweise von einem zweiten Standort aus, da ein Monitor auf demselben Server seinen eigenen Ausfall nicht melden kann.

Note · Caddy kümmert sich automatisch um HTTPS. Für Header, Rate Limits und komplexeres Routing siehe die Anleitung zu Caddy als Reverse Proxy.

Backups, die sich wirklich wiederherstellen lassen

Alles, was es wert ist, aufbewahrt zu werden, liegt unter `/srv/stack`: SQLite-Datenbanken, Forgejo-Repositories, Caddy-Zertifikate und Ihre Konfiguration. Verlassen Sie sich nicht auf Snapshots des Anbieters; halten Sie mit restic eine eigene verschlüsselte, externe Kopie, wie in der Anleitung zu restic-Backups beschrieben.

SQLite-Dateien, die kopiert werden, während ein Dienst schreibt, können inkonsistent sein. Der einfachste sichere Weg auf einem kleinen Server ist, den Stack für die Minute anzuhalten, die ein Backup dauert. Wenn Sie Nextcloud mit MariaDB hinzufügen, sichern Sie die Datenbank vor dem restic-Lauf mit `mariadb-dump`. Testen Sie mindestens einmal eine Wiederherstellung in ein Testverzeichnis; ein nie wiederhergestelltes Backup ist eine Vermutung.

#!/bin/sh
# /usr/local/sbin/stack-backup (run nightly from cron or a systemd timer)
# needs RESTIC_REPOSITORY and RESTIC_PASSWORD_FILE in the environment
cd /srv/stack || exit 1
docker compose stop
rc=0
restic backup /srv/stack --tag stack || rc=$?
docker compose start
[ "$rc" -eq 0 ] || exit "$rc"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Sicherheitsgrundlagen

• ▹SSH: nur Schlüssel, kein Root-Login per Passwort, optional ein Nicht-Standard-Port; siehe [die Anleitung zur SSH-Härtung](/guides/ssh-hardening).
• ▹Vorsicht bei der Firewall: Von Docker veröffentlichte Ports umgehen `ufw`-Regeln, weil Docker eigene iptables-/nftables-Chains schreibt. Veröffentlichen Sie nur, was öffentlich sein muss (80, 443, 2222), und nie Datenbank- oder Admin-Ports.
• ▹Updates: Aktivieren Sie `unattended-upgrades` für den Host und führen Sie `docker compose pull && docker compose up -d` nach einem Zeitplan aus, den Sie auch wirklich einhalten.
• ▹Registrierung: Lassen Sie öffentliche Registrierungen in Vaultwarden und Forgejo deaktiviert; laden Sie Nutzer stattdessen ein.
• ▹Disk-Verschlüsselung: Legen Sie `/srv` auf ein [verschlüsseltes Root](/guides/luks-encrypted-root), damit ein kopiertes Disk-Image nichts preisgibt; auf einem entfernten Server nutzen Sie [LUKS-Entsperren per SSH](/guides/luks-remote-unlock-ssh) und bevorzugen das Format LUKS2, erklärt in [LUKS2 vs. LUKS1](/guides/luks2-vs-luks1).
• ▹Secrets: `.env` und das Datenverzeichnis von Vaultwarden sollten nur für root lesbar sein (`chmod 600`/`700`).

FAQ