How to update?

[michaelr524]

I've updated from the web UI as it offered.
But is this the right way?
How should an update be completed with docker-compose? (I'm using the nginx example)

[holzfelix]

I tried the update via the docker-compose. Changed Version. But UI still shows Version 3.4.1

[michaelr524]

Yep. Had the same issue.

[holzfelix]

Found the solution, go on settings, on top of the screen you find an button, search for updates.

[michaelr524]

Yeah @holzfelix that's what I meant that I updated from the web UI. Just asking if it's the right way or we should update it by pulling latest versions of the repo and rebuilding the docker images somehow.

[holzfelix]

yes thats the correct way of upgrading.

[Tideri-Tim2]

Yep. Had the same issue.

I have the same issue too. Dockerfile updated, new image pulled and container started. But the UI shows the old version. How come? Is there some kind of cache I have to clear? Log out and in again did not help. Thanks.

[holzfelix]

you have to click on update manually

[holzfelix]

klick on settings -> you have to click on the "Search for new versions" button

[Tideri-Tim2]

Thanks for your answer. I'm running Matomo on a Kubernetes system with a persistant-volume. So I guess I have to do both. Dockerfile-Update and the automatical file update like you are showing it now.
Thanks for your help!

[holzfelix]

yes you have to do both.

[codedmonkey]

I don't see any buttons to search for updates. I just get a prompt "New update: 4.5.0" which is already the version of the Docker image. I'm guessing it's getting the current version from the database so how do I check if it needs to perform any database migrations?

Looks like this is a known issue: #161

[evesinger]

can somebody please explain how they would do the upgrade, from let's say 4.6.2->4.10.1 in this scenario:

• self hosted on AWS, running docker image in some container on ECS
• DB is running on RDS

cause what I am doing is when I deploy the new docker image in ECS, I get to the setup screen again but then the step to connect to the DB fails with 'ACCESS DENIED' for any newer version than 4.6.2.

Is the proposed suggestion now to

• first do the update in the frontend so that DB knows about this new version
• then update docker container?

Why would that be necessary...and why do I get 'Access Denied' message? seems strange to me.

[psi-4ward]

So I did an update right now.... and ... it was wired.

1. /var/www/html is a volume https://github.com/matomo-org/docker/blob/master/Dockerfile-alpine.template#L89 so created a new container from an updated image still uses the old volume
2. The entrypoint.sh Script checks if theres already a matomo.php and if not, it will copy the files from docker-image.

So what I did is just delete the volume, recreated the container and execute ./console core:update
Ie docker inspect matomo => find the volume and do a docker volume rm ......

Never seen such a strange implementation of a docker image.

[J0WI]

This is somewhat blocked by matomo-org/matomo#19151

[JanMalte]

This is somewhat blocked by matomo-org/matomo#19151

Could you explain how the linked issue is related to provide a simple docker based update process.
I can‘t see how this should solve the issue with the mounted Matomo source volume.

[J0WI]

You need to update sources, optionally plugins, and then migrate the database. If you just update the source volume you may overwrite your configs or plugins. core:update can only migrate the database of existing installations but is useless if you start with a new installation or migrate your data and config to the new version. There might be workarounds but I'd prefer to wait for a stable CLI from upstream that I can use.

[cma-se]

My current solution is: I build the docker container as usual. So I have the new version under /usr/src. As the entry point prevent the use of the new version because it checks if the matomo.php is in the persistent volume. I attach a session to the running container and just execute the same commands like the entry point will do (cp from /usr/src and change owner)
I think this is only a workaround but I can't use the webupdater. Maybe I will use an updater container which has a different entry-point.
Did anyone see a problem in this approach?

[routmoute]

Simply remove matomo.php and restart the container with a new Matomo image works well for me.

[exetico]

I totally agree here. It's odd that Matomo doesn't really handle this as well, compared to other container images. A pull of the image(s) and a restart of the container, should indeed secure the newest version, if you ask me.

I've noted the tip from routmounte, so I'm currently execuing:

docker pull matomo && \
docker exec -it matomo-app-1 rm /var/www/html/matomo.php && \
docker restart matomo-app-1

(edit the context for docker-compose, or whatever you'd like)

Which did the trick for me...

I guess it would be better to remove the volume as noted in this issue, and using the ./console core:update, but... I'm sticking to this right now.

[FuckingToasters]

You should eb able to update it like any other docker image (make sure you use :latest tag in the image section of your compose file and then just redeploy it whenever there is a new version) alternativly you can use something like https://containrrr.dev/watchtower/ to automaate the update process for multiple running containers.