Install Docker on Synology NAS

Check Your Model Supports It First

Container Manager is not offered on every Synology model — Synology decides model by model, and no setting unlocks it on a model that is not on the list. The Plus series models (the ones with a + in the name, like the DS220+ or DS920+) support it, and Synology also lists selected value models — the DS124, DS223 and DS423 among them, plus the DS420j from DSM 7.2. Most other small j-series and older play models are not offered the package at all.

The two-minute check settles it for your exact NAS: open Package Center and search for Container Manager (on DSM 7.1 or older, search for Docker). If it appears, your model is supported. If it does not appear, the package is simply not available for your model — there is no hidden switch to find.

Install the Package From Package Center

The install itself is the easiest part — it is a normal, official DSM package from Synology's own store. Open Package Center, search for Container Manager (or Docker on DSM 7.1 and older) and click Install. If DSM asks which volume the package should live on, pick your main, roomiest volume.

Wait for the install to finish, then open the package once so DSM creates its working folders. From DSM 7.2 onwards you will see tabs named Overview, Project, Container, Image, Registry, Network and Log. The older Docker package screens look slightly plainer but work the same way. Projects are how several containers that belong to one app are run together from a single Compose file — you do not need that for your first container.

Create the Docker Shared Folder Before Anything Else

This is the step beginners skip and regret. A container's inside is temporary — delete the container and everything stored inside it goes with it. Real data must live in a normal shared folder that the container is pointed at.

Open Control Panel → Shared Folder → Create and name the folder docker. Inside it, make one subfolder per app — for example docker/portainer and docker/jellyfin. One app, one folder: backups and cleanups stay simple. When you create a container later, you map its data path to its folder here. That mapping is called a volume, and it is the single most important idea on this page.

Run a First Container as a Test

Do not start with the app you actually care about. Start with a small throwaway container and prove the whole chain — image download, port, volume, logs — works. In Container Manager, open Registry, search for a small test image (a tiny static web server is ideal) and download it. Prefer images published by the official project or a well-known maintainer; random re-uploads by strangers are a risk. The downloaded image lands under Image.

Select the image and choose Run. Give the container a clear name you will recognise in six months. For the port: the container's own port is fixed by the app — your job is the local (host) port. DSM itself already uses 5000 and 5001 for its own web interface, so pick something clear like 8080 or higher and write it down. If the app stores anything, map its data path to a folder inside your docker shared folder — for a test app, a test subfolder is fine. Leave automatic restart off for a test container: you want to see it fail if it fails, not watch it restart in a loop forever.

Read the Log, Then Open It in Your Browser

Start the container, then open its Log tab before you touch your browser. The log is the app talking to you. A healthy app prints its ready line — often the address and port it is listening on. A container that starts and stops in a loop is telling you something is missing: a folder it cannot write to, a setting it needs, or a port already taken. The last few log lines usually name the problem in plain words.

Only now open your browser to your NAS address with the port you chose (for example, port 8080). Seeing the app's own page means the chain works: the image downloaded, the container runs, and you can reach it.

Do the Deletion Test — the Real Lesson

Now the step nobody wants to do and everybody should. Put one throwaway file or setting into the test app, then stop the container and delete it completely. Open your docker shared folder in File Station: the data you mapped is still there — because it was never inside the container at all. Recreate the container with the same volume mapping and the same setting reappears.

The app was disposable; the data was not. If instead the data vanished, you have learned the most valuable container lesson at the cheapest possible price: that app was storing data in the container's own temporary layer, and it needs a volume mapping before it can be trusted with anything real.

Honest Limits Before Real Apps