Docker Compose auf dem VPS: Webserver, Datenbank und Reverse Proxy richtig betreiben

Docker Compose auf einem VPS ist für viele Webprojekte der pragmatische Mittelweg zwischen klassischem LAMP-Server und großem Kubernetes-Cluster. Du kannst einen Webserver, eine Datenbank, einen Cache, einen Reverse Proxy und Hilfsdienste in einer einzigen YAML-Struktur beschreiben, versionieren und mit wenigen Befehlen starten. Gerade für Blogs, SaaS-Prototypen, interne Tools, kleine Shops oder Kundenprojekte ist das schnell, günstig und gut wartbar.

Damit ein Compose-Setup nicht nur lokal funktioniert, sondern auch dauerhaft im Internet zuverlässig läuft, braucht es jedoch mehr als docker compose up -d. Entscheidend sind eine klare Netzwerkstruktur, persistente Volumes, ein sinnvoll konfigurierter Reverse Proxy, automatische TLS-Zertifikate, Backups, Ressourcenlimits und ein sauberer Update-Prozess. Dieser Guide zeigt dir, wie du Webserver, Datenbank und Reverse Proxy auf einem VPS richtig betreibst.

Wann Docker Compose auf dem VPS sinnvoll ist

Docker Compose eignet sich ideal, wenn du wenige bis einige Dutzend Container auf einem einzelnen Server betreiben möchtest. Typische Szenarien sind WordPress mit MariaDB, ein Node.js-Backend mit PostgreSQL, ein Laravel-Projekt mit Redis oder mehrere kleine Apps hinter einem gemeinsamen Reverse Proxy. Der große Vorteil: Alle Abhängigkeiten sind gekapselt, Deployments sind reproduzierbar und du kannst die Konfiguration im Git-Repository pflegen.

Nicht jede Umgebung sollte mit Compose gelöst werden. Wenn du automatische horizontale Skalierung, mehrere Worker-Nodes, Self-Healing über Cluster-Grenzen oder komplexe Service Meshes brauchst, ist Kubernetes oft passender. Für die meisten kleinen Produktionssysteme ist ein gut gehärteter VPS mit Docker Compose aber einfacher, günstiger und schneller zu verstehen.

Die richtige VPS-Basis wählen

Für produktive Docker-Setups solltest du bei der Servergröße nicht zu knapp planen. Ein einzelnes kleines Webprojekt läuft oft bereits mit 2 vCPU, 4 GB RAM und 40 bis 80 GB SSD. Sobald Datenbank, Backups, Monitoring oder mehrere Apps dazukommen, sind 4 vCPU, 8 GB RAM und 100 GB NVMe die deutlich entspanntere Basis. Wichtig sind außerdem ein aktuelles Linux wie Debian oder Ubuntu LTS, IPv4-Erreichbarkeit, zuverlässige Snapshots und ein Anbieter mit transparenter Netzwerkanbindung.

Plane Speicher nicht nur für die App, sondern auch für Datenbankwachstum, Logdateien, Docker-Images und temporäre Backup-Archive. Docker kann alte Images und Build-Caches ansammeln; regelmäßiges Aufräumen gehört deshalb zum Betrieb. Für Lern- und Administrationsmaterial lohnt sich ein Blick auf Docker- und Linux-Server-Bücher bei Amazon*.

Grundstruktur: Reverse Proxy, App-Netz und Datenbank-Netz

Ein häufiges Anti-Pattern ist, alle Container direkt mit Ports ins Internet zu hängen. Besser ist eine klare Trennung: Nur der Reverse Proxy veröffentlicht Port 80 und 443. Die eigentlichen Anwendungen kommunizieren intern über Docker-Netzwerke. Datenbanken bleiben grundsätzlich ohne öffentlichen Port und sind nur für die jeweilige App erreichbar.

Bewährt hat sich eine Struktur mit einem externen Proxy-Netzwerk, zum Beispiel proxy, und separaten internen Netzen pro Projekt. Der Reverse Proxy hängt im Proxy-Netz. Jede App, die öffentlich erreichbar sein soll, wird ebenfalls mit diesem Netzwerk verbunden. Datenbank und Cache liegen zusätzlich in einem internen Backend-Netz, das der Proxy nicht benötigt. So reduzierst du die Angriffsfläche erheblich.

Reverse Proxy: Traefik, Caddy oder Nginx Proxy Manager?

Der Reverse Proxy nimmt eingehende HTTP- und HTTPS-Anfragen entgegen und leitet sie an den passenden Container weiter. Für Docker Compose sind drei Optionen besonders beliebt: Traefik, Caddy und Nginx Proxy Manager. Traefik erkennt Container über Labels und ist sehr flexibel. Caddy ist minimalistisch und bringt automatisches HTTPS elegant mit. Nginx Proxy Manager bietet eine Weboberfläche und ist für Einsteiger angenehm.

Für produktive DevOps-Setups ist Traefik oft die beste Wahl, weil Routing-Regeln, Middlewares und Zertifikate direkt in der Compose-Datei dokumentiert werden können. Beispielhaft setzt du Labels wie Host-Regel, TLS-Aktivierung und Zielport am App-Container. Dadurch bleibt das Setup nachvollziehbar und du musst keine separaten Nginx-Konfigurationsdateien pflegen.

Beispiel: Compose-Aufbau für Webapp und Datenbank

Eine typische Compose-Datei besteht aus drei Bereichen: Services, Volumes und Networks. Der Webservice nutzt ein Image oder wird aus deinem Code gebaut. Die Datenbank erhält ein festes Volume für persistente Daten. Sensible Werte wie Passwörter gehören nicht hart in die YAML-Datei, sondern in eine .env-Datei oder in Docker Secrets, wenn dein Setup dafür vorbereitet ist.

services:
  app:
    image: example/webapp:latest
    restart: unless-stopped
    env_file: .env
    networks:
      - proxy
      - backend
    depends_on:
      - db
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`example.com`)"
      - "traefik.http.routers.app.tls.certresolver=letsencrypt"
      - "traefik.http.services.app.loadbalancer.server.port=3000"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - backend

volumes:
  db_data:

networks:
  proxy:
    external: true
  backend:
    internal: true

Dieses Beispiel zeigt das Grundprinzip: Der App-Container ist über den Proxy erreichbar, die Datenbank jedoch nur intern. restart: unless-stopped sorgt dafür, dass Container nach einem Reboot wieder starten. depends_on ersetzt allerdings keinen echten Healthcheck; für kritische Dienste solltest du zusätzlich prüfen, ob die Datenbank wirklich bereit ist.

Volumes und Backups: Daten sind wichtiger als Container

Container sind austauschbar, Daten nicht. Deshalb verdienen Volumes besondere Aufmerksamkeit. Für Datenbanken solltest du nicht nur das Volume sichern, sondern regelmäßige logische Dumps erstellen, etwa mit pg_dump oder mysqldump. Diese Dumps lassen sich leichter prüfen, versionieren und auf einem anderen Server wiederherstellen als rohe Dateisystemkopien einer laufenden Datenbank.

Ein solides Backup-Konzept enthält mindestens tägliche Datenbank-Dumps, wöchentliche Vollsicherungen, externe Speicherung und Wiederherstellungstests. Backups, die nie zurückgespielt wurden, sind nur eine Hoffnung. Bewahre Kopien nicht ausschließlich auf demselben VPS auf. Ein defektes Volume, eine kompromittierte Maschine oder ein versehentliches Löschen kann sonst alle Sicherungen gleichzeitig treffen.

Updates ohne unnötige Downtime

Docker Compose macht Updates einfach, aber nicht automatisch risikofrei. Der übliche Ablauf lautet: Images aktualisieren, Datenbank sichern, neue Version starten und Logs prüfen. Verwende konkrete Image-Tags statt blindem latest, wenn Stabilität wichtiger ist als maximale Aktualität. Bei Webapps kannst du vor dem Update einen Snapshot des VPS erstellen und zusätzlich ein Datenbank-Backup anlegen.

Kommandos wie docker compose pull, docker compose up -d und docker image prune reichen oft aus. Für größere Projekte lohnt sich ein Staging-Server, auf dem du Updates zuerst testest. Wenn Datenbankmigrationen beteiligt sind, solltest du Rollback-Szenarien vorab klären. Nicht jede Migration lässt sich einfach rückgängig machen.

Sicherheit: SSH, Firewall, Secrets und Rechte

Ein Docker-VPS ist nur so sicher wie sein Basissystem. Deaktiviere Passwort-Logins per SSH, nutze Schlüssel, halte das System aktuell und öffne in der Firewall nur die notwendigen Ports. In der Regel sind das 22 für SSH sowie 80 und 443 für den Reverse Proxy. Datenbankports wie 5432 oder 3306 gehören nicht ins öffentliche Internet.

Secrets sollten nicht im Git-Repository landen. Nutze .env-Dateien mit restriktiven Dateirechten und füge sie in .gitignore ein. Prüfe außerdem, ob deine Container wirklich als Root laufen müssen. Viele Images unterstützen eigene User. Setze Ressourcenlimits, damit ein einzelner Dienst nicht den ganzen VPS lahmlegt. Für passendes Zubehör und Fachliteratur findest du Linux-Server-Administration bei Amazon*.

Monitoring und Logs nicht vergessen

Ohne Monitoring bemerkst du Probleme oft erst, wenn Nutzer sie melden. Mindestens solltest du CPU, RAM, Disk, Netzwerk, Containerstatus und Zertifikatslaufzeiten überwachen. Für kleine Setups reichen Uptime Kuma, Netdata oder ein externer Uptime-Monitor. Wer mehr Transparenz möchte, kombiniert Prometheus, cAdvisor und Grafana.

Logs sollten begrenzt werden, damit sie die Festplatte nicht füllen. Docker unterstützt Logging-Optionen wie max-size und max-file. Zusätzlich lohnt sich ein regelmäßiger Blick auf docker compose logs, besonders nach Updates. Kritische Fehler gehören in ein Alerting-System, nicht nur in eine Datei, die niemand liest.

DNS, TLS und Domains sauber planen

Bevor du Container startest, sollte DNS vorbereitet sein. A- und AAAA-Records zeigen auf deinen VPS, Subdomains trennen Dienste logisch: etwa app.example.com, admin.example.com oder monitoring.example.com. Der Reverse Proxy kann dann pro Hostname die passende App auswählen. Let's Encrypt-Zertifikate funktionieren zuverlässig, wenn Port 80 oder ein DNS-Challenge-Verfahren korrekt konfiguriert ist.

Achte darauf, interne Dashboards nicht versehentlich öffentlich zu machen. Adminbereiche sollten mindestens durch starke Passwörter, besser zusätzlich durch IP-Filter, Basic Auth, VPN oder Single Sign-on geschützt sein. Ein Reverse Proxy ist bequem, aber er macht auch schnell Dinge erreichbar, die eigentlich privat bleiben sollten.

Häufige Fehler bei Docker Compose auf dem VPS

• Zu viele öffentliche Ports: Nur der Reverse Proxy sollte 80 und 443 veröffentlichen.
• Keine Backups: Volumes ohne Wiederherstellungsstrategie sind ein großes Risiko.
• Unklare Image-Tags: latest kann ungewollte Major-Updates auslösen.
• Keine Ressourcenlimits: Ein fehlerhafter Container kann RAM und CPU blockieren.
• Secrets im Repository: Zugangsdaten gehören nicht in Git.
• Fehlende Log-Rotation: Logs können unbemerkt die SSD füllen.

Checkliste für den produktiven Betrieb

Vor dem Go-live solltest du folgende Punkte abhaken: Domain zeigt auf den VPS, TLS-Zertifikat wird automatisch erneuert, Datenbank ist nicht öffentlich erreichbar, Backups laufen extern, Firewall ist aktiv, SSH ist gehärtet, Logs sind begrenzt, Monitoring ist eingerichtet und Updates wurden mindestens einmal getestet. Zusätzlich solltest du dokumentieren, wie ein Restore funktioniert und welche Befehle im Notfall nötig sind.

Wenn du Docker Compose intensiver nutzen möchtest, können Bücher und Referenzen helfen, typische Fehler schneller zu vermeiden. Eine passende Suche ist Docker Compose VPS Server bei Amazon*. Mehr Grundlagen zu DevOps-Werkzeugen findest du außerdem in unserem Artikel DevOps-Tools im Überblick.

Fazit

Docker Compose auf dem VPS ist eine starke Lösung, wenn du Kontrolle, niedrige Kosten und einfache Deployments kombinieren möchtest. Der Schlüssel liegt in sauberer Trennung: Reverse Proxy nach außen, Anwendungen in definierten Netzen, Datenbanken intern und Daten in gesicherten Volumes. Mit Backups, Monitoring, Firewall, festen Update-Prozessen und dokumentierten Restore-Schritten wird aus einem schnellen Container-Experiment eine belastbare Produktionsumgebung.

Für viele Teams ist genau dieser Ansatz der beste Einstieg in moderne DevOps-Praxis: klein genug, um überschaubar zu bleiben, aber professionell genug, um echte Webprojekte sicher zu betreiben.