Podman Desktop: a desktop client that treats four container engines as one target

One interface over Podman, Docker, Lima and crc

The premise is narrower than the marketing implies and more useful for it. Podman Desktop does not replace your container engines; it gives all of them one graphical client. The README names four: the Podman container engine, crc, Lima for Linux machines, and the Docker container engine. A dashboard covers containers, images, pods and volumes, and a system tray keeps the engine reachable without switching windows.

Two features sit above that dashboard and are the reason to choose this over a plain Podman client. The first is Kubernetes context handling: you can define contexts, switch between them, and deploy pods to local or remote clusters from the same window. The second is that Podman Desktop will keep the `podman` binary itself up to date, installing new versions rather than leaving you to track releases.

For someone whose work spans a laptop running Podman, a Linux VM under Lima, and a remote cluster, that consolidation is the actual value. For someone who only runs Docker and is happy with its own tooling, the honest answer is that this is a second client rather than an upgrade.

Extensions are separate packages in a pnpm workspace

The repository is a pnpm workspace, not a single package. `pnpm-workspace.yaml` and `pnpm-lock.yaml` sit at the root, `packages/` holds the main process, preload scripts, UI and renderer, and `extensions/` holds one directory per integration.

The build script shows how mechanical the split is. Every extension is its own build step, and the aggregate is a chain:

pnpm run build:extensions:compose && pnpm run build:extensions:docker && pnpm run build:extensions:podman-docker-context && pnpm run build:extensions:lima && pnpm run build:extensions:podman && pnpm run build:extensions:kubecontext && pnpm run build:extensions:kind && pnpm run build:extensions:registries && pnpm run build:extensions:kubectl-cli

Nine integrations compile in that chain: compose, docker, podman-docker-context, lima, podman, kubecontext, kind, registries and kubectl-cli. Note that `podman-docker-context` is its own package, which tells you that making Podman and Docker interchangeable to the CLI is treated as a first-class concern rather than a config toggle. The `kind` and `kubectl-cli` packages are equally telling: this is a Kubernetes client that happens to manage containers too.

Developing against it is one command, and the tree shows the tooling that surrounds it: Playwright for end-to-end tests, Storybook for the UI, Biome and ESLint configs side by side, and Husky for commit hooks. Node 24 or newer is required, and `package.json` also declares npm 10.2.3 or newer as an engine constraint even though every script in the file invokes pnpm. Both statements are in the manifest; in practice pnpm is the tool the repository is written for.

Root-level files that describe how the project is distributed

A handful of root files exist for packaging and catalog metadata rather than for building the app, and they are the clearest evidence of how the project expects to be distributed.

featured.json
product.json
recommendations.json
.flatpak-appdata.xml
.flatpak.desktop
.chocolatey/

The Flatpak appdata and desktop files, plus the Chocolatey directory, are the metadata that Linux desktop software catalogs consume. `product.json` and `featured.json` sit alongside them, and `recommendations.json` is the kind of file a registry uses to cross-promote companion tools. `CUSTOM_UPDATE_SERVER.md` at the root covers an enterprise concern, which is pointing the auto-updater at an internal server.

This is worth understanding because it explains why the app behaves like a desktop application rather than a developer script. It has an update channel, a signing story, and catalog entries. The README is thin on all of this and points to podman-desktop.io for downloads, which is the right place to get a build anyway.

AI agent configuration checked into the repository root

Among the dotfiles are `AGENTS.md`, `CLAUDE.md`, `.mcp.json`, `.agents/` and `.claude/`, alongside `.devcontainer/` and `.vscode/`. A contributor agent configuration, a Model Context Protocol server declaration and a specific vendor's instruction file are all versioned at the top level.

That is a deliberate choice rather than an accident, and it has a practical consequence. `AGENTS.md` and `CODE-GUIDELINES.md` are the files a coding agent reads when working in this repository, so the project's own conventions are available to tooling automatically. If you are contributing a patch, the fastest way to match house style is to read those two files rather than infer it from surrounding commits.

It also signals where the project's development attention is going. The presence of `.agentready-config.yaml` and `.fullsend/` suggests the repository is being prepared for automated contributors. Whether that helps or hurts a given pull request is not something the repository settles, but the configuration is committed and anyone can read what it instructs an agent to do.

A link trail that still points at the old organization

Several README links resolve through `github.com/containers/podman-desktop`, while the repository actually lives at `github.com/podman-desktop/podman-desktop`. The issue link, the milestone link and the pull request link all use the `containers/` path. Those redirects work, which is why the README still reads correctly today.

The distinction matters only if you are deciding where to open something. File an issue against `podman-desktop/podman-desktop` and it lands in the tracker that is actually scanned; the redirected URL reaches the same place, but the rendered issue link and any tooling that reads the raw path will show the old organization. Nothing in the README acknowledges the mismatch.

The repository is not archived and the last push was on 2026-09-21, the same day release `v1.30.0` was published, with `v1.29.2` and `v1.29.3` in the two weeks before it. The manifest on `main` reads `1.31.0-next`, which is the ordinary state of a repository between releases rather than a version discrepancy worth worrying about.

Where the documentation lives versus where the README stops

The README is a signpost. Usage, downloads and feature lists all resolve to podman-desktop.io, the documentation site, and to GitHub Discussions for questions. Community presence is spread across a Discord server, libera.chat on IRC, a Matrix room on fedora.im, and a Kubernetes Slack channel, with the README noting that the three chat platforms are bridged.

The governance files at the root are more substantive than the README: `GOVERNANCE.md`, `MAINTAINERS.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md`, `SECURITY-INSIGHTS.yml` and `CONTRIBUTING.md`. `SECURITY-INSIGHTS.yml` is the OpenSSF scorecard configuration, which is how the project feeds its security posture tooling. `ADOPTERS.md` is the one a prospective extension author should read first, and `RELEASE.md` covers the release process.

For contributors, the documented path is the standard GitHub flow: issues for bugs and feature requests, a community meeting for discussion, and a pull request for changes. For users, podman-desktop.io is the authority on supported platforms, since the README does not enumerate which operating systems the published builds cover.

Editorial conclusion

Podman Desktop is at its best when you move between engines rather than when you commit to one, because the multi-engine support and the Kubernetes context switcher are the features that Docker Desktop does not attempt. The extension architecture is real but shallow: `extensions/` packages each compile separately and register into the app, and the catalog files at the repository root suggest distribution metadata is part of the design. Install the signed package from podman-desktop.io rather than building from source, and read `ADOPTERS.md` before writing an extension.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. podman-desktop/podman-desktop on GitHub
3. Project website
4. README
5. Releases