podman-kube-generator: Podman Kube Generator Turns Live Containers Into a Portably Managed Stack

Most tools in this space start with a file. Podman Kube Generator starts with a working system. It connects to the Podman socket, inspects what is actually running, and exports that live state into Kubernetes YAML and Quadlet-friendly definitions.

The export button for a running stack

That inversion is the whole story. If you already have a Podman stack alive on a workstation, home server, or dev box, this project gives you a clean way to turn it into something you can keep, move, and operate later.

That matters because real stacks drift. Environment variables change. Volumes get remapped. A container is restarted with one-off flags and suddenly the original compose file, if it even exists, is stale. This repo does not pretend the file is truth. It treats the runtime as truth.

Why runtime introspection changes the workflow

The difference looks small until you use it. Static converters assume the desired system already exists on paper. This one is closer to an observability tool that turns into a generator: it asks what is there now, then produces artifacts from that.

That makes it useful in a very specific moment: the application already works, and now you want to formalize it. For developers prototyping locally, that is often the hardest step. The code is done. The orchestration story is not.

Quadlets make it more than a YAML exporter

The exporter is not stopping at manifests. It reaches into Quadlets, systemd units, auto-update flows, and even image pruning helpers. That is a different category of utility. It is not only helping you deploy. It is helping you keep the deployment healthy.

That is why the project feels unusually opinionated. A lot of tools stop at portability. This one cares about what happens after the export is generated.

How the generator thinks

Under the hood, the architecture is more disciplined than the feature list suggests. The generation engine builds Python dictionaries first, then dumps YAML from those structures. That sounds ordinary until you notice the payoff: the transformation logic stays testable and reusable instead of being buried inside template strings.

def build_service(container):
    spec = {
        "apiVersion": "v1",
        "kind": "Pod",
        "metadata": {"name": container.name},
        "spec": {
            "containers": [
                {
                    "name": container.name,
                    "image": container.image,
                    "env": resolve_env(container),
                    "volumeMounts": parse_volumes(container),
                }
            ]
        },
    }
    return yaml.dump(spec, sort_keys=False)

The interesting part is the judgment logic around volumes. Absolute paths become host paths. Relative paths move toward persistent storage. Special cases like /etc/localtime are handled explicitly. That is the kind of detail that makes the repo feel less like a serializer and more like a translator of intent.

There is a similar pattern in the rest of the codebase. The Django views handle UI flow, but the important inference work lives in helper functions that can reason about database connections, environment variables, and image metadata. The app is not trying to impress with framework tricks. It is trying to make the export reliable.

A small stack with strong opinions

The frontend stack says a lot. Django. HTMX. SQLite. Bootstrap. That is a compact, old-school combination, and it fits the problem. This is not a place for a heavy SPA. The job is to expose a sequence of decisions, keep the interactions snappy, and avoid making the generator itself harder to operate than the stacks it exports.

The project also shows a preference for self-contained infrastructure. JSON-backed models give it flexibility. Admin and analytics features stay in-house. The result is a tool that feels built by someone who expects to run it, trust it, and keep it around.

Security and defaults are part of the product

These are not flashy headline features. They are the kind of details that tell you the author expects the software to be deployed by real people, not just demoed.

That matters in a self-hosting context. The tool is helping people turn ad hoc container experiments into managed services, so defaults have to be conservative. A generator that can also nudge users toward safer setups is doing part of the ops work for them.

How it compares to compose and Kompose

This is not a winner-takes-all comparison. These tools live at different points in the workflow. Podman Kube Generator is the handoff from reality to artifact. Kompose is the handoff from declaration to artifact. podman-compose is the handoff from declaration to runtime.

That distinction is the repo’s identity. It does not try to replace everything upstream. It fills the gap after the stack already exists.

What this repo suggests about Podman’s future

The bigger signal here is cultural. Podman is not only becoming an alternative runtime. It is becoming a place where people can discover, inspect, and operationalize a container stack after the fact. That opens a different workflow for solo operators, home labs, and small teams who would rather export a working setup than reverse engineer it.

In that sense, Podman Kube Generator is more than a convenience tool. It is a statement about how infrastructure should feel. Start with something that works. Observe it. Then compile it into something durable.