Update Containers on Synology NAS Without Losing Data
People fear container updates because they have seen the warning: the container will be recreated. Recreated sounds like erased. It is not — as long as two things are true before you start. This guide gives you the update routine that experienced NAS owners actually follow: check, back up, update one app, verify, and only then move on.
🎥 Watch the complete installation in the video — Docker on a Synology NAS, step by step
A container is never patched in place. The app maker publishes a new image, and updating means swapping your old container for a fresh one built from that image, with the same settings. Everything the container stored in its own temporary layer disappears in the swap — and everything stored in a mapped shared folder survives, because it was never inside. That single fact divides safe updates from disasters, and it is why the volumes guide in this series comes before this one. If your app's data is not in a folder you can see in File Station, fix that first. Updating it is how people find out.
An update, honestly drawn
App image — old versionREPLACED
Container built from itRECREATED
Data in a mapped shared folderUNTOUCHED
Data inside the container onlyLOST
Old image kept on diskYOUR WAY BACK
An update replaces the app, not the data — provided the data lives in a mapped folder and you kept the old image until the new one proves itself.
1
Before Any Update — The Five-Minute Preparation
Updates go wrong rarely and at the worst times. This preparation is what makes a wrong update a ten-minute inconvenience instead of a lost weekend.
Export the container's settings. In Container Manager, open the container and use its export option to save a settings file to a safe folder. If a recreation ever scrambles your ports or variables, this file rebuilds the container in minutes.
Confirm the data is mapped. Open the container's volume settings and check its data path points at a shared folder. Look inside that folder in File Station and see the app's files with your own eyes.
Check the app's release notes if it is something important — a database or anything with a major version jump. Occasionally an update changes data formats and cannot go backwards.
Update when you are home, awake, and not in a hurry. Friday night before guests arrive is not update time.
2
The Update Itself in Container Manager
Container Manager watches the registry for you — when a newer image exists for a container, the interface flags it, and images offer an update action.
Download the new image version of your app's image. The old image stays on disk beside it.
Stop the old container. Use the container's update or reset-to-new-image route in Container Manager, or delete the container and recreate it from the new image with the exported settings — same ports, same volume mappings, same variables.
Start the new container and read its Log. First starts after an update often run migrations; give it a minute before judging.
Open the app and check your data like a sceptic — recent items, settings, the thing you would cry about. Present and correct means the update is done.
3
If the New Version Misbehaves — Rolling Back
This is what the kept old image is for.
Stop the new container and delete it — its data is in the shared folder, untouched.
Recreate the container from the old image, which is still listed under Image, with the same settings export.
Start it and verify. You are back where the evening began, and the update can wait for a better day or a fixed release.
One honest exception: if the new version already migrated the app's database format, the old version may refuse the newer data. That is what the app's backup — and your exported settings plus a copy of the data folder taken before important updates — are for. For your one or two critical apps, copying the app's docker subfolder before a big update is cheap insurance.
4
One at a Time — And Not Everything Deserves Auto-Update
The temptation is a tool that updates every container the moment a new image appears. Resist it for anything you rely on.
Update one app, verify it, then the next. Three broken apps at once means three mysteries; one broken app means one.
Small stateless tools can update casually. Databases, photo libraries and anything whose data format changes get the full ceremony — notes read, folder copied, log watched.
An app that works is not obliged to chase every release. Security fixes deserve prompt attention; a cosmetic release can wait for your monthly maintenance pass.
Delete old images only after the new version has survived a few days of real use. Disk space is cheap; a way back is priceless.
5
Projects and Compose — Updating a Whole Stack
If your app runs as a Project (Docker Compose), the same logic applies with tidier mechanics: the compose file is your settings export, permanently. Updating means pulling the new images for the project and rebuilding it — the services are recreated with the same volumes and ports the file declares. Keep a copy of every compose file outside the NAS as well, and the stack can be rebuilt on any machine, not just this one. The compose file plus the data folders is the entire app, in a form you can carry in a coat pocket.
🐳 Update rule: export settings, confirm the data folder, keep the old image, update one app and verify it. Four habits, five minutes — and there is no container update left that can actually hurt you.
🎥 Watch the Complete Video
The full Docker on Synology NAS installation, shown live on a real NAS from package install to a running container.
Not if the app's data is mapped to a shared folder — that data sits outside the container and is untouched by the swap. If the app stored data only inside the container's own layer, that data is deleted when the container is recreated. Check the volume settings before updating anything important.
How do I go back if an update breaks the app?
Stop and delete the new container, then recreate it from the old image, which Container Manager keeps on disk until you remove it, using your exported settings and the same volume mapping. Your data folder was never changed by the swap. Only delete old images after the new version has run well for a few days.
Should I let a tool update all my containers automatically?
For small, stateless tools it is a convenience some people accept. For databases, photo libraries or anything that migrates its data format between versions, automatic updates are how people lose weekends — update those manually, one at a time, after reading the release notes.
This guide is based on the Technical Anshu video on installing Docker on a Synology NAS • Stuck on a step? Ask in the video comments 🙏