Container Manager (Docker) auf der Synology nutzen

Container Manager ist die Synology-eigene Docker-Implementation — auf älteren DSM-Versionen hieß das Paket noch „Docker”, auf DSM 7.2+ ist es Container Manager (basiert auf Docker Engine, identische Befehle). Damit kannst Du eigene Anwendungen als Container auf Deiner Synology laufen lassen.

Klassische Use Cases: Pi-hole (DNS-Filter), Home Assistant (Smart-Home-Zentrale), Vaultwarden (Bitwarden-Server), Plex/Jellyfin (Media-Server), Nextcloud (wenn Du nicht unsere managed Variante willst), Wireguard (VPN), Adguard Home — die Liste ist lang.

Voraussetzung: Plus-Modelle (DS225+, DS925+, DS1625+) unterstützen Container Manager. Die einfacheren Value-Modelle nicht — auf denen läuft Docker nicht.

Container Manager installieren

1. Paket-Zentrum → „Container Manager” suchen → Installieren.
2. Nach Installation in die App wechseln.

Du siehst vier Tabs:

• Übersicht: laufende Container im Schnellblick
• Container: alle Container, mit Aktionen (Start, Stop, Logs)
• Image: lokal vorhandene Docker-Images
• Registry: Docker Hub und andere Registries durchsuchen

Plus eine fünfte Sektion Projekt für Docker Compose Stacks (siehe unten).

Erster Container — Beispiel Pi-hole

Pi-hole als DNS-Filter für werbe- und tracker-blockendes DNS in Deinem Heimnetz. Klassisches Beispiel.

Über Docker Compose (empfohlene Variante):

1. In Container Manager: Projekt → Erstellen.
2. Projektname: pihole.
3. Pfad: /docker/pihole (Synology legt das automatisch an).
4. Quelle: YAML erstellen.

Inhalt der docker-compose.yml:

version: "3"
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
    environment:
      TZ: "Europe/Berlin"
      WEBPASSWORD: "DEIN-PASSWORT"
    volumes:
      - "/volume1/docker/pihole/etc-pihole:/etc/pihole"
      - "/volume1/docker/pihole/etc-dnsmasq:/etc/dnsmasq.d"
    restart: unless-stopped

Speichern, Übernehmen. Container Manager pullt das Pi-hole-Image, startet den Container.

Pi-hole-Web-Interface erreichst Du dann auf Port 8080 — http://<deine-synology-ip>:8080/admin.

Über die GUI ohne Compose

Wenn Du keinen YAML-File schreiben willst:

1. Image → Hinzufügen → Aus URL → pihole/pihole:latest.
2. Nach Download: Image markieren → Ausführen.
3. Im Wizard: Container-Name, Port-Mapping, Volume-Mounts, Environment-Variablen einzeln eintragen.

Ist klickintensiver, geht aber. Für komplexere Stacks ist Compose deutlich übersichtlicher.

Stolperfallen, die wir oft sehen

Port-Konflikte: DSM nutzt einige Standardports (5000, 5001, 80, 443). Wenn Dein Container die gleichen Ports will: konflikt. Lösung: Container auf andere Ports mappen (z.B. 8080:80 statt 80:80).

Volume-Pfade falsch: Synology mountet Volumes anders als Linux-Standard. Pfade sind /volume1/..., nicht /mnt/.... In Compose-Files genau drauf achten.

Network-Modus „host”: einige Container brauchen Host-Networking (etwa Pi-hole ohne Custom-DNS-Bind). Das geht auf Synology, ist aber Trickreich. In Container Manager unter Erweiterte Einstellungen → Netzwerk → Bridge oder Host.

RAM-Verbrauch im Auge behalten: Container essen RAM. Eine Synology mit 4 GB RAM verkraftet 3–5 leichte Container, mehr eher nicht. Im Resource Monitor im DSM den RAM-Verbrauch beobachten.

Updates nicht automatisch: Container Manager updated Images nicht von selbst. Für Auto-Update einen Watchtower-Container daneben laufen lassen, oder manuell alle paar Wochen Image neu pullen.

Best-Practice-Setup für eigene Container

Volume-Struktur für Container-Daten:

/volume1/docker/
├── pihole/
│   ├── etc-pihole/
│   └── etc-dnsmasq/
├── homeassistant/
│   └── config/
└── vaultwarden/
    └── data/

Pro Container ein Unterordner — alles, was persistiert, in den Mount-Pfad. Beim Backup einfach /volume1/docker/ mit in Hyper Backup nehmen.

Reverse Proxy für externe Erreichbarkeit: in DSM unter Anmeldeportal → Reverse Proxy kannst Du Subdomains (etwa vault.deinname.de) auf Container-Ports routen. Mit Let’s-Encrypt-Zertifikat funktioniert dann HTTPS automatisch.

Backup-Schicht für laufende Datenbanken: Postgres- oder MySQL-Container brauchen vor dem Backup einen Dump, sonst sind die Backups inkonsistent. In Compose oder in einem Cron-Job regelmäßig Dumps in den Mount-Folder schreiben.

Docker Hub — Vorsicht beim Image-Pull

Auf Docker Hub findest Du Tausende Images. Aus unserer Erfahrung:

• Bevorzuge offizielle Images (Tag „official”, oder von der Projekt-eigenen Organisation).
• Vermeide unbekannte Pakete: ein Image von „supercoolusername” ohne Repo-Link kann Malware enthalten.
• Pin auf konkrete Versionen: :latest Tag ist bequem, aber kann sich hinter Deinem Rücken verändern. :1.4.2 ist sicherer.

Vertrauenswürdige Quellen für Privatkunden:

• LinuxServer.io (lscr.io) — viele gut gewartete Images
• Home Assistant Community (HACS)
• Offizielle Projekt-Repos

Container in der DSM-Übersicht

Container Manager zeigt:

• Status: laufend / gestoppt / Fehler
• CPU- und RAM-Nutzung live
• Logs: Container-Output, scrollbar — wichtig fürs Debugging
• Konsole: Shell im Container öffnen (für Bash-Debugging)
• Aktionen: Start, Stop, Neustart, Löschen

Häufige Fragen

Was ist der Unterschied zu Docker auf einem vServer? Funktional identisch. Container Manager ist Synologys GUI auf Docker Engine, alle Standard-Docker-Features sind drin. Vorteil Synology: einfache GUI, integrierte Volume- und Backup-Verwaltung. Vorteil vServer: mehr CPU/RAM für anspruchsvolle Container.

Funktioniert Docker Compose v3? Ja. Container Manager auf DSM 7.2+ unterstützt Compose v3 — die meisten gängigen Compose-Files laufen out-of-the-box.

Kann ich GitHub Actions Self-hosted Runner als Container? Ja, das machen einige Kunden. Beachte: der Runner braucht eine eingehende Verbindung zu GitHub (Outbound HTTPS reicht), keine offenen Ports nach außen.

Kann ich Container von außen erreichbar machen? Über Reverse Proxy in DSM (siehe oben). Direkter Port-Mapping nach außen geht auch — dann muss die Firewall-Regel passen, und die Container-Ports sind direkt im Internet erreichbar.

Was ist mit Apple Silicon (ARM) — laufen alle Container? Synology Plus-Modelle nutzen x86_64-Architektur. Container, die nur ARM-Images haben, laufen nicht. Bei Multi-Arch-Images (die meisten populären) ist das egal — Docker pullt automatisch x86_64.

Wie viele Container kann ich parallel laufen lassen? Hängt von RAM und CPU ab. Eine DS225+ mit 2 GB RAM: 3–5 leichte Container. Eine DS925+ mit 4 GB RAM: 8–12. Mit RAM-Upgrade auf 16 oder 32 GB deutlich mehr.

Was, wenn ein Container Daten korrumpiert? Hoffentlich hast Du Hyper Backup laufen — dann kannst Du den Daten-Mount-Folder zurückspielen. Snapshot Replication auf dem Volume hilft auch (siehe Snapshot Replication).

Weiter geht’s

• Snapshot Replication für Versions-Schutz
• Hyper Backup auf storageDRIVE
• Let’s-Encrypt-Zertifikat einrichten