CasaOS – Upgrading Containers

Update: As of the latest iteration CasaOS has an option to “Check and then update.” However, when I ran it against PiHole, which needed an update, it came back claiming current. So… these instructions still stand for the moment.

---

As of the current iteration of CasaOS, there’s no way to one-click yourself an upgrade on a container. Or, rather, there is, but only sort of. It’s all about how the container installed initially.

To check, pull a config file from the container in question:

1. Settings > choose Export ComposeFile
2. Open the file in your text editor of choice and search for the image: line. If it says something like “latest” or “develop” you’re good to go:
3. In this instance, all you need to do is click Save in CasaOS and the latest image will be pulled down and installed. But wait! Keep reading before you do so! If nothing else, jump down to step 7.
4. If the image has a hard coded version number, you’re going to need to change it to “latest” and save the YAML (as a different name, or take note of the version number, just in case you find you need to revert):
5. In the event you’ve had to  update your compose file, now comes the sweaty bit. You need to uninstall the app from CasaOS. If you’ve mapped all your data volumes correctly, this should be fine. Just remember to uncheck Delete userdata when prompted:
6. Once uninstalled, reinstall the app:
   1. Select App Store, then Custom Install
   2. Select the Import icon on the top right and select your YAML file.
   3. All the settings will be loaded in – confirm them and let ‘er rip.
7. Now, if you’re making a big upgrade, or an upgrade to a big app, things can get pinchy here for a bit. For instance, I upgraded Navidrome, my music server, and CasaOS barfed a message at me saying something akin to the container being unwell. I run PiHole in the same CasaOS instance, and I noticed that my browsing/DNS resolving had become profoundly slow. CasaOS’s nifty little stats didn’t show anything exciting insofar as resource utilization, but the CasaOS page was also profoundly slow and sluggish. I pulled up the terminal for Navidrome and discovered this:
8. Now, I have a lot of music. A LOT. So I SSH’ed into my device running CasaOS and navigated to the data directory for Navidrome to discover this:
9. Navidrome was indeed hard at work upgrading its ridiculously large database – as I refreshed I the timestamp on the db-wal file would continue to iterate.
10. Eventually the database upgrade finished, Navidrome loaded, and the container was healthy and upgraded.

The moral of the story is, be patient! Don’t freak out if CasaOS delivers some kind of ominous warning – dig deeper before doing  something drastic, like killing a running container in the midst of upgrading a critical database. I suppose you could be double safe by making a backup of your apps data directories before attempting an upgrade. I live on the edge. I recommend going through all your containers and updating all of the ones using hard-coded versions with something like ‘latest.’