​

1. The Matomo code base shows their latest stable version is 5.0.3. https://builds.matomo.org/
2. The Docker code is a community project. Matomo doesn't make it. That code is here:
   https://github.com/matomo-org/docker/issues
3. The combination of 1 and 2 are auto pushed to here https://hub.docker.com/_/matomo This version will have the stable release, Matomo 5.0.3, wrapped in a community based release of the Docker set up

Please note that the Matomo Docker images do not form part of Matomo's automated security assessments. They only do this for the Matomo codebase itself.​​​​

To be secure:

• Build your own docker image to be used for your Matomo deployment. For our security-focused users, this is going to be the best method available as it ensures you have complete and full control of all dependencies and packages installed in the container itself or
• Update the vulnerable packages in the docker image and save the patched image as your base image for deployment. This is likely the easiest solution if you don't want to go through the process of building your own docker image from scratch. The process of updating packages and committing the chanDockerges to the base image is out of the scope of our support, but there are several guides online that you can use to make the necessary changes to your docker image.​​​

Matomo does not provide hands-on, in-depth support for Docker but it is a popular way to deploy.

The general concept is similar to a multi-server Matomo model, so these diagrams are useful: https://matomo.org/faq/on-premise/how-to-configure-matomo-for-high-availability-multi-server-environment/

Three ways to upgrade Matomo without losing data (this is for sites with more than 1M hits/month).
Two of these are described here
https://matomo.org/faq/how-to-update/faq_20844/


Option 1 -
Creating a copy/replica of the existing production environment with a test database
The steps for this would be as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Update the config file to point to a testing/dev Matomo database
3. Update all plugins on this server
4. Update the database credentials to point to the production database
5. Update DNS records or Load balancer config to point to this new server
6. Run the core:update command to update the productions database

This option has the benefit of being able to update the codebase without directly making changes to the production environment, but doesn't allow for 1:1 planning for any potential issues with the production database.

Option 2 -
Creating a copy/replica of the existing production environment including the Matomo database
The steps for this would be as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Create a copy of the production Matomo database
3. Update the config file to point to the copied Matomo database
4. Update all plugins on this server
5. Run the core:update command to update the copied production database
   (This is our opportunity to look for potential issues and find an accurate time to plan for the production update)
6. Once we've tested the update, we update the database details to point to the production database
7. We can then update the DNS records or load balancer config to point to the new server.
8. Run the core:update

This option has the benefit of updating the codebase without impacting the production environment, planning for any specific issues that might arise from updating the production database and have mitigation strategies for that. It also allows for an accurate estimate of the required maintenance window for the production database update.

This strategy does not allow for minimal downtime and tracking during the update would need to use either the Queued Tracking or Log Analytics method mentioned here: https://matomo.org/faq/how-to-update/faq_20844/

Option 3 -
Creating a copy/replica of the existing production environment including the Matomo database and migrating to this replicated setup once updated.
The steps for this would be similar to option 2 and are as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Create a copy of the production Matomo database
3. Update the config file to point to the copied Matomo database
4. Update all plugins on this server
5. Run the core:update command to update the copied production database
6. Once we've tested the update and ensured that everything is working, we can then update the DNS records or load balancer config to point to the new server.
7. We backfill any tracking data that was sent to the old production instance since the replica was made

This strategy allows for the most amount of planning and doesn't require specific timeframes to complete the update. Since we can backfill the data as much as is necessary using the Matomo web server access logs (These need to be enabled in the web server configuration). The update can happen while the existing production database is running and the switch can be made once this replicated setup is fully updated and ready. The backfilling of tracking data can also be tested while running in parallel to the existing production setup to check for any potential discrepancy in the replayed tracking data.