If you went looking for Docker on your Synology NAS and couldn’t find it, nothing was removed. Synology renamed the package to Container Manager in DSM 7.2, and that rename is responsible for most of the confusion around this topic. Container Manager is Docker: it runs the same containers, it uses the same images, and it reads the same documentation you would use on any other machine.
It’s also better than the package it replaced, because it added a Project tab that lets you run Docker Compose from the interface instead of over SSH. That one addition changes how I’d tell anyone to use Docker on a Synology, and it’s where most of this guide lives.
This walks through Container Manager the way I’d actually set it up on current DSM: what each tab is for, how to create a container from a Docker Compose file, the volume paths that trip everyone up, how to handle ports and networks, and how to update a container without losing the ability to roll back.
Container Manager vs. Docker: What Actually Changed
For all intents and purposes, Container Manager is the same thing Docker was on DSM 7.1 and earlier. Two things actually changed, and neither one affects the containers you run.
- The interface was rebuilt, and the settings moved. Everything you had before is still there, just in different places, which is why older tutorials feel wrong even when the steps are right.
- The Docker engine was updated, from the 20.10 era to 24.x, and Docker Compose came along with it as a built-in feature rather than something you installed yourself over SSH.
That is the whole story, and it means that a tutorial written for “Docker on a Synology NAS” still applies, and a Docker Hub page that hands you a docker run command or a Compose file still works. You are translating between interfaces rather than between products, and the rest of this guide is mostly about doing that translation well.
One practical note before anything else: Container Manager is in Package Center, and if you’re coming from an older DSM it replaces the Docker package rather than sitting beside it, so your existing containers survive the transition without any work on your part.
The Container Manager Tabs, and What Each One Is For
When you launch Container Manager you land on the Overview tab, and there are six more down the left side. Here’s what each one does, because knowing that up front saves a lot of clicking around.
- Overview shows running services and resource usage. It’s empty until you’ve created something, and honestly you can mostly ignore it.
- Project is Docker Compose. This is the tab I think most people should live in, and it’s the one that didn’t exist before DSM 7.2.
- Container lists everything running and lets you build containers through the GUI, the way you always did.
- Image holds the images you’ve downloaded, flags when an update is available, and links out to each image’s Docker Hub page.
- Registry is where you search Docker Hub and pull images down.
- Network manages the Docker networks, including any macvlan interfaces you create over SSH.
- Log is the event log for the package itself.
Start With the Documentation, Not the GUI
This is the part I’d push hardest, because it’s what separates people who can run any container from people who can only follow one tutorial at a time.
Every container you’ll ever run has documentation on Docker Hub, and that documentation tells you the three things you need: which volumes to map, which ports it wants, and which environment variables it accepts. Search for the image in the Registry tab, download it, then open the Image tab, select the image, choose Details, and click the Docker Hub link.
Every project writes its documentation differently, so you’ll have to hunt a bit. What you’re looking for is a Docker Compose example or a docker run command, because either one contains the full configuration in a form you can copy. Most well-maintained images publish a Compose file you can use almost as-is, and that file is the fastest possible starting point.
If you learn to read that file, every container becomes the same job with different values. If you don’t, every container is a new mystery.
How to Use Docker Compose on a Synology NAS (the Project Tab)
You could always use Docker Compose on a Synology NAS, but you had to do it over SSH, which put it out of reach for a lot of people. The Project tab moved it into the interface, and that’s the single biggest improvement Container Manager brought.
Speaking transparently, I don’t think there’s much reason to create a container through the Synology GUI anymore. A Compose file holds the entire configuration in one place, which means the container is portable in a way a GUI-built container never is. If you move to a Proxmox server or a mini PC later, you copy the folder, run one command, and you are back up, where without Compose you would be rebuilding every container by hand from memory.
Creating a Project
1. Before you touch Container Manager, open File Station and create a folder for this container inside the docker shared folder. Installing Container Manager creates that docker folder for you, and it’s where everything should live. There’s still no separate “Container Manager” folder in DSM, so keep using docker.
2. In the Project tab, select Create, give the project a name, and set the path to the folder you just made.
3. Choose Create docker-compose.yml and paste in the Compose file from the documentation, or upload an existing docker-compose.yml. Each container gets its own project folder and its own Compose file, so don’t dump everything into the root of the docker folder.
4. Edit the file before you create it. This is your chance to set passwords, change the time zone, adjust ports, and most importantly fix the volume paths, which is the next section because it’s where nearly everyone gets stuck.
Fixing the Volume Paths (This Is What Breaks)
Documentation almost always uses relative paths like ./etc-pihole:/etc/pihole. Those don’t work on a Synology, and this one detail causes more failed containers than anything else in Container Manager.
Read a volume line as local folder : container folder. Everything left of the colon is a path on your NAS, everything right of it belongs to the container and should be left alone. Your job is to replace the left side with a real, absolute path that includes the volume number.
That path starts at /volume1/docker/ for most people, and if you’re not sure which volume your docker folder actually lives on, open Control Panel and check Shared Folders, because it will be volume2 or volume3 if you installed Container Manager somewhere else.
So a Jellyfin Compose file ends up looking like this, with every local path rewritten:
services:
jellyfin:
image: jellyfin/jellyfin
container_name: jellyfin
network_mode: 'host'
volumes:
- /volume1/docker/jellyfin/config:/config
- /volume1/docker/jellyfin/cache:/cache
- /volume1/docker/jellyfin/media:/media
restart: 'unless-stopped'Two things that will save you a support search. Container Manager will not create those subfolders for you, so every folder in every local path has to exist in File Station before you start the project, or it fails. And the old version: line at the top of older Compose examples is obsolete now, so you can delete it if the documentation you copied still includes one.
These mounted folders hold all of your personal data for every container. They are the folders you need to back up. Everything else is configuration that can be rebuilt.
Once the paths are right, create the project and Container Manager builds it. If it fails, the error is almost always a missing folder or a port conflict, both of which are covered below.
Creating a Container Without Compose
If you’d rather use the GUI, the Container tab still does everything it always did. The settings are the same ones in the Compose file, just spread across a wizard, so if you understand the file you understand the wizard.
Volume Settings
The Volume section is the GUI version of the volume lines above. You pick a folder on the NAS and type the container path it maps to, and there’s a read-write or read-only toggle on each one. Read-write is right for almost everything, though a few containers want read-only mounts.
You can’t mount arbitrary folders here, because the container only ever writes to the paths its image expects, and those are exactly what the documentation lists, which is the second place that Docker Hub page earns its keep.
Ports
Ports map the same way volumes do: a local port on your NAS points at a container port. The conflict you will hit is port 80, because DSM already uses it for its own reverse proxy. Map the container’s port 80 to something free like 8080 and reach it at your NAS address plus that port.
http://[SYNOLOGY_NAS_IP]:8080
One thing that confuses people: if you set the container to use the host network, the port settings disappear entirely. That’s expected, because host networking means the container shares the NAS’s network stack and there’s nothing left to map.
Environment Variables
Environment variables are how you configure most containers, and there’s no standard set across images. Some share names, plenty don’t, so the documentation decides this one too. The container ships with defaults you can change, remove, or add to before you create it.
While you’re in this part of the wizard, leave execute container using high privilege unchecked unless a container genuinely requires it. That setting runs the container as root, and a handful of containers do need it, but it shouldn’t be your default.
Networks, and When You Actually Need macvlan
Most containers run fine on bridge or host networking and you never think about this again. The exception is a container that needs the real port numbers rather than remapped ones, and Pi-hole is the usual case because it wants port 80 for its admin interface and DSM already has it.
You have two ways out of that, and the simple one is to change the local port, which works for most things and costs you nothing but an odd-looking URL. The other is to create a macvlan network interface, which gives the container its own IP address on your network and its own complete set of ports, so there is nothing left to conflict with.
A few things are worth knowing before you go down that road. A macvlan interface can only be assigned to one container, and it’s created over a specific physical network port, so if your NAS has two NICs you could create one on each. By default the NAS itself can’t talk to a container on a macvlan interface, which is why you keep a bridge network attached as well and use the bridge address for any NAS-to-container communication. And if you’re running bonded interfaces, expect to experiment.
Creating a macvlan Network Interface
1. SSH into your Synology NAS. If SSH isn’t enabled, turn it on in Control Panel under Terminal & SNMP, and allow port 22 if you’re running Synology’s firewall.
2. Find the interface name that holds your NAS’s IP address. Run the command below and note it down, since it’s usually eth0.
ifconfig
3. Create the network, substituting your own subnet, gateway, interface name, and a free IP address that nothing else on your network uses. ph_network is just the name, so call it whatever you like.
sudo docker network create -d macvlan -o parent=eth0 --subnet=192.168.1.0/24 --gateway=192.168.1.1 --ip-range=192.168.1.198/32 ph_network4. The network now shows up in the Network tab and in the network list when you create a container, and you’ll reach that container at the IP address you picked. You can close the SSH session and disable SSH again if you don’t need it.
To attach more than one network to a container, do it from the Network tab rather than the container settings. Select Manage under the network name, pick the container, and it’s added.
How to Update a Docker Container on a Synology NAS
It helps to understand what an update actually is here, because Docker containers aren’t really updated so much as replaced. You pull a newer image and build a new container from it, which is why the safest update procedure is the one that keeps the old container sitting there until you’re sure.
Container Manager flags updates for you in the Image tab, and there’s a one-click Update button there that works fine. The method below takes a couple of extra minutes and gives you a rollback, which I started doing after a Pi-hole update left me unable to reach the admin portal and I had to rebuild the container on an older version.
Back up your mounted folders before updating any container.
1. Open the Registry, find the container’s image, and download the latest version.
2. Stop the existing container, edit it, and rename it. I add -backup to the end so it’s obvious what it is.
3. With the old container still stopped, choose Settings then Duplicate settings, and give the copy the original name. It carries over every volume, port, and environment variable, but builds on the new image.
4. Start it and use it for a few days. If everything works, delete the backup container. If it doesn’t, delete the new one, rename the backup to its original name, and you’re exactly where you started.
Updating a Docker Compose Project
Compose projects update differently, and more easily. You can do it from the Project tab, or over SSH with two commands. Navigate to the folder holding that project’s docker-compose.yml first, because Compose always runs against the file in the current directory.
sudo docker compose pull sudo docker compose up -d
The first command pulls the newest image, the second rebuilds the container from it. Note that it’s docker compose with a space now rather than the old hyphenated docker-compose, since Compose ships as part of Docker itself in current Container Manager. There’s nothing to install separately anymore, which is a nice change from the days of updating the Compose binary by hand over SSH.
Rolling back a Compose project is genuinely easy, and it’s another argument for using them. Open the file, pin the image to an older tag, and bring it up again. That’s a two-minute fix, where rebuilding a GUI container means re-entering every volume and variable by hand.
Should You Update at All?
Not always, and I’d rather say that plainly than pretend every update is free. If a container is exposed to the internet, or the release fixes a security flaw, update it, and that part isn’t a judgment call.
For something running locally that already works, a media server being the obvious example, the trade is different. At best you get a few new features and slightly better performance. At worst you introduce problems you didn’t have. Update your containers periodically rather than reflexively, and keep the rollback path open when you do.
Security note: this changes constantly and nothing here is a guarantee. Don’t port forward containers to the internet directly, use a reverse proxy or a VPN if you need outside access, and keep DSM itself current.
How to Access a Container From the Command Line
Sometimes you need to get inside a running container, whether to edit a config file or just to see how it’s laid out, and on a Synology that has to happen over SSH rather than through Container Manager.
1. Start the container first. You can’t attach to a container that isn’t running.
2. SSH into the NAS, enabling it in Control Panel under Terminal & SNMP if you haven’t.
3. List the running containers and copy the Container ID of the one you want.
sudo docker container ls
4. Attach to it, substituting the ID you copied. Some minimal images don’t include bash, so use sh instead if bash isn’t found.
sudo docker exec -it CONTAINER_ID bash
You’re now the root user inside the container. Anything you change here that isn’t in a mounted folder disappears when the container is replaced, so treat it as a place to look rather than a place to configure.
Why Use Docker Instead of a Synology Package?
Portability is the honest answer, and it is bigger than it sounds, because a container’s data lives in folders you chose, in a format any Docker host understands. A Synology package’s data lives wherever Synology decided to put it, and moving it means digging through the filesystem hoping to reassemble something on the other side.
The second reason is selection, because Package Center is limited and Docker Hub is not. Synology Drive is genuinely my favorite first-party tool, but it only exists in DSM, where something like Nextcloud does much the same job and runs anywhere. The containers I’d point most people at first are Pi-hole for DNS ad blocking, Uptime Kuma for uptime tracking, and Vaultwarden for passwords.
None of that is an argument against first-party packages, and I still run several. It’s that once you understand how containers work, the flexibility is worth the extra setup time, and the setup time drops fast once you’ve done it twice.
Where I’d Start
If you’re new to this, pick one container you actually want, find its Docker Hub page, and build it as a Compose project in the Project tab. Get the volume paths right, accept that the first one takes a while, and you’ll find the second one takes ten minutes.
The goal was never to memorize Container Manager, it was to be able to read any container’s documentation and translate it into Synology’s interface, because once you can do that the name on the package stops mattering. Docker, Container Manager, or Docker Compose on some other machine entirely, it’s the same job.
