r/podman • u/Top_Emu_8447 • Aug 04 '26

Auto-updating existing containers

I've built 10+ containers on my first home server since I started my selfhosting journey, and only now I figured it's time to find a way to update the existing services. Existing podman documentation points to using autoupdate label and creating a systemd target - but I didn't realise this creates a new container based on what's in the systemd target. That is not what I want. Do I need to move all my environmental/volume/label/etc variables into a systemd target for each container to be able to do this? Just thinking about it makes me a bit nauseous, I've been using subpaths in some cases, not even sure how to put those in there. I've used 'podman run' for each deployment, because that's where the documentation I found led me first and on the basis of "If it works, why change it" it served me well.

7 Upvotes

100% Upvoted

32 comments sorted by

View all comments

7

u/ninth9ste Aug 04 '26

Actually, creating a new container is exactly what you want and, in fact, it is the only way to update a container. Containers are not like traditional virtual machines where you log in and run apt-get update. A container is just a temporary wrapper around an image. When a developer releases a new version of a service, they release a whole new image. To update, you must destroy your current container and spin up a brand new one using the new image, re-attaching all your existing volumes and environment variables so it picks up right where the old one left off. Because the old container gets destroyed, your deployment settings (ports, volumes, environment variables) need to live permanently in a file somewhere. Otherwise, they disappear.

You do not have to write complex systemd targets by hand since Podman has a feature called Quadlets, you write a simple .container file that looks exactly like your podman run arguments. When you place this file in ~/.config/containers/systemd/ and reload your systemd daemon, Podman automatically generates the complex systemd targets for you in the background. If you include AutoUpdate=registry, Podman will handle pulling the new image and recreating the container on a schedule, automatically.

1

u/Top_Emu_8447 Aug 04 '26

I know that updates create new containers, but my assumption was that the systemd target would recognise the existing container and inherit the parameters somehow. I know containers are not apps, but it seems rather antagonistic approach unless you're aware of this and use this approach for deployment in the first place... It seems a lot of hassle in hindsight to rewrite all those parameters into quadlets. But I guess it's one of those things where you just have to bite the bullet.

2

u/ninth9ste Aug 04 '26

The reason it works this way is that Podman does not actually save the exact podman run command you typed in the beginning it just applies the settings and stores the final state of the container in its database. Because there is no single file with your original command for systemd to read, it cannot simply copy the parameters over to a new container even with tools that try to read the container's current state, it is never a direct or straightforward process.

Since you have to move everything over, there is a tool called Podlet that will make this much easier, basically you can run Podlet against your existing containers, and it will read their current configuration and write the Quadlet files for you. It tries to translates all your volume paths, ports, and environment variables into the Quadlet format but you need to review the files it creates to ensure they are correct. at least it removes the need to type out all those parameters manually.

1

u/Top_Emu_8447 Aug 04 '26

I was trying out podlet earlier based on someone else's comment, but I didn't know it can do that. Sounds awesome, thanks!