This post is a tutorial on how to use Container Station 3 to update Containers and Applications on a QNAP server.
Updating the software version of a container is critical to ensure the latest and greatest version is running the best features, and possibly more importantly ensure all security updates are applied. QNAP’s Container Station will do most of the heaving lifting here – allowing you to manage the version via the QNAP admin.
Now if you’ve use Container Station 2 in the past – it’s been a bit clunky to manage and at times rather difficult to do updates. [see post Update Container Version in QNAP Container Station 2] When QNAP released Container Station 3 – they addressed many of the shortcomings of Container Station 2. Container Station 3 may look similar on the surface, however it has many huge improvements hidden within it. Container Station 3 solves most of the issues/complaints that were common in it’s prior versions.

Contents
- 1 Identifying if an Update is Available
- 2 How Container Naming and Versioning Works
- 3 Methods to Update Containers
- 4 Application vs Container
- 5 Container Station 2 Compatibility
- 6 Tutorial to Update a “Container” Image in Container Station 3
- 7 Tutorial to Update an “Application” Image in Container Station 3
- 8 Troubleshooting
- 9 Resources
Identifying if an Update is Available
The remainder of this post isn’t very helpful if it’s not known that an update is needed. So how does one identify that an update is required? Often times as a user of the software within the container a notice will be prompted. But not always – many updates go undetected. And that’s partly because there isn’t a great system in place to alert when new updates come along. So at this time, it’s a bit of a manual process. Make a habit to check frequently (first of the month?). Also check with the software developers – many have newsletters or alerts when new versions are released.
If a Docker image was used to create the container, the version releases are published at Docker Hub – so that’s a great place to check what the latest version is. Docker Hub uses fairly standard URL patterns, so that’s helpful. https://hub.docker/com/r/<namespace>/<package>
So for example, if the Image name in Container Station is mattermost/mattermost-enterprise-edition
, then the docker URL is: https://hub.docker.com/r/mattermost/mattermost-enterprise-edition
. Once on that page, click on the Tags tab – this lists all of the versions available. Not all tagged versions are the official releases however. Some developers put frequent tags into Docker Hub with their work in progress. It’s typically best to take the official releases – which will often have a numbered scheme to them or start with the name release-<version_number>
. Each developer can choose to mange this how they’d like. There are some standards, but not always followed the same by all developers.
A helpful tip is when creating a container in Container Station use the <version_number>
in the container name so that it’s quickly identifiable what version the container is. This small bit of effort will pay off in the long run of not having to click into the container to look at the image to figure out what version it is (and if the version is :latest
it’s still not identifiable)
Another tip is that most developers publish notes of what changed in each release. But they don’t publish this at Docker Hub. Release notes are often available at their website, or GitHub (look for the Releases link in the right hand column).
And lastly – once you’ve found the Docker Hub page and release notes for a software package – it’s smart to bookmark these. Make a folder in your browsers Bookmark bar and add these there. They will be visited again in the future I’m sure!
ASIDE: Ideally the system would ping Docker Hub from time to time to see if there is an updated version of a container and alert in some way (ie. email) so that it can be applied when desired. Full disclosure: I don’t have that setup at this time and thus I don’t know much for specifics here. However some possible options are Watchtower or docker notify.
How Container Naming and Versioning Works
As software developers update their software, they increment the version number. This helps to know/understand what features/bug-fixes you are running. Each container has a specific naming pattern, which often includes a version number. Example:
1 | namespace/package |
The namespace
is the vendor or software manufacturer who created the image.
The package
is what the software is. There can be many package
s for one namespace
.
A /
separates the namespace
and the package
.
To specify what version of a package
the container is, a version number is added at the end of the container name. Example:
1 | namespace/package:2.4 |
A :
separates the image naming and the version.
Alternatively the version can be left off as in the initial example in this section. Or latest
can be used. Both have the same result – the latest version of the containers package will be used. Example:
1 | namespace/package:latest |
A wise strategy to use with the version number is to specify the specific version number. Typically the latest version number will be used, but it’s better to specify that version as opposed to using :latest
so that it’s clear in the future to know what version is installed. It becomes a quick easy reference and also is helpful in ensuring that the software is what it is. Additionally when it comes to applying version updates this makes it easy to keep things straight. Another thing to consider when deciding to use :latest
or :<version_number>
is that not versions run as expected. There may be reasons that the latest version isn’t desired and thus forcing a specific version will ensure your system runs smoothly and as expected.
Methods to Update Containers
Container Station 3 provides two methods for updating containers.
- Update in place
- Duplicate Container
Each of these methods have their pros and cons. Understanding when to use either method and the outcomes is wise to know before beginning the update.
Feature | Update in Place | Duplicate Container |
---|---|---|
Container Usage | The existing container is reused. This minimizes disk space usage and doesn’t require cleanup of old containers. However if the update goes wrong for some reason, or the updated version isn’t suitable, it becomes a larger task to rollback to an older version. | A new container is created for each version. This method insulates against update failures or unforeseen reasons that a rollback to an older version if needed. This does create multiple versions of the software package, which does result in some cleanup over time – deleting older unused containers, ensuring only the latest version is set to auto-start, etc. |
Disk Space Usage | Less | More (until manual cleanup run) |
Container Settings | Not all of the settings transfer to the new container – they must be configured manually in the creation process. |
Application vs Container
Container Station has two methods for creating containers:
- Applications
- Containers
Containers are the most straightforward method of using Container Station as it is the least complex, runs one system, and much of it’s configuration is pre-set. These are single stand-alone containers.
Applications offer a more robust solution allowing multiple Docker images to be configured to be running in the same Container. (a bit confusing, I know). Applications will require writing a Docker Make file using a language called YAML. This is outside of the scope of this article. A few pre-built YAML files are offered for common applications as needed.

Depending on if the container to be updated is a Container or an Application requires a slightly different process as outlined below.
Container Station 2 Compatibility
In my personal experience, I found some Container Station 2 containers that the Duplicate method didn’t work – thus forcing a complete recreation of the container under Container Station 3. The recreation can be made easier by clicking into the existing container and clicking the Inspect button. This will display the parameters used to create the container. This can help in guiding how to recreate the a new container.

Given how the QNAP UI works, you likely need to close this screen though before being able to create the new container. QNAP didn’t provide a simple way to copy this… While you can highlight the text and copy it, anything under a closed triangle expander will not copy unless it’s expanded first. Thus you need to click on all of them to expand, then you can copy all of the text and paste it into a text editor to keep it as a reference as needed.
Tutorial to Update a “Container” Image in Container Station 3
Follow this process step by step to update Container Station 3 images for a Container on a QNAP server. As mentioned above, there are two methods to do this – Update in Place and Duplicate Container. Tutorials for both methods are below to guide through the process.
Steps for Update in Place to Upgrade a “Container” Image in Container Station 3
When using Update in Place the container is reused. The settings can be altered with this method. If issues with the updated version are encountered the method of going back is to update the container again changing the settings back.
- Login to the QNAP Admin Panel
- Open Container Station
- Click on Containers
- Click on the Name of the container to update
- Click the down arrow next to the Edit button and select either the Recreate Directly or Recreate option
- To know which option to use, look at the Image heading in the left hand column of the container information panel.
- If the Image has
:latest
at the end of the name or no specific version number (ie.:12.1.4
) then the Recreate Directly option should be used as no modification will be necessary. - If the Image has a specific version number (ie.
:12.1.4
) then the Recreate option is needed to allow for changing the container settings.
- If the Image has
- To know which option to use, look at the Image heading in the left hand column of the container information panel.
Recreate Directly Method
- Check the Try pulling the image from the registry before creating the container. check box.
- Click the Yes button
Recreate Method
- Alter the Image: field setting the image number at the end of the name as needed (ie.
:12.0.1
).- See section How Container Naming and Versioning Works
- Check the Try pulling the image from the registry before creating the container. check box.
- Click the Next button
- Set the Restart policy: to
Always
so the container will restart if it were to crash or upon server restart - Click the Next button
- Click the Finish button
At this point Container Station will take over and download the image from Docker hub, create the container, and finally auto-start the container (based on the policy set). After a bit of time the container will be running and this task is complete.
Steps for Duplicate Container to Upgrade a “Container” Image in Container Station 3
Duplicating a container results in more than one containers of different versions. This provides a quick/easy method to roll-back to the prior container if needed. This method is not recommended when the version is :latest
however. Without a clearly defined version number anytime the underlying image is updated any container with a version of :latest
would inherit that update. The Recreate Directly Method above is desired in that case.
Login to Container Station on QNAP
- Login to the QNAP Admin Panel
- Open Container Station
- Click on Containers
- Click on the Name of the container to update
Disable Auto-restart
Typically containers are configured to restart automatically. Since the existing container will no longer be used, it’s wise to ensure that it’s no longer going to auto-restart.
- Click the Edit button
- Set the Restart Policy to
None
- Click the Apply button

Backup Settings
Some of the settings don’t carry over as you’d expect. So doing a quick prep-work step makes it easy to get past this hurdle.
- Click the Inspect button
- Expand out the closed arrows to reveal sub-content – namely the Mount section.
- Copy the contents of the Inspect window and paste it into a text editor to reference later.
Duplicate the Container
Next to start the creation of a new updated container.
- Click the Stop button to stop the container
- Click the down arrow next to the Edit button and select the Duplicate option
- In the Image field set the image name and version.
<namespace>/<package>:<version>
<version>
can be set tolatest
to pull the most recent version or set to a specific version number.
- Check the Try pulling the image from the registry before creating the server box
- Click the Next button
- Set the Name accordingly
- Set the Restart policy as desired. In most cases it is ideal to use
Always
- Some of the settings don’t transfer in from the prior container. Click the Advanced Settings and go through all the settings to ensure they are set as expected. This is where the previous settings from the Inspect window in the previous step can be used to reference how the settings should be configured.
- Click the Apply button
- Click the Next button to move onto the Summary step
- Click the Finish button

Container Station will take some time to download the image from Docker hub, create the container, and start it up. At this point the version update of the package should be up and running on the duplicated container and all is set to go.
Tutorial to Update an “Application” Image in Container Station 3
These steps will walk through updating the images within an Application on a QNAP server. These tutorials will cover both the Update in Place and Duplicate Container methods.
Login to Container Station on QNAP
- Login to the QNAP Admin Panel
- Open Container Station
- Click on Applications
- Click on the Name of the Application to update the images for
Within this screen the multiple containers/images that are running within the application are listed. Depending on the application, maybe one image would need to be updated but not the others.
It is possible to duplicate the entire Application using the down arrow next to the Edit button. But that’s not the focus of what is to be one here as the focus of this tutorial is for the underlying images.
Steps for Update in Place to Upgrade an “Application” Image in Container Station 3
This method can only be used for applications where the version number is not specified in the applications YAML configuration for the image
, or the version is set to :latest
. The same application will be used. The process will fetch the latest copy of the image from Docker Hub to use for this application.
- Click the down arrow next to the Edit button
- Select the Recreate option
- Click the Update button
Wait as QNAP goes through it’s processes to download the image from Docker Hub, install it, and restart the container. In time, the container will start itself back up and be running again.
Steps for Duplicate Container to Upgrade an “Application” Image in Container Station 3
Duplicating an application means that the original application stays intact. The benefit here is that if anything were to go awry, the original application is there to fallback on. This creates a layer of safety that is wise. The downside is that the old image will still stay around and after the duplicated application is proved to be running sufficiently, the original should be manually deleted. If not, it eats up file space and creates more clutter. Not a huge downside, but could be an issue in time.
NOTE: Some containers/applications do upgrade resources such as databases and configuration files when and updated version is applied. There is a chance that this could break the safety fallback of re-enabling the older version of the application. Identifying which applications this will affect and which won’t is out of the scope of this post however. But some research and critical thinking about how the application is built and runs can be applied to help here.
Disable Auto-restart
It is common that the containers are configured to restart automatically should they fail. Once this process is complete Since the existing container will no longer be used, it’s wise to ensure that it’s no longer going to auto-restart.
- Click on the Applications tab in Container Station
- Click on the Application name that will be duplicated
- Set the Restart Policy to
None
- Click the Apply button
If multiple images are part of the application, repeat this process for each image.
Stop the Current Container
Stop the running application and it’s images as they will no longer be needed – they are being replaced by the newer version.
- Click the Stop button in the top right
Depending on the image running, this may take some time to complete as it may have a shutdown sequence to execute.
Duplicate the Container YAML
- Click on the Applications tab in Container Station
- Click on the Application name that will be duplicated
- Click the down arrow next to the Edit button and select the Duplicate option
- Select Duplicate
- Set a name in the Application name: field. It is wise to include the package name and version number that the new container will be updated to.
- In the YAML code: section, change the
image
properties value setting the propernamespace/package:version
to the desired version. - Click the Create button
At this time the new version of the image needs to be pulled from Docker Hub into the QNAP server and thus it will take a few minutes to complete. The progress of this can be monitored in the queue at the top of the QNAP web admin. Notice a counter shows up on this queue loader to indicate that it is making the container. When it is complete, it will show in the list of applications.

Click on the main Applications tab in the left hand column to see what applications are running. In time, the new application will show in this list.
Enable Auto-restart
It’s typically desired to have the application restart automatically if it were to crash or the system is restarted. Since auto-restart was disabled before duplicating the application, this application will not auto-restart. Enable auto-restart for the new application.
- Click on the Applications tab in Container Station
- Click on the Application name that will be duplicated
- Set the Restart Policy to
Always
- Click the Apply button
If multiple images are part of the application, repeat this process for each image.
Troubleshooting
Update Options are Greyed Out
For whatever reason some containers created in prior versions of Container Station can not be updated using the processes explained here. The Recreate
and Duplicate
options are greyed out and do not work. This implies that there is an incompatibility with the container and how Container Station 3 work. The workaround here is to manually build a new version of the container in Container Station 3. From this point forward the update methods outlined here should succeed since the new base container was built in Container Station 3.