Podman Desktop 1.2 makes the Podman 6 migration an explicit desktop workflow

Red Hat build of Podman Desktop 1.2 adds full Podman 6 support, a graphical secrets workflow, automatic import of trusted host certificates and in-application updates. The release is a meaningful developer-workstation change because it brings several operations that previously required command-line or manual maintenance into the desktop interface—and because upgrading from Podman 5 can require cleanup of local state.

What changed

The 1.2 release can download and update the local Podman engine to Podman 6. Red Hat highlights the new engine’s CLI, security, host-to-VM integration, AMD GPU support and Quadlet improvements, but the desktop-specific work is most visible around secrets and enterprise network configuration.

A new Secrets panel lists local Docker and Podman secrets and allows developers to create, inspect or delete them. The container-creation screen can inject an existing secret either as an environment variable or as a mounted file. Extension authors can also expose secret management for custom providers through the Podman Desktop API when the provider implements the Docker secrets endpoint.

The release also automates a common corporate-network problem. When creating a Podman 6 machine, Podman Desktop enables an option to import trusted host certificate-authority certificates into the virtual machine. It invokes Podman’s --import-native-ca support during machine startup, replacing the post-creation synchronization scripts previously needed behind TLS-inspecting proxies or private registries.

In-app updating rounds out the maintenance changes. The application checks for Red Hat builds in the background, surfaces notifications in the dashboard and native operating-system interface, and lets users review release notes and security advisories before triggering the update.

The migration caveat

The move from Podman 5 to Podman 6 is not presented as an in-place engine swap. Red Hat tells users to stop active machines first. Windows users running Hyper-V rather than WSL must run podman machine reset to remove old engine state.

Podman Desktop then detects the major-version transition and offers a cleanup flow that removes outdated Podman 5 containers, networks, volumes and machine definitions before the user creates a fresh Podman 6 virtual machine. Developers with important local volumes or reproducibility gaps should inventory and preserve what they need before accepting that cleanup.

Who should act

Developer-platform teams that distribute Red Hat’s Podman Desktop build should test three paths before broad deployment: Podman 5 state migration, corporate CA import and secret injection into representative containers. The automatic CA path can eliminate a recurring onboarding failure, while the secrets panel gives developers a less error-prone alternative to copying credentials into ad hoc command lines.

The release also shifts part of workstation lifecycle management into the application itself. Teams that centrally package developer tools should decide whether in-app updates fit their change-control model and document which update path takes precedence.

For individual developers, the practical advice is simpler: treat the Podman 6 migration as a rebuild of the local machine environment, not a routine point update. Once that boundary is understood, version 1.2 reduces several sources of setup friction that are especially common on managed enterprise laptops.