Bitnami Deprecation

I’ve long said that, when using container images in production, it’s vitally important that you build and maintain all of your own images, or if you want have some kind of commercial maintenance agreement for them. Relying on freely provided externally managed images is a recipe for problems down the line.

I’m not sure this is the right approach, but I am somewhat scared at the Docker Compose tsunami in self-hosting. While people are very productive, it gives me very bad vibes about maintenance, etc. But perhaps it doesn’t matter so much.

My most frequent opinion is that… you should take a look at upstream for the services that you want to run, and see what’s their preferred method of distribution. Many OSS services do not even provide clear distribution instructions (well, we don’t pay for it, so…), and lately this has been container images more and more. If you want to run things on LTS distros and have some modicum of stability… things can get complex.

Surprisingly, a lot of services I run have RHEL-compatible packages, but I run some stuff in Kubernetes because… the project only provides Docker images. But then if it’s the original authors providing the images, well, I expect them to be well-updated, at least compared to anything else.

With Go, Cargo, uv, … and other language dependency managers that are figuring out how to run stuff smoothing out differences between operating systems, I see some room for something that works with those tools to keep software running an updated.