Seit DSM 7.2 bringt Synology mit dem Container Manager nativen Docker-Compose-Support direkt in die Weboberflaeche – kein SSH, kein Terminal, kein Drittanbieter-Tool notwendig. Das alte Docker-Paket mit dem Wal-Logo wird vollständig ersetzt. Wer auf seinem NAS Selbsthosting-Apps wie Passwortmanager, Medienserver oder Home-Automation betreiben will, kommt am Container Manager nicht vorbei. Diese Grundanleitung ist der Referenzartikel für alle unsere Docker-Anleitungen auf s-edv.com: Einmal sauber erklärt, immer verlinkt.

Voraussetzungen

Synology NAS mit Intel- oder AMD-Prozessor (x86_64) oder einem unterstützten ARM64-Modell (z.B. DS223, DS223j, DS423 und neuere)
Ältere ARM-Modelle (DS118, DS218j, J-Serie vor 2022) werden nicht unterstützt – Prüfung: im Paket-Zentrum nach „Docker“ suchen; kein Ergebnis = nicht kompatibel
DSM 7.2 oder höher (DSM 7.2.1 oder DSM 7.3 empfohlen)
Mindestens 1 GB RAM auf dem NAS (2 GB empfohlen bei mehreren Containern)
Aktive Internetverbindung des NAS für Image-Downloads
Admin-Zugang zur DSM-Weboberflaeche (Port 5000 oder 5001)

Schritt 1: Container Manager installieren

Öffne in DSM das Paket-Zentrum und suche nach Docker. Das neue Container-Manager-Paket erscheint mit einem anderen Icon als das alte Wal-Logo. Klicke auf Installieren – der Vorgang dauert je nach Internetgeschwindigkeit ein bis drei Minuten. Nach der Installation findest du den Container Manager im Hauptmenü von DSM.

Beachte: Der Container Manager nutzt Docker Engine 24.0.x. Diese Version ist seit Juni 2024 offiziell End-of-Life, läuft auf Synology NAS-Geräten aber stabil. Sicherheits-Patching-Garantien gibt es für diese Version nicht mehr – für den isolierten NAS-Betrieb im Heimnetz oder kleinen Unternehmen ist das akzeptabel, sollte dir aber bewusst sein.

Verifizieren: Öffne den Container Manager. Die Übersicht zeigt die Abschnitte Übersicht, Container, Projekt, Image und Registrierung in der linken Navigation. Wenn du diese Struktur siehst, ist die Installation erfolgreich abgeschlossen.

Schritt 2: Shared Folder und Projektverzeichnis anlegen

Der Container Manager erstellt Host-Verzeichnisse nicht automatisch – du musst sie vorher anlegen, sonst schlägt der Container-Start mit no such file or directory fehl.

Öffne die File Station in DSM. Falls noch nicht vorhanden, lege einmalig einen Shared Folder namens docker an: File Station > Freigegebener Ordner > Erstellen. Dieser Ordner dient als zentrale Ablage für alle Projekte.

Lege danach für jede App einen eigenen Unterordner an, zum Beispiel:

/volume1/docker/beispiel-app/
/volume1/docker/beispiel-app/config/
/volume1/docker/beispiel-app/data/

Die genauen Unterordner hängen von der jeweiligen App ab und sind in der entsprechenden App-Anleitung dokumentiert. Weitere Hintergründe zu Berechtigungen und PUID/PGID findest du in der Grundanleitung Docker-Ordner und Berechtigungen auf dem Synology NAS.

Pfad-Muster	Korrekt?	Hinweis
/volume1/docker/appname/config:/config	Ja	Absoluter Pfad mit Volume-Nummer
./config:/config	Nein	Relative Pfade funktionieren nicht
/docker/appname/config:/config	Nein	Volume-Nummer fehlt

Verifizieren: Navigiere in der File Station zu /volume1/docker/. Der Unterordner deiner App und alle erforderlichen Unterverzeichnisse müssen sichtbar sein, bevor du mit Schritt 3 weitermachst.

Schritt 3: Projekt erstellen und compose.yaml einfügen

Wechsle in den Container Manager und klicke auf Projekt > Erstellen. Fülle das Formular aus:

Projektname: Nur Kleinbuchstaben und Bindestriche, keine Leerzeichen (z.B. beispiel-app statt Beispiel App)
Pfad: Wähle das vorher angelegte Verzeichnis, z.B. /volume1/docker/beispiel-app
compose.yaml: Füge den Inhalt direkt in den Editor ein oder lade eine vorbereitete Datei hoch

Der bevorzugte Dateiname laut Docker-Standard ist compose.yaml (nicht mehr docker-compose.yml). Der Container Manager akzeptiert beide Namen für Rückwärtskompatibilität.

Eine typische Basis-compose.yaml für Synology-Projekte sieht so aus:

services:
  beispiel-app:
    image: registry/imagename:latest
    container_name: beispiel-app
    restart: unless-stopped
    environment:
      - PUID=1026
      - PGID=100
      - TZ=Europe/Berlin
    volumes:
      - /volume1/docker/beispiel-app/config:/config
      - /volume1/docker/beispiel-app/data:/data
    ports:
      - "8080:8080"

Wichtige Punkte zu den Werten:

PUID/PGID: Die korrekten Werte für deinen Admin-User ermittelst du per SSH mit id admin (typisch: PUID=1026, PGID=100). Details dazu in der Grundanleitung Docker-Ordner und Berechtigungen.
restart: unless-stopped: Diese Policy sorgt dafür, dass der Container nach einem NAS-Neustart automatisch wieder hochkommt. Manuell gestoppte Container bleiben gestoppt.
Ports: Das Format ist "NAS-Port:Container-Port". Den freigegebenen NAS-Port musst du anschließend auch in der DSM-Firewall erlauben.

Variable	Beispielwert	Bedeutung
PUID	1026	User-ID des Synology-Admin (per `id admin` ermitteln)
PGID	100	Gruppen-ID „users“
TZ	Europe/Berlin	Zeitzone des Containers
restart	unless-stopped	Autostart nach Reboot, nicht nach manuellem Stopp

Verifizieren: Nachdem du alle Felder ausgefüllt hast, zeigt der Container Manager eine Zusammenfassung. Prüfe, ob Projektname, Pfad und der Inhalt der compose.yaml korrekt dargestellt werden, bevor du auf Weiter klickst.

Schritt 4: Projekt bauen und starten

Im letzten Schritt des Assistenten aktiviere die Option „Projekt nach Erstellung starten“ und bestätige. Ein Terminal-Fenster öffnet sich und zeigt den Build-Prozess in Echtzeit – Docker lädt das Image herunter und startet den Container.

Warte, bis der Build abgeschlossen ist. Das Ergebnis erkennst du am Exit-Code am Ende der Ausgabe:

...
Container started
Exit Code: 0

Ein Exit Code 0 bedeutet: alles erfolgreich. Jeder andere Code zeigt einen Fehler an – in diesem Fall scrolle im Terminal nach oben, um die genaue Fehlermeldung zu finden.

Verifizieren: Wechsle in den Bereich Container. Dein Container sollte mit dem Status „Wird ausgeführt“ (grüner Punkt) in der Liste erscheinen. Öffne außerdem den Browser und rufe http://<NAS-IP>:<Host-Port> auf – die Web-Oberfläche der App sollte erreichbar sein. Falls nicht, prüfe zuerst die Firewall (Schritt 7).

Schritt 5: Container-Logs lesen

Logs sind dein wichtigstes Diagnosewerkzeug. Im Container Manager gibt es zwei Wege:

Container-Logs: Navigiere zu Container, wähle den betreffenden Container aus und klicke auf den Tab Log. Hier siehst du die Echtzeit-Ausgabe des Prozesses im Container.
Projekt-Logs: Navigiere zu Projekt, wähle dein Projekt aus und öffne Details > Log. Dieser View zeigt die kombinierten Logs aller Container des Projekts.

Typische Hinweise auf Probleme in den Logs: Permission denied deutet auf falsche PUID/PGID oder fehlende Verzeichnisrechte hin; no such file or directory zeigt, dass ein Volume-Pfad nicht existiert.

Verifizieren: Öffne den Log-Tab des laufenden Containers. Du siehst fortlaufende Ausgaben ohne rote Fehlermeldungen. Wenn die App einen Startvorgang abschließt (z.B. Server started on port 8080), ist der Container betriebsbereit.

Schritt 6: Projekt ändern – compose.yaml bearbeiten und neu bauen

Wenn du die compose.yaml nachträglich anpassen willst (z.B. eine Umgebungsvariable ergänzen, einen Port ändern oder ein Volume hinzufügen), reicht ein einfacher Neustart des Projekts nicht aus. Änderungen werden erst nach einem vollständigen Neu-Build wirksam.

Vorgehensweise:

Klicke im Bereich Projekt mit der rechten Maustaste auf dein Projekt und wähle Stoppen
Rechtsklick erneut > Bearbeiten – der compose.yaml-Editor öffnet sich
Nimm deine Änderungen vor und bestätige
Rechtsklick > Erstellen (Build) – der Container wird mit der aktualisierten Konfiguration neu gebaut

Verifizieren: Prüfe nach dem Build-Vorgang erneut den Exit Code (muss 0 sein) und kontrolliere im Log-Tab, ob die Änderung wie erwartet wirksam ist – z.B. ein neuer Port wird jetzt genutzt oder eine neue Umgebungsvariable erscheint im Startlog.

Schritt 7: Firewall-Regel für den Container-Port setzen

Wenn dein Container nach dem Start nicht erreichbar ist, obwohl er läuft, blockiert meist die DSM-Firewall den Host-Port. Navigiere zu Systemsteuerung > Sicherheit > Firewall und füge eine Regel hinzu, die den entsprechenden NAS-Port (z.B. 8080) für die gewünschten Quell-IPs freigibt.

Alle Details dazu – inklusive Interface-Auswahl und Regelreihenfolge – erklärt die Grundanleitung DSM-Firewall auf dem Synology NAS: Ports für Docker-Container freigeben.

Verifizieren: Rufe http://<NAS-IP>:<Host-Port> von einem anderen Gerät im Netzwerk auf. Die Web-Oberfläche der App muss jetzt laden.

Schritt 8: Images aktualisieren und Container neu bauen

Image-Update und Container-Neubau sind zwei separate, zwingend notwendige Schritte – ein häufiger Fehler ist, nur das Image zu aktualisieren, ohne den Container danach neu zu bauen. Der laufende Container nutzt dann weiterhin das alte Image.

Vorgehensweise für ein Update:

Wechsle in den Bereich Image. Nach mindestens 12 Stunden Laufzeit erscheint neben Images mit dem :latest-Tag der Hinweis „Update verfügbar“
Klicke auf Update – Docker lädt das neue Image herunter
Wechsle zu Projekt, Rechtsklick auf das Projekt > Stoppen
Rechtsklick > Erstellen (Build) – der Container wird mit dem neuen Image neu gestartet

Wichtige Einschränkungen der Update-Erkennung:

Der Container Manager meldet Updates nur für :latest-Tags von Docker Hub
Spezifische Versions-Tags (z.B. :3.2.1) und Images von der GitHub Container Registry (ghcr.io) erhalten keine automatische Update-Benachrichtigung
Für lückenlose Update-Überwachung aller Image-Tags empfiehlt sich DIUN (Docker Image Update Notifier) als eigener Container im Container Manager

Sonderfall Datenbank-Images: Bei PostgreSQL, MariaDB oder MySQL kann ein Major-Version-Upgrade (z.B. von Version 15 auf 16) zu Datenbankkorruption führen. Lege vor jedem Update zwingend ein Backup an und prüfe die Migrations-Hinweise des jeweiligen Datenbankprojekts.

Verifizieren: Wechsle nach dem Rebuild in den Bereich Image. Neben dem aktualisierten Image sollte kein „Update verfügbar“-Hinweis mehr stehen. Prüfe im Container-Log, ob die neue Version gestartet ist – viele Apps geben beim Start ihre Versionsnummer aus.

Troubleshooting / Typische Fehler

„no such file or directory“ beim Container-Start: Ein Volume-Pfad in der compose.yaml existiert nicht. Lege alle Host-Verzeichnisse vorher in der File Station an. Prüfe außerdem, ob der Pfad mit /volume1/ (oder /volume2/ usw.) beginnt – relative Pfade wie ./config funktionieren nicht.
Container läuft, App ist nicht erreichbar: Die DSM-Firewall blockiert den Host-Port. Navigiere zu Systemsteuerung > Sicherheit > Firewall und lege eine Freigabe-Regel für den Port an.
„Permission denied“ in den Logs: PUID oder PGID stimmen nicht mit dem Besitzer des Host-Verzeichnisses überein. Ermittle die korrekten IDs per SSH mit id admin und passe die Umgebungsvariablen in der compose.yaml an.
Image-Update zeigt keine Wirkung: Du hast das Image aktualisiert, aber den Container nicht neu gebaut. Stoppe das Projekt und wähle anschließend Erstellen (Build) – nicht nur Starten.
Kein Update-Hinweis für mein Image: Der Container Manager meldet Updates nur für :latest-Tags von Docker Hub. Für andere Tags oder ghcr.io-Images benötigst du DIUN oder einen manuellen Pull.
Container startet nach NAS-Neustart nicht: Die restart-Policy fehlt oder ist auf no gesetzt. Ergänze restart: unless-stopped in der compose.yaml, stoppe das Projekt und baue es neu.
Projektname verursacht Probleme: Projektnamen mit Großbuchstaben, Leerzeichen oder Sonderzeichen können zu Fehlern führen. Verwende ausschließlich Kleinbuchstaben und Bindestriche (z.B. mein-projekt).
Container Manager lässt sich im Paket-Zentrum nicht installieren: Dein NAS-Modell wird nicht unterstützt. Ältere ARM-Modelle (DS118, DS218j) sind nicht kompatibel. Eine Prüfung ist nicht möglich, wenn im Paket-Zentrum kein Docker-Paket erscheint.

Häufige Fragen

Muss ich SSH nutzen, um Docker Compose auf dem Synology NAS zu verwenden?

Nein. Seit DSM 7.2 kannst du die gesamte compose.yaml direkt im Browser über Container Manager > Projekt > Erstellen eingeben oder hochladen. SSH ist für den normalen Betrieb nicht erforderlich. Nur für spezielle Aufgaben wie das Ermitteln von PUID/PGID oder das Debuggen von Berechtigungsproblemen ist ein SSH-Zugang hilfreich – wie du ihn einrichtest, zeigt die Grundanleitung SSH auf dem Synology NAS aktivieren und verbinden.

Wo lege ich den Projektordner am besten an?

Die empfohlene Struktur ist /volume1/docker/<appname> – ein zentraler docker-Shared-Folder auf Volume 1 mit einem Unterordner pro Projekt. Der Shared Folder wird einmalig in der File Station angelegt. Verwende für Appnamen ausschließlich Kleinbuchstaben und Bindestriche.

Warum sehe ich kein Update für mein Image, obwohl eine neue Version erschienen ist?

Der Container Manager prüft Updates nur für Images mit dem Tag :latest und ausschließlich von Docker Hub. Für andere Tags (z.B. :v2.5.0) oder Images von ghcr.io erscheint kein Update-Hinweis. Die Lösung ist DIUN (Docker Image Update Notifier) als eigener Container – der Vergleichsartikel Docker-Container automatisch aktualisieren: Diun, WUD und Renovate im Vergleich erklärt die Optionen.

Was passiert mit meinen Containern nach einem NAS-Neustart?

Alle Container, die beim Herunterfahren liefen und die Policy restart: unless-stopped gesetzt haben, werden nach dem Neustart automatisch wieder gestartet. Manuell gestoppte Container bleiben gestoppt. Container ohne Restart-Policy oder mit restart: no müssen nach einem Neustart manuell gestartet werden.

Was ist der Unterschied zwischen Container Manager, Portainer und Dockge?

Der Container Manager ist das in DSM eingebaute Tool – kein Extra-Container, kein zusätzlicher Aufwand, ideal für den Einstieg und für alle, die direkt in der DSM-Oberfläche bleiben wollen. Portainer läuft als eigener Container und bietet erheblich mehr Funktionen (Multi-Host-Management, RBAC, Template-Bibliothek), ist dafür aber komplexer einzurichten – die Anleitung dazu: Portainer auf Synology NAS installieren. Dockge ist ein schlankes, modernes Stack-orientiertes Tool speziell für Docker Compose mit übersichtlicherem Interface als Portainer, ebenfalls als Container betrieben – Setup: Dockge auf dem Synology NAS installieren.

Kann ich eine compose.yaml von einem Linux-Server auf dem Synology NAS verwenden?

Ja, mit einer wichtigen Anpassung: Alle Volume-Pfade müssen auf /volume1/... umgeschrieben werden. Relative Pfade wie ./data funktionieren auf Synology nicht. Bei ARM-basierten NAS-Modellen prüfe außerdem, ob das Docker-Image eine linux/arm64-Variante anbietet.

Fazit

Der Container Manager macht Docker Compose auf dem Synology NAS zugänglich, ohne dass du die Kommandozeile kennen musst. Die Kernprinzipien bleiben einfach: Ordner vorher anlegen, absolute Pfade mit Volume-Nummer verwenden, restart: unless-stopped setzen und beim Update beide Schritte ausführen – Image pullen und Container neu bauen. Wer diese Grundlagen verinnerlicht hat, kann jede unserer App-Anleitungen auf s-edv.com direkt umsetzen, ohne bei den Basis-Schritten zu stolpern.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: Synology Knowledge Center: Container Manager – Project | Docker Compose Services Reference (Restart, Ports, Volumes) | Docker Compose Application Model