Mehrere Dienste auf einem Server

Wann zusammenlegen – und wann nicht

Kombiniert wird nach Plattform, nicht nach Anleitung.

Jede Anleitung installiert eine Basis (Container-Engine, k3s, OKD …) und einen Workload. Die Basis ist der teure, wartungsintensive Teil – den legst du einmal an und betreibst mehrere Workloads darauf.

• developer-sandbox ist gehostet – nichts zu kombinieren.
• Docker-Host und k3s auf derselben Box: technisch möglich, wird aber unsauber (beide wollen Port 80/443, cgroups, iptables). Eins nehmen.
• Wenn du ohnehin Kubernetes lernen willst: k3s ist die universelle Basis – darauf läuft auch WordPress + Vaultwarden als simple Manifeste. Diese Anleitung bleibt bei Docker Compose, weil das für 2–6 Dienste am wenigsten bewegliche Teile hat.

Die Architektur

Ein Proxy besitzt Port 443. Jeder Dienst ist ein eigenes Compose-Stack in seinem eigenen Netz. Nach außen reden nur Proxy und SSH (Secure Shell).

Die drei Regeln

1. Genau ein Ding hört auf 80/443 – der Reverse Proxy. Jede App bekommt keine ports:, nur einen Anschluss ans gemeinsame proxy-Netz + Traefik-Labels.
2. Ein Stack pro Dienst – eigenes Verzeichnis, eigenes compose.yaml, eigenes .env, eigene benannte Volumes, eigener DB-User. So lässt sich ein Dienst einzeln updaten, sichern, zurückrollen, löschen.
3. Interne Dienste bleiben intern – die Datenbank hängt nur im wp_internal-Netz, nie im proxy-Netz und nie mit ports:. Nur der HTTP-Container jeder App ist in beiden Netzen.

Warum Traefik Alternativen

Traefik liest die Routing-Regeln aus den Compose-Labels – neue App = Labels dran, sonst nichts. Caddy ist noch simpler zu konfigurieren (ein Caddyfile), aber ohne Label-Automatik. Nginx Proxy Manager hat eine Web-Oberfläche, wenn du Routen lieber klickst. Alle drei können Let’s Encrypt. Das Muster unten gilt sinngemäß für alle.

Server dimensionieren

RAM (Random Access Memory) ist der Engpass, nicht CPU (Central Processing Unit). Rechne pro Dienst mit Ruhe- und Lastwert.

Datei-Layout auf dem Server

Ein Verzeichnis pro Dienst unter /opt/stacks/. Alles, was ein Dienst braucht, liegt beisammen – leicht zu sichern, zu verschieben, zu löschen.

/opt/stacks/
├─ traefik/
│  ├─ compose.yaml
│  ├─ traefik.yaml          # statische Konfig
│  ├─ dynamic/security.yaml  # Middlewares
│  └─ acme.json             # Zertifikate  (chmod 600)
├─ wordpress/
│  ├─ compose.yaml
│  ├─ .env                  # DB-Passwoerter  (chmod 600)
│  └─ db/my.cnf             # DB-Tuning
├─ vaultwarden/
│  ├─ compose.yaml
│  └─ .env
└─ backup/
   ├─ backup.sh
   └─ .env                  # Storage-Box-Ziel

# Volumes verwaltet Docker (docker volume ls) - Daten NICHT unter /opt/stacks,
# sondern in /var/lib/docker/volumes. Das Backup-Skript zieht sie da raus.

Server + Grundhärtung

Setzt Server-Basis voraus (Konto, Token, hcloud, SSH-Key). Der Server hier wie container-host, plus die Punkte aus der Grundausstattung. Für 3–4 Stacks eher CPX32 als CPX22 (RAM).

# Cloud-Firewall: nur SSH + HTTP + HTTPS
hcloud firewall create --name web-fw
hcloud firewall add-rule web-fw --direction in --protocol tcp --port 22  --source-ips 0.0.0.0/0
hcloud firewall add-rule web-fw --direction in --protocol tcp --port 80  --source-ips 0.0.0.0/0
hcloud firewall add-rule web-fw --direction in --protocol tcp --port 443 --source-ips 0.0.0.0/0

hcloud server create --name dienste --type cpx22 --image debian-12 `
  --ssh-key laptop --firewall web-fw --user-data-from-file cloud-init.yaml

#cloud-config
package_update: true
packages: [ ca-certificates, curl, fail2ban, unattended-upgrades ]
runcmd:
  # Docker Engine + Compose-Plugin
  - curl -fsSL https://get.docker.com | sh
  # non-root Betriebsuser
  - useradd -m -s /bin/bash -G docker deploy
  - install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
  - cp /root/.ssh/authorized_keys /home/deploy/.ssh/ && chown deploy:deploy /home/deploy/.ssh/authorized_keys
  # SSH haerten
  - sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/;s/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
  - systemctl restart ssh
  # 1 GB Swap als OOM-Puffer
  - fallocate -l 1G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
  - echo '/swapfile none swap sw 0 0' >> /etc/fstab
  # Docker-Logs begrenzen (sonst laeuft die Disk voll)
  - |
    cat > /etc/docker/daemon.json <<'EOF'
    { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }
    EOF
  - systemctl restart docker
  - mkdir -p /opt/stacks
  - docker network create proxy
write_files:
  - path: /etc/apt/apt.conf.d/20auto-upgrades
    content: |
      APT::Periodic::Update-Package-Lists "1";
      APT::Periodic::Unattended-Upgrade "1";

Traefik als Edge-Proxy

Einmal aufgesetzt. Danach reicht jeder App ein paar Labels.

services:
  traefik:
    image: traefik:v3.3
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yaml:/etc/traefik/traefik.yaml:ro
      - ./dynamic:/etc/traefik/dynamic:ro
      - ./acme.json:/acme.json
    networks: [ proxy ]
    labels:
      - traefik.enable=true
      # Dashboard nur ueber Basic-Auth + eigene Subdomain
      - traefik.http.routers.dash.rule=Host(`traefik.seb4u.com`)
      - traefik.http.routers.dash.entrypoints=websecure
      - traefik.http.routers.dash.tls.certresolver=le
      - traefik.http.routers.dash.service=api@internal
      - traefik.http.routers.dash.middlewares=dashauth
      - traefik.http.middlewares.dashauth.basicauth.users=admin:$$apr1$$...    # htpasswd -nbB admin '...'

networks:
  proxy:
    external: true

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint: { to: websecure, scheme: https, permanent: true }
  websecure:
    address: ":443"
    http:
      middlewares: [ secure-headers@file ]

providers:
  docker:
    exposedByDefault: false      # nur Container mit traefik.enable=true
    network: proxy
  file:
    directory: /etc/traefik/dynamic
    watch: true

certificatesResolvers:
  le:
    acme:
      email: admin@seb4u.com
      storage: /acme.json
      tlsChallenge: {}            # kein Port 80 noetig, laeuft ueber 443

api:
  dashboard: true

log:
  level: INFO
accessLog: {}

http:
  middlewares:
    secure-headers:
      headers:
        stsSeconds: 63072000
        stsIncludeSubdomains: true
        stsPreload: true
        frameDeny: true
        contentTypeNosniff: true
        referrerPolicy: strict-origin-when-cross-origin
    ratelimit:
      rateLimit: { average: 100, burst: 50 }

cd /opt/stacks/traefik
touch acme.json && chmod 600 acme.json
# DNS: traefik. / blog. / vault.  -> A-Record auf die Server-IP (bei Cloudflare, grau/DNS only)
docker compose up -d
docker compose logs -f traefik      # auf "Configuration loaded" warten

WordPress + Datenbank

Ein Stack mit drei Containern: wordpress, db (MariaDB), redis. DB und Redis hängen nur im internen Netz.

DB_NAME=wp_blog
DB_USER=wp_blog
DB_PASSWORD=# openssl rand -base64 24
WP_HOST=blog.seb4u.com

services:
  db:
    image: mariadb:11.4
    restart: unless-stopped
    command:
      - --transaction-isolation=READ-COMMITTED   # von WordPress empfohlen
      - --binlog-format=ROW
      - --innodb-buffer-pool-size=512M
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    environment:
      MARIADB_DATABASE: ${DB_NAME}
      MARIADB_USER: ${DB_USER}
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_RANDOM_ROOT_PASSWORD: "yes"
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD","healthcheck.sh","--connect","--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 10
    networks: [ wp_internal ]

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: [ "redis-server","--maxmemory","128mb","--maxmemory-policy","allkeys-lru","--save","" ]
    networks: [ wp_internal ]

  wordpress:
    image: wordpress:6-php8.3-apache
    restart: unless-stopped
    depends_on:
      db: { condition: service_healthy }
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME}
      WORDPRESS_DB_USER: ${DB_USER}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_REDIS_HOST','redis');
        define('WP_REDIS_PORT',6379);
        define('WP_CACHE', true);
        define('FS_METHOD','direct');
        define('DISALLOW_FILE_EDIT', true);
    volumes:
      - wp_data:/var/www/html
    networks: [ wp_internal, proxy ]
    labels:
      - traefik.enable=true
      - traefik.http.routers.wp.rule=Host(`${WP_HOST}`)
      - traefik.http.routers.wp.entrypoints=websecure
      - traefik.http.routers.wp.tls.certresolver=le
      - traefik.http.routers.wp.middlewares=ratelimit@file
      - traefik.http.services.wp.loadbalancer.server.port=80

volumes:
  db_data:
  wp_data:

networks:
  wp_internal:
  proxy:
    external: true

docker compose up -d
docker compose logs -f wordpress        # einmalige Installation im Container

# Redis-Object-Cache aktivieren (WP-CLI im laufenden Container):
docker compose exec -u www-data wordpress \
  bash -c 'wp plugin install redis-cache --activate && wp redis enable'

Aufrufen: https://blog.seb4u.com/wp-admin → Sprache, Titel, Admin-Konto (Benutzername nicht admin), 2FA-Plugin.

DB-Tuning optional, aber sinnvoll

Statt der command:-Zeilen eine my.cnf mounten – übersichtlicher, wenn mehr Parameter dazukommen:

[mariadb]
transaction-isolation      = READ-COMMITTED
binlog-format              = ROW
character-set-server       = utf8mb4
collation-server           = utf8mb4_unicode_ci
innodb-buffer-pool-size    = 512M      # ~25-40 % vom RAM, den du der DB goennst
innodb-flush-log-at-trx-commit = 2     # etwas schneller, minimal weniger crash-sicher
max-connections            = 60
slow-query-log             = 1
long-query-time            = 1

Mount: - ./db/my.cnf:/etc/mysql/conf.d/z-tuning.cnf:ro im db-Service, command: dann weglassen.

Warum lokale MariaDB

• WordPress ist bei jedem Seitenaufruf sehr gesprächig mit der DB. Über Netzwerk (managed DB, anderer Host) sammelt sich Latenz → spürbar langsamer.
• Eine im Netz erreichbare MySQL ist eine Angriffsfläche. Im internen Docker-Netz mit eigenem User: nicht.
• MariaDB statt Oracle-MySQL: Drop-in, in der Praxis für WordPress etwas fixer, große Verbreitung. Redis als Object-Cache nimmt der DB einen Großteil der Wiederhol-Queries ab – auf einem geteilten Server wichtig.
• Hetzner hat keine managed Datenbank. Externe managed DB = Latenz + Extra-Kosten, für eine kleine Site nicht sinnvoll.

Umzug einer bestehenden Site z. B. von easyname / CloudPanel

# alt: DB + wp-content sichern
wp db export dump.sql          # oder: mysqldump --single-transaction ... > dump.sql
tar czf wp-content.tar.gz wp-content

# neu: einspielen (Stack laeuft schon)
docker compose exec -T db sh -c 'mariadb -u$MARIADB_USER -p$MARIADB_PASSWORD $MARIADB_DATABASE' < dump.sql
docker run --rm -v wordpress_wp_data:/v -v "$PWD":/b alpine \
  sh -c 'cd /v/wp-content && tar xzf /b/wp-content.tar.gz --strip-components=1'

# URLs umschreiben, falls die Domain wechselt
docker compose exec -u www-data wordpress \
  wp search-replace 'https://alt.example' 'https://blog.seb4u.com' --all-tables

Alternativ ohne CLI (Command-Line Interface): Plugin Duplicator oder All-in-One WP Migration – exportiert Site + DB als ein Paket, im neuen WP wieder importieren.

Datenbank: geteilt oder pro Dienst

Zwei brauchbare Muster. Faustregel: bis ~3 Dienste je eigene DB, ab dann eine geteilte Instanz – wegen RAM.

A – eine DB-Instanz pro Dienst Standard

• Jeder Stack bringt sein eigenes db-Container mit (wie WordPress oben).
• Vorteil: vollständig isoliert – eigene Version, eigenes Tuning, eigenes Backup, lässt sich einzeln löschen. Ein „DROP“ im einen trifft den anderen nie.
• Nachteil: jede MariaDB kostet ~130 MB Grund + Buffer Pool. Fünf Dienste = fünfmal Overhead.

B – eine geteilte DB-Instanz, mehrere Datenbanken

services:
  mariadb:
    image: mariadb:11.4
    restart: unless-stopped
    command: [ --innodb-buffer-pool-size=768M, --character-set-server=utf8mb4,
               --collation-server=utf8mb4_unicode_ci, --transaction-isolation=READ-COMMITTED ]
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_root
    volumes:
      - shared_db:/var/lib/mysql
      - ./init:/docker-entrypoint-initdb.d:ro   # .sql beim ersten Start
    networks: [ db_net ]
    secrets: [ db_root ]
volumes:
  shared_db:
networks:
  db_net:
    name: db_net
secrets:
  db_root:
    file: ./db_root.txt

CREATE DATABASE IF NOT EXISTS wp_blog   CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER IF NOT EXISTS 'wp_blog'@'%'   IDENTIFIED BY 'PW_A';
CREATE USER IF NOT EXISTS 'nextcloud'@'%' IDENTIFIED BY 'PW_B';

GRANT ALL PRIVILEGES ON wp_blog.*   TO 'wp_blog'@'%';     # nur die eigene DB
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'%';
FLUSH PRIVILEGES;

• Die App-Stacks bekommen dann kein eigenes db-Container, sondern hängen zusätzlich im externen db_net und setzen WORDPRESS_DB_HOST: mariadb.
• Jede App bekommt eigene DB + eigenen User, der nur auf seine DB GRANT hat – das ist die Isolationsgrenze.
• Vorteil: ein DB-Prozess, ein Buffer Pool, ~300–500 MB gespart bei 5 Apps. Ein Backup-Job dumpt alle DBs.
• Nachteil: gemeinsame Version + gemeinsames Tuning. Ein Neustart trifft alle. Ein durchgesickertes Root-Passwort öffnet alle DBs. Root-Passwort daher als Docker-Secret, nicht als Env.

Postgres vs. MySQL/MariaDB

Manche Dienste wollen Postgres (Vaultwarden optional, Gitea, viele neuere Apps), manche MySQL/MariaDB (WordPress, Nextcloud klassisch). Dann brauchst du beide Engines – nicht mischen in einer Instanz. Praktisch: eine geteilte MariaDB und eine geteilte Postgres, je als eigener Mini-Stack. Vaultwarden läuft aber gut mit seiner eingebauten SQLite – für einen Ein-Personen-Tresor kein DB-Server nötig.

Vaultwarden dazu

Gleiche Mechanik, eigener Stack. Lies zuerst Abschnitt 13 – für einen Passwort-Tresor ist ein eigener Server oft die bessere Wahl.

services:
  vaultwarden:
    image: vaultwarden/server:1.32-alpine
    restart: unless-stopped
    environment:
      DOMAIN: https://vault.seb4u.com
      SIGNUPS_ALLOWED: "false"          # nach dem ersten Konto: aus
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: ${ADMIN_TOKEN}       # Argon2-Hash, siehe unten
      PUSH_ENABLED: "false"
    volumes:
      - vw_data:/data
    networks: [ proxy ]
    labels:
      - traefik.enable=true
      - traefik.http.routers.vw.rule=Host(`vault.seb4u.com`)
      - traefik.http.routers.vw.entrypoints=websecure
      - traefik.http.routers.vw.tls.certresolver=le
      - traefik.http.routers.vw.middlewares=secure-headers@file
      - traefik.http.services.vw.loadbalancer.server.port=80
volumes:
  vw_data:
networks:
  proxy:
    external: true

# Admin-Token als Argon2-Hash erzeugen (nicht im Klartext ablegen):
docker run --rm -it vaultwarden/server /vaultwarden hash
# Ausgabe in .env:  ADMIN_TOKEN='$argon2id$v=19$...'
docker compose up -d

Danach https://vault.seb4u.com im Browser, Konto anlegen, dann SIGNUPS_ALLOWED auf "false" und docker compose up -d. Admin-Panel: /admin. Die offiziellen Bitwarden-Apps zeigen in den Einstellungen auf die Server-URL – Details in der Anleitung Vaultwarden auf Hetzner.

Weitere Dienste nach Muster

Jeder neue Dienst: Verzeichnis anlegen, compose.yaml mit dem Label-Block, docker compose up -d, DNS-Record. Das ist alles.

services:
  app:
    image: <image>
    restart: unless-stopped
    environment: { ... }
    volumes: [ app_data:/data ]
    networks: [ internal, proxy ]      # internal nur wenn es ein DB-/Cache-Backend hat
    labels:
      - traefik.enable=true
      - traefik.http.routers.<dienst>.rule=Host(`<dienst>.seb4u.com`)
      - traefik.http.routers.<dienst>.entrypoints=websecure
      - traefik.http.routers.<dienst>.tls.certresolver=le
      - traefik.http.routers.<dienst>.middlewares=secure-headers@file
      - traefik.http.services.<dienst>.loadbalancer.server.port=<container-port>
volumes: { app_data: }
networks:
  internal: {}
  proxy: { external: true }

Backup pro Dienst

Nicht „der Server“, sondern je Dienst: Volume-Archiv + konsistenter DB-Dump, dann off-site. So lässt sich ein Dienst wiederherstellen, ohne die anderen anzufassen.

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F_%H%M)
DEST="/opt/backups/$STAMP"
mkdir -p "$DEST"

dump_mariadb() {  # $1 = compose-projektname, $2 = service
  docker compose -p "$1" exec -T "$2" sh -c \
    'exec mariadb-dump --single-transaction --routines --triggers \
       -u"$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' | gzip > "$DEST/$1-db.sql.gz"
}
archive_volume() {  # $1 = volume-name
  docker run --rm -v "$1":/v -v "$DEST":/b busybox \
    tar czf "/b/$1.tar.gz" -C /v .
}

# --- WordPress ---
dump_mariadb  wordpress db
archive_volume wordpress_wp_data

# --- Vaultwarden (SQLite -> einfach das Volume, Dienst kurz pausieren fuer Konsistenz) ---
docker compose -p vaultwarden stop
archive_volume vaultwarden_vw_data
docker compose -p vaultwarden start

# --- off-site: Hetzner Storage Box per rsync/ssh ---
rsync -a --delete "$DEST/" "$SB_USER@$SB_HOST:backups/$STAMP/"

# --- lokale Aufbewahrung: 7 Tage ---
find /opt/backups -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +
echo "ok: $STAMP"

chmod +x /opt/stacks/backup/backup.sh
# Storage Box: ssh-key hinterlegen, dann als cron (03:15 taeglich)
( crontab -l 2>/dev/null; echo '15 3 * * * SB_USER=u123 SB_HOST=u123.your-storagebox.de /opt/stacks/backup/backup.sh >> /var/log/backup.log 2>&1' ) | crontab -

Restore-Probe einmal wirklich machen

cd /opt/stacks/wordpress
docker compose down            # Volumes bleiben
docker volume rm wordpress_wp_data wordpress_db_data
docker volume create wordpress_wp_data && docker volume create wordpress_db_data
docker run --rm -v wordpress_wp_data:/v -v /opt/backups/<stamp>:/b busybox \
  tar xzf /b/wordpress_wp_data.tar.gz -C /v
docker compose up -d db && sleep 20
gunzip -c /opt/backups/<stamp>/wordpress-db.sql.gz | \
  docker compose exec -T db sh -c 'mariadb -u$MARIADB_USER -p$MARIADB_PASSWORD $MARIADB_DATABASE'
docker compose up -d

Betrieb: Updates, Logs, Monitoring

Vom Laptop: dienste-stack.ps1 im cloud-host-Ordner

Alle Stacks in einem Rutsch an/aus, per SSH – in der richtigen Reihenfolge (Traefik + geteilte DB zuerst hoch, zuletzt runter):

.\scripts\dienste-stack.ps1 status                    # was laeuft, Container, RAM/CPU, Disk
.\scripts\dienste-stack.ps1 up                        # jeder Stack: docker compose up -d
.\scripts\dienste-stack.ps1 down                      # jeder Stack: docker compose down (Volumes bleiben)
.\scripts\dienste-stack.ps1 stop        # / start  - schneller, ohne Container wegzuwerfen
.\scripts\dienste-stack.ps1 pull                      # pull + up -d fuer alle, dann image prune
.\scripts\dienste-stack.ps1 logs traefik              # Logs eines Stacks folgen
.\scripts\dienste-stack.ps1 up   -Only wordpress,vaultwarden
.\scripts\dienste-stack.ps1 down -Only wordpress

Oben in der Datei: $Server (SSH-Ziel bzw. ~/.ssh/config-Alias), $StacksDir, $UpOrder, $Exclude. Findet die Stacks selbst (/opt/stacks/*/compose.yaml). Server aus? Erst .\scripts\snapshot.ps1 up bzw. .\scripts\cloud.ps1 up.

Updates – pro Stack, kontrolliert

cd /opt/stacks/wordpress
docker compose pull
docker compose up -d
docker image prune -f

• Image-Tags pinnen (mariadb:11.4, nicht latest) – dann bringt pull nur Patch-Updates, keine bösen Überraschungen.
• Watchtower (Auto-Update aller Container) auf einem Multi-Dienst-Server eher nicht – ein kaputtes Upstream-Image legt dann nachts alles lahm. Lieber diun (nur Benachrichtigung „neues Image da“) + von Hand.
• Vor größeren Updates (MariaDB-Major, WordPress-Major): Backup läuft lassen, dann updaten.

Logs & Platz

• Docker-Log-Limit ist in daemon.json gesetzt (10 MB × 3 pro Container). journald zusätzlich begrenzen: journalctl --vacuum-time=14d bzw. SystemMaxUse=500M.
• df -h und docker system df ins Monitoring – ein voller Datenträger nimmt alle Dienste mit.
• docker compose logs -f --tail=100 <service> für Fehlersuche.

Monitoring

• Uptime Kuma als eigener kleiner Stack – prüft jede öffentliche URL (Uniform Resource Locator) von außen, schickt bei Ausfall Telegram/E-Mail. Am besten auf einem anderen Host (sonst meldet es sich nicht, wenn der Server weg ist) – z. B. der kostenlose Tier eines zweiten Anbieters, oder daheim.
• netdata oder beszel für RAM/CPU/Disk-Verlauf pro Container – zeigt dir, welcher Dienst zu groß wird, bevor OOM zuschlägt.
• Hetzner-Verbrauchswarnung: es gibt kein Ausgabenlimit – wenn der Server 24/7 läuft, ist das der teuerste Fall. Snapshot/Restore (Anleitung) gilt auch hier, wenn der Server nur zeitweise gebraucht wird.

Wann doch trennen

Konsolidieren ist der Normalfall. Diese Dinge gehören trotzdem auf einen eigenen Server:

+ Kostenvergleich

Die Ersparnis in Euro ist moderat. Der größere Gewinn: eine Wartungsoberfläche – ein OS (Betriebssystem) patchen, ein Backup-Lauf prüfen, ein Monitoring, ein Firewall-Regelsatz – statt drei- bis fünffach.

+ Podman statt Docker

Die Beispiele nutzen Docker Compose. Mit Podman:

• podman compose (oder podman-compose) versteht dieselben compose.yaml – Netze, Volumes, Labels identisch. Traefik liest die Labels über den Podman-Socket (podman system service).
• Sauberer für den Dauerbetrieb: Quadlet – je Dienst eine .container-Datei in /etc/containers/systemd/, dann sind es echte systemd-Units (systemctl restart wordpress). Ein .network fürs proxy-Netz.
• Rootless ist der Podman-Vorteil für einen geteilten Server – jeder Dienst als eigener unprivilegierter User, Container-Ausbruch trifft nur diesen User. Dafür kann Port 80/443 nicht direkt gebunden werden (net.ipv4.ip_unprivileged_port_start=80 setzen oder Traefik als root/rootful).
• Der container-host-Guide hat den Podman/Docker-Umschalter im Detail.