With DSM 7.2 Synology renamed the Docker package to Container Manager. More than a rebrand: new UI, better Docker Compose support, and a few old bugs gone.
Compose finally first-class
Container Manager now has a dedicated Compose editor where you paste a docker-compose.yml, validate, and apply. For the stacks we self-host for clients — Vaultwarden, Plausible, n8n, NocoDB — it is the difference between "I put it up" and "I put it up calmly".
Networking: the delicate point
Docker networks on DSM are separate from the NAS LAN. If you want a container to reach another machine on the NAS LAN, use network_mode: host or create a dedicated macvlan. Macvlan is cleaner but needs subnet attention.
Persistence: volumes vs bind mounts
On Synology we always recommend bind mounts to a Btrfs path (e.g. /volume1/docker/<service>) over native Docker volumes. Why: Btrfs snapshots protect that data the same way they protect the rest of the NAS. Native volumes live in a less snapshot-friendly zone.
Auto-updates
Container Manager has no built-in auto-update. For critical stacks we use Watchtower on a weekly schedule with webhook notifications. For client production stacks, never silent updates — always reviewed.
Real limits
- No Docker Swarm (third-party hacks exist).
- No Kubernetes on Synology — if you need it, time for a VPS.
- Limited RAM on J/value models: heavy stacks (Postgres + Redis + app) saturate fast. DS923+/DS1522+ (4-8 GB+) work fine.
For 90% of our self-hosting on NAS scenarios, DSM 7.2 + Container Manager is plenty.