# cockpit-podman: a Cockpit interface for Podman containers

> cockpit-podman is the Cockpit web interface for Podman, and it talks to the container engine over the Podman REST API rather than shelling out to the command line. It is a thin, well automated front end: the interesting parts are the build, the release pipeline and the translation loop.

**cockpit-project/cockpit-podman** — Cockpit UI for podman containers

- Repository: https://github.com/cockpit-project/cockpit-podman
- Stars: 651 · Forks: 126
- Language: JavaScript
- License: LGPL-2.1
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/cockpit-project-cockpit-podman

## A front end over the Podman REST API

The mechanism is stated in one line in the README and it is the design decision that matters: cockpit-podman communicates to Podman through its REST API. That choice is what separates this project from a script that parses the output of the container command line. Every container operation the interface performs is an HTTP request against the engine's documented API, so the interface is bound to the API surface rather than to the shape of a command's output, and it is bound to the engine running on that host rather than to a local socket it spawns. The second fact in the README is that the project is based on the Cockpit Starter Kit, and the starter kit is what supplies the surrounding application structure, the build system and the development workflow that any Cockpit page needs. Together these two facts define the project precisely. It is not a container runtime, not a management daemon, and not a CLI wrapper. It is a page in the Cockpit web console that happens to talk to Podman, and the value it adds is that a person who opened Cockpit to check on a machine can now also look at the containers on it without leaving the browser.

## Building the source with gettext, nodejs and make

The build is a clone, a change of directory and a make. The development dependencies are listed per distribution, and both lists are short: gettext, nodejs and make.

```bash
    $ sudo apt install gettext nodejs make
```

On Fedora the same three packages come from dnf.

```bash
    $ sudo dnf install gettext nodejs make
```

Then the source is checked out and built into the dist directory.

```bash
git clone https://github.com/cockpit-project/cockpit-podman
cd cockpit-podman
make
```

gettext is in that list because the interface is translated, and the repository carries a po directory of translation files and the Weblate configuration for the workflow described further down. nodejs is there for the build tooling, and the package manifest shows the shape of that tooling: a build script called build.js is the entry point, with a watch mode that runs the same script with a watch flag, an eslint task over the source tree and a stylelint task for the stylesheets. The styles are Sass, since the lint task targets css and scss files and the build depends on esbuild with a Sass plugin. The TypeScript types are configured as well, with a separate tsconfig file and the TypeScript compiler itself listed as a development dependency. HACKING.md is the file to read for the details of running and testing the code, and the README points there rather than summarising it.

## Installing into the Cockpit share directory, or building an RPM

Installation is a single make target, and the README states exactly what it does and where it puts things. A sudo make install installs the package under /usr/local/share/cockpit/, which is where Cockpit looks for its pages, and it depends on the dist target, which generates the distribution tarball. There is also a make rpm target for building RPMs for local installation, which is the route to take when you want to test on a distribution that packages Cockpit rather than on a developer machine.

The build also has a production mode, and the README explains that in production mode source files are automatically minified and compressed, and that setting NODE_ENV=production duplicates that behaviour when you need it outside the normal build path. The Makefile shows how much of this is reproducible. The version is taken from git describe, the tarball name is built from the package name and that version, and the tar arguments are chosen to make the generated archives reproducible, with sorted names, a fixed modification time taken from the last commit, fixed permissions and a numeric owner and group. The test default is fedora-44, and there is a test scenario switch for a workspace container setup that uploads the tarball into a virtual machine and runs an install script, plus a special path for ostree and bootc images that skips the RPM build and uploads the dist directory into place instead. That last detail is the kind of thing that tells you how the project is tested: in virtual machines, on real images, not with mocks.

## Patternfly, xterm and what the interface is made of

The dependency list explains what a container console needs. Most of the entries are Patternfly packages, the design system Cockpit pages use, with the react-core components, the icons, the styles, the table and the tokens, all pinned at version 6.6.x. Two entries stand out for a container interface specifically. The xterm terminal packages provide the terminal emulator in the browser, and the addon-webgl variant brings the accelerated renderer, which matters because a container console is a character grid redrawn constantly and a software renderer makes that visibly worse. The rest is infrastructure: esbuild and its Sass plugin for the build, argparse for argument handling, and a small package called docker-names, which suggests the interface handles container naming conventions and the conflicts that come with them. The repository layout matches a page in a larger system. There is a src directory for the sources, a test directory, a packaging directory, a po directory for translations, a plans directory with the test plan metadata, a build.js, a Makefile, a packit.yaml for the Fedora and COPR release path, and an AppStream metainfo file for the package description. The presence of node_modules in the top level listing is a signal worth checking in a fork, since a vendored dependency tree in version control is a decision you inherit whether you want it or not.

## Releases are a signed tag and nothing else

The release process is described with unusual clarity, and it is the strongest argument for trusting this project's maintenance. The intention is that the only manual step for releasing a project is to create a signed tag for the version number, and that the tag itself includes a summary of the noteworthy changes, written as a short list.

```
123

- this new feature
- fix bug #123
```

Pushing the release tag then triggers the release.yml GitHub Actions workflow, which creates the official release tarball and publishes it as an upstream release on GitHub. The Fedora and COPR releases are handled separately with Packit, driven by the packit.yaml control file, which is the standard mechanism for building distribution packages from a GitHub hosted source. The version numbers are bare integers, and the recent history shows them moving steadily: 130 on 2026-08-27, 131 on 2026-09-23 and 132 on 2026-10-07, with the last push to the repository on 2026-10-22. There is no version scheme to learn and no changelog file to maintain by hand, because the changelog is the tag message. The practical advice for a user is simple: take the latest integer tag, and if you want to know what changed, read the tag message rather than searching a release page.

## Dependabot and a translation pipeline that runs on its own

The automated maintenance section covers two things, and both are about work that would otherwise rot. The first is dependency currency. The README stresses the importance of keeping the NPM modules up to date to follow security updates and bug fixes, and says this happens with dependabot, with the configuration file in the dependabot configuration in the GitHub directory. The second is translations, and the schedule is specific in a way that tells you how much text there is. Translations are refreshed every Tuesday evening, or manually, through the weblate-sync-po action, and conversely the PO template is uploaded to Weblate every day through the weblate-sync-pot action. The two directions make sense once you understand the split. The template holds the strings that exist in the source, and uploading it daily means a new or changed string enters the translation platform quickly, while the weekly pull back means translators work against a stable set and the merge does not fight with edits made in the same hour. The static analysis tools, mypy and ruff, are configured in pyproject.toml for the test and bot scripts, with strict typing flags and a broad ruff rule selection, which is a sign that the integration tests are treated as code rather than as scripts.

## Where this is the wrong tool

The boundary of the project is easy to state, and it is worth stating before anyone installs it. The interface is a consumer of the Podman REST API, which means the set of things you can do in the browser is the set of things the API exposes, and the command line remains the more complete surface. If your workflow needs an operation the interface does not surface, you will end up dropping to a terminal on the host, and the interface will not have saved you anything. There is also a deployment dependency: the project is a Cockpit page, so the machine needs Cockpit for this to be useful, and the install path writes into the Cockpit share directory, which is a system location. The other honest limitation is the version scheme. Tags are bare integers, there is no long term support branch, and the release cadence is roughly every two to three weeks with the last push a couple of days after the newest tag, so what you get is a moving target rather than a version you can settle on. For an organisation that wants a pinned interface tied to a pinned container engine, that is the argument for packaging it yourself with make rpm, rather than tracking main.

## Conclusion

Adopt cockpit-podman if you already run Cockpit and want container administration in the same console as the rest of the machine, and if you are willing to track the main branch, because the release numbering moves every couple of weeks and the tags are plain integers. It does not fit a team that wants a container management UI without also deploying Cockpit, and it does not fit a workflow that needs features the interface does not expose, since the underlying Podman command line remains the more complete surface. Before you build it, check the starter kit version your copy is based on, because the project states it is based on the Cockpit Starter Kit and that dependency decides how much of the surrounding scaffolding you inherit.

## FAQ

### How does cockpit-podman talk to Podman?

Through Podman's REST API, as the README states. The project is the Cockpit user interface for Podman containers and is based on the Cockpit Starter Kit, which supplies the surrounding application structure and build tooling.

### How do I build cockpit-podman from source?

Install the development dependencies, gettext, nodejs and make, then clone the repository, change into the directory and run make, which builds into the dist directory. The README gives the apt command for Debian and Ubuntu and the dnf command for Fedora.

### How do I install cockpit-podman?

Run sudo make install, which installs the package under /usr/local/share/cockpit/ and depends on the dist target that generates the distribution tarball. You can also run make rpm to build RPMs for local installation, and set NODE_ENV=production to get the minified and compressed production build.

### How are cockpit-podman releases made?

By creating a signed tag for the version number that includes a summary of the noteworthy changes. Pushing the tag triggers the release.yml GitHub Actions workflow, which creates the official release tarball and publishes it upstream, while the Fedora and COPR releases are done with Packit using packit.yaml.

### What licence is cockpit-podman released under?

LGPL-2.1, as stated in the package manifest and the LICENSE file in the repository. The package is named podman in the manifest, with the description Cockpit UI for Podman Containers.

## Sources

- [cockpit-project/cockpit-podman on GitHub](https://github.com/cockpit-project/cockpit-podman)
- [Issues](https://github.com/cockpit-project/cockpit-podman/issues)
- [License: LGPL-2.1](https://github.com/cockpit-project/cockpit-podman/blob/main/LICENSE)
- [README](https://github.com/cockpit-project/cockpit-podman/blob/main/README.md)
- [Releases](https://github.com/cockpit-project/cockpit-podman/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cockpit-project-cockpit-podman