# Container Desktop: a Podman desktop GUI that also drives Docker and remote engines > container-desktop is a desktop application for Podman that presents the same interface on every platform, with a dynamic engine based theme, no telemetry, and support for Docker engines and remote connections alongside Podman. It is built on Electron, with Tauri and Wails shell variants in the tree, and the AI assistant is a documented subsystem rather than a bolt-on. **iongion/container-desktop** — Podman desktop companion - Repository: https://github.com/iongion/container-desktop - Website: https://container-desktop.com/ - Stars: 1,638 · Forks: 51 - Language: TypeScript - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/iongion-container-desktop ## What it is: a companion to Podman, not a Podman Desktop fork Container Desktop is described in two words as a Podman desktop companion, and the homepage is container-desktop.com. The distinction from Podman Desktop matters, because a companion that presents a familiar interface is a different proposition from a fork that inherits a codebase and its conventions. The project is by Ionut Stoica, the primary language is TypeScript, the licence is MIT, and the manifest version is 6.0.0 with a release of the same number on 2026-07-06 preceded by 5.3.18 and 5.3.17 in early July. The last push to the repository was on 2026-09-29. The Author notes section gives the three positions the project commits to, and they are all about restraint: no telemetry, an identical UI on all platforms, and a dynamic engine based theme. ## Podman is the engine, but Docker and remote connections are first class The README is explicit that Podman is the driving engine, and there are separate screenshots for the Podman view and the Docker engine view of the connections manager. The Requirements section says that on Linux you install Podman, with a note that distributions usually ship older versions and a pointer to the Aalvistack repositories for the most recent ones. If you want to add support for the Docker container engine, the README says the easiest route is to install rootless Docker as documented. The Multiple engines and remote connections supported section and the Docker engine Connections screenshot make it clear this is a multi-engine client rather than a Podman-specific one, and the documentation has a dedicated engine matrix page, which is the file to read before assuming a feature works the same way on each engine. ## The platform requirements are where the real work is The Requirements section is short but each line has a condition attached. On Linux you need Podman, and additional packages besides Podman may be required, with aardvark-dns and passt named for networking. On Windows you install Podman or provision a WSL distribution with the latest Podman following the Linux instructions, and the detail is that on a custom WSL distribution the engine's own system dial-stdio bridges its unix socket back to the Windows native context, described as a named pipe bridge to wsl.exe stdio, with no TCP listener and no SSH server inside the distribution. That is an unusual and specific architectural choice: the transport is stdio rather than a socket, which removes a network listener but also means the Windows path is not the same as the Linux one. On macOS you install Podman or Lima. There is also a LIMA setup guide in the documentation directory. ## The AI assistant is an architecture document, not a feature bullet The documentation index lists an AI subsystem page among the architecture documents, alongside overview, backend, frontend and connection startup, and there is a screenshot labelled AI assistant. That distinction is the interesting one. Most desktop applications would list an assistant in the feature list. Here it has its own architecture document next to the backend and the frontend, which suggests it is a designed part of the system with its own process and communication model rather than a chat panel bolted onto the side. The same treatment is given to connection startup, which is the part of a container client that is hardest to get right, since the app has to find the engine, authenticate to it and survive the engine not being there. There is a full set of documentation for both, and a principles page called Notes / principles, which is where a project states the rules it holds itself to. ## Three desktop shells in one repository, which is the biggest structural decision here The top level of the repository contains src-tauri/, src-wails/ and src/, alongside the Electron build in the package.json. The scripts make the arrangement explicit. The main Electron build is composed of build:main, build:preload and build:renderer, each a separate Vite build with its own config file, vite.config.main.mjs, vite.config.preload.mjs and vite.config.renderer.mjs, plus a common config. Then there is a parallel set of Tauri scripts, tauri:renderer, tauri:serve, tauri:dev with a mock mode driven by CONTAINER_DESKTOP_MOCK=1, and tauri:build. And a Wails entry, wails3, with an asset staging script that copies tray icons for the docker, podman and unified variants in light and dark. Three shells means three ways to ship the same interface, and the tray icon staging is a small but telling detail, because the icon has to change with the active engine and the theme, in every build. ## The Makefile shows the release process, and it is not a one-liner The Makefile at the root is unusually informative about how this project ships. There is a prepare-node target that sources nvm from NVM_DIR when it is present, installs the .nvmrc version if missing and then runs yarn install with a frozen lockfile, and the comment explains that nvm is a shell function that must be sourced before use. The check and format targets run Biome lint and format including support/cli. There are build-website and screenshots targets, and build-assets depends on both, so the website and its images are rebuilt as part of the asset pipeline. The trigger-cd-pipeline target reads the VERSION file and calls the GitHub workflow CDPipeline.Tauri.yml with a git-ref, a stage of production, a target of all and publish-release true. The header comment on the release target says it cuts a release keeping the docs, the static site, the screenshots and the demo videos in sync inside the release commit. ## Tooling: Biome, Vite, Vitest in three configurations, and a webdriver directory The tooling stack is visible from the file names. Biome is the linter and formatter, configured in biome.json, and the Makefile targets run it across the project including the CLI in support/. Vite does the bundling with separate configs for main, preload and renderer and a common file. Tests are Vitest, and there are three configuration files for it, vitest.config.mts, vitest.live.config.mts and vitest.ui.config.mts, which suggests unit tests, live tests against a real engine and a browser based UI mode. There is a webdriver/ directory, so end to end tests are driven through a real browser. The website is built with Eleventy, eleventy.config.mjs, and the source lives in website-src/ with the output in website/. There is a support/ directory holding the watch and production scripts, a .browserslistrc, a .nvmrc, an .npmrc and a VERSION file, and the macOS build has entitlements.plist files for the app and for inheritance. ## The interface: dashboard, container actions, image building and a connection manager The screenshots in the README are the feature list, and they are arranged around four areas. There is a dashboard, shown in both a unified version and a Podman version, with the Podman one labelled as the driving engine view. There is a containers management view with container actions. There is an image building view with image actions. And there is the connection manager under the multiple engines and remote connections heading. The word unified appears in the screenshot file names for the dashboard and the container actions, which suggests a design where the same view renders for more than one engine with the engine-specific differences expressed in the theme and the data rather than in separate screens. The dynamic engine based theme is the mechanism, and the tray icon staging in the build script is its most visible trace. ## Conclusion Container Desktop suits a developer or support engineer who works with Podman and wants a graphical interface for containers, images and connections, and who wants the same application on Linux, Windows and macOS. It is the wrong choice if you need Podman Desktop itself, since this is explicitly a companion project rather than a fork, and a poor fit if your containers run on a remote host only, because a remote connection is a feature here rather than the primary mode. Before adopting it, read docs/architecture/engine-matrix.md and docs/architecture/overview.md, because the project ships a written architecture and an engine matrix, and check the platform requirements in the README, since Windows needs Podman, or a custom WSL distribution where the engine's system dial-stdio bridges the unix socket back, and macOS needs Podman or Lima. ## FAQ ### What is Container Desktop? It is a Podman desktop companion, a desktop application for managing containers and images with Podman as the driving engine. The project states three author notes: no telemetry, an identical UI on all platforms, and a dynamic engine based theme. The homepage is container-desktop.com and the licence is MIT. ### Does Container Desktop support Docker and remote engines? Yes. The README has separate sections for Podman as the driving engine and for multiple engines and remote connections, with a Docker engine connections screenshot. On Linux the README says the easiest way to add Docker support is to install rootless Docker, and the documentation includes a dedicated engine matrix page. ### What are the requirements for running Container Desktop on Windows and macOS? On Windows you install Podman or provision a WSL distribution with the latest Podman, and the engine's own system dial-stdio bridges its unix socket back to the Windows native context over wsl.exe stdio, with no TCP listener or SSH server. On macOS you install Podman or Lima. On Linux you install Podman, and packages such as aardvark-dns and passt may be needed for networking. ### Which desktop shells does Container Desktop build for? The repository contains src-tauri/, src-wails/ and the Electron sources, with separate Vite configs for the main, preload and renderer processes, and scripts for tauri dev, tauri build and wails3. The tray icons are staged for the docker, podman and unified variants in light and dark. ### How does the Container Desktop release process work? The Makefile has a trigger-cd-pipeline target that reads the VERSION file and runs the CDPipeline.Tauri.yml GitHub workflow with the version as the git-ref, a production stage and publish-release set to true. The release target keeps the docs, static site, screenshots and demo videos in sync inside the release commit. ## Sources - [iongion/container-desktop on GitHub](https://github.com/iongion/container-desktop) - [License: MIT](https://github.com/iongion/container-desktop/blob/main/LICENSE) - [Project website](https://container-desktop.com/) - [README](https://github.com/iongion/container-desktop/blob/main/README.md) - [Releases](https://github.com/iongion/container-desktop/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/iongion-container-desktop