Application Less Containers

This is conceptually similar to what we did for Postgres extensions at the StackGres [1] project. I gave a talk at a Kubecon about it [2].

However, this scheme is not perfect. Some Kubernetes security solutions enforce immutable containers, and once the agent pulls any additional file into the container, it will be flagged. It's also harder to reason about the security of the image (think CVEs, etc), given that its true contents are not known ahead of time.

We have also worked on a solution for this, which is to create dynamic container images. It still requires (as of today, may change in the future) restarting the container, but it keeps container images immutable. Apologies for the self plug, but I believe it may be interesting that I'll speak about it in the Container Days conference in September [3].

[1]: https://stackgres.io

[2]: https://aht.es/#talks-postgres_extensions_in_kubernetes

[3]: https://www.containerdays.io/containerdays-conference-2025/a...

(edit: formatting)

This is an excellent summary. We've had great success using Sparrow6 for the Ditana GNU/Linux installer because it allows for an agent-based, declarative approach. Shifting complexity from static configurations, such as Dockerfiles or linear installation scripts, to a dynamic agent that continually adjusts the system to the desired state is a powerful approach. This pattern works just as well for a full OS as it does for containers.

TL;DR - How to invert k8s deployments using application less containers design