Upgrading container tarball deployment, is it just "drop-in"?

I have a new self-hosted Mattermost 10.3.1 running in a container (LXC, not Docker) - essentially the Mattermost tarball and the libraries it needs, plus nginx. The only persistent Mattermost parts are the data directory and the config/config.json file. I am not using any plugins. I am able to destroy and re-create the container (with the same Mattermost version) with no problems.

I want to know if I can simply build a new image, using the new 10.4.1 tarball instead of 10.3.1, leaving everything else the same and then stop the old container and spin up a new one with the new image.

I expect this will work and that, when Mattermost ( /opt/mattermost/bin/mattermost server ) runs, it automatically applies any required changes (if any) to data and to the data in Postgres. I’m just looking for confirmation of that please.

If so, I presume this is a one-way street, so I will snapshot the persistent volumes and database prior to doing this in case I need to roll back. Or is it ok to “go back” to the prior version image ?

Furthermore, can I switch between the Enterprise and Team tarballs without impact? I am running unlicensed and not using any enterprise or trial features. The reason for asking this is because I deployed the enterprise tarball without realising (see FYI below) and I could switch to team version now when building my new image. Also, if on the team version, I could just switch to the enterprise version in future, should my needs change?

(FYI the tarball install documentaion does not mention the team tarball url, I only discovered it today when reading the upgrade documentation.)

Thanks very much.

Well I went ahead and just did this and it is fine. I stayed on the enterprise version (in free mode) just to minimise risk until I hear if it’s ok to switch. I noticed the db schema version didn’t change so that probably minimises any potential issues.

It would still be good to get guidance on this, ahead of the next upgrade.