Today, we're thrilled to announce our application for Podman Desktop to join the Cloud Native Computing Foundation (CNCF) as a Sandbox project.This is a huge milestone for our project and our community, and we're incredibly excited for what the future holds.

About Podman Desktop​

Podman Desktop builds upon the innovations brought by Podman, offering a powerful yet user-friendly environment for containerized development. Podman provides a daemonless, rootless container engine that enhances security and flexibility, while Podman Desktop delivers an intuitive graphical interface for managing containers and interacting with Kubernetes. Enhanced by a plug-in system that allows developers to customize their inner loop container workflows to their needs and offers flexible extension points for other projects as well as other container engines.

Why the CNCF?​

The CNCF is a vital organization for the cloud-native world, supporting collaboration and driving innovation for critical projects like Kubernetes, Prometheus, and Envoy. As a CNCF project, Podman Desktop will benefit from increased visibility, a neutral home for open governance, and access to a wealth of resources and expertise. CNCF projects will take a renewed interest in collaborating with us. This move will help us grow our community, ensure the project's long-term sustainability, and accelerate its development.

How Podman Desktop simplifies containers and Kubernetes​

Developing with containers can be complex. Podman Desktop simplifies this by providing an intuitive interface and powerful tools for building, managing, and running containers. This allows developers to focus on writing code, not wrestling with infrastructure. Why is this important? Because in today's complex world, developer productivity is paramount. By removing friction and simplifying workflows, Podman Desktop empowers developers to deliver value faster. Podman Desktop enables developers to run Kubernetes locally, mirroring their production environment. This eliminates the "works on my machine" problem and allows for early detection of configuration issues. By closing the gap between development and production, Podman Desktop reduces deployment risks and accelerates the feedback loop. This leads to higher quality software and faster release cycles.

Open source and the CNCF: A perfect match for developer tools​

We believe in the power of open source. Open source software fosters transparency, encourages collaboration, and drives innovation. By donating Podman Desktop to the CNCF, we're ensuring it remains open and accessible to all, fostering a vibrant community around it. The CNCF is the perfect home for Podman Desktop because it champions open source values and provides a neutral ground for collaborative development. This ensures that Podman Desktop remains vendor-neutral and driven by the needs of its users, keeping options open and avoiding vendor lock-in.

Furthermore, while the CNCF has fostered incredible innovation and many developers profit from the number of projects available through the CNCF, there's a recognized need for more developer-focused tooling. Podman Desktop fills this gap perfectly by providing a developer-centric, streamlined, and intuitive experience for containerizing, managing, and deploying cloud-native applications. Podman Desktop has a natural affinity to Kubernetes due to its design and features that seamlessly bridge the gap between local container development and Kubernetes deployments. This close relationship aligns perfectly with the CNCF's mission to drive the adoption of cloud-native technologies.

Join the growing Podman Desktop community​

As a CNCF project, we have the opportunity to open our doors to a wider community of contributors and users. We believe that open source thrives on collaboration and diverse perspectives. By broadening our contributor base, we can accelerate innovation, improve the quality of Podman Desktop, and ensure it meets the needs of a diverse range of users.

You can contribute in various ways:​

• Reporting issues: If you encounter bugs or have suggestions for improvements, you can report them on the GitHub issue tracker. Be sure to provide detailed information and steps to reproduce the issue.

• Working on issues: You can browse the issue tracker and contribute by fixing bugs or implementing new features. This involves forking the repository, making changes, and submitting pull requests.

• Contributing code: Beyond addressing existing issues, you can propose and contribute entirely new features or enhancements to Podman Desktop's functionality, user interface, or integrations with other tools. Learn more about how to contribute.

• Contributing plug-ins: Feel like there is an integration missing? You can contribute your own plug-in functionality for Podman Desktop. Check out the guide.

• Improving documentation: Clear and comprehensive documentation is essential. You can contribute by improving existing documentation, adding new guides, or creating tutorials.

• Providing website contributions: The Podman Desktop website is also open source. You can contribute to its content, design, or translations.

• Becoming an Adopter: If you are a happy user, we’d love to know and share the word. Consider adding yourself or your organization to the list of adopters with a pull request.

Before you start contributing, it's helpful to familiarize yourself with the project's contribution guidelines and code architecture. These resources provide valuable information on coding style, testing procedures, and the overall development process. You can also join #podman-desktop on the Kubernetes Slack to connect with other contributors and get help.

KubeCon 2024 and beyond​

We are at KubeCon NA 2024 in Salt Lake, to officially announce this exciting news and share more about Podman Desktop and our roadmap. Stop by the Red Hat booth to say hello, contribute to the project, and help us shape the future of cloud-native development.

Get involved and learn more​

We're incredibly excited about this new chapter for Podman Desktop and can't wait to see what we can achieve together with the CNCF community.

• Visit our website: https://podman-desktop.io/

• Join our community: #podman-desktop on the Kubernetes Slack

• Contribute to the project: https://github.com/podman-desktop/podman-desktop/

• Read 10 Reasons Why Developers Should Consider Podman Desktop

If you're unfamiliar with BootC, it offers an impressive method for deploying applications directly to bare metal from either a single Containerfile or a pre-existing bootc-supported image.

A "bootable" image, known as a BootC container image, allows you to use a simple container image to create a full bootable operating system, whether it's a raw virtual machine image or an iso for USB installation!

This capability is ideal for a variety of uses, from a simple HTTP server to an OS powering a full-stack application.

In this tutorial, we'll deploy an OpenShift derivative called MicroShift, an edge-optimized version of OpenShift designed for single-node setups on resource-constrained configurations. Think of it as a compact version of OpenShift!

This entire process is carried out using a single Containerfile (or Dockerfile).

Requirements​

Before starting the tutorial, ensure you have:

• An active Red Hat account in order to access RHEL-based images
• Access to an OpenShift Hybrid Cloud pull secret
• Podman Desktop installed
• Podman Desktop BootC Extension
• Your preferred VM-running software (e.g., using libvirt)

Building the BootC container image​

First, we'll build the initial BootC container image from which we'll later create a bootable OS.

Logging into Red Hat registry​

Before proceeding, download the Red Hat Authentication extension from the catalog to enable access to Red Hat registries:

Then log into your account:

Download your OpenShift Hybrid Cloud pull secret​

Download your pull secret.

This is downloaded as pull-secret.txt. Put it in a secure location.

Creating the Containerfile (or Dockerfile)​

The Containerfile is crucial for creating the bootable image.

It's important to note that we will be providing one argument during the build and that is the PASSWORD in order to access the Virtual Machine that will be logged in via the redhat username.

We will be using the Containerfile from the MicroShift image mode GitHub documentation.

Copy the Containerfile from the above link to a new file which we will be building with Podman Desktop:

$ curl https://raw.githubusercontent.com/openshift/microshift/main/docs/config/Containerfile.bootc-rhel9 -o Containerfile

Build with Podman Desktop​

Select the Containerfile and build it within Podman Desktop.

You will need to provide:

• A password for the redhat user that will be created in the Containerfile.

Pass the argument as USER_PASSWD in the build page arguments.

Build the bootable image with BootC Podman Desktop extension​

Install​

Install the BootC Podman Desktop extension from the extensions catalog:

Build the image​

Now, create the bootable image from our container image!

Click the new BootC icon on the navigation bar and go to build:

Once the build is complete, you'll see a confirmation on the dashboard.

Next, select the image we built and choose an appropriate output format for testing the bootable image. RAW is a common choice for local testing with QEMU and other VM software like libvirt.

Testing the image​

Explore various ways to test your image, using local software or cloud platforms. Here are some common steps for using the RAW output bootable image.

Running the Virtual Machine​

This guide doesn't cover all methods for running a virtual machine, but here are the most common:

$ brew install qemu

$ cd ~/output

$  qemu-system-aarch64 \
    -m 8G \
    -M virt \
    -accel hvf \
    -cpu host \
    -smp 4 \
    -serial mon:stdio \
    -nographic \
    -netdev user,id=mynet0,hostfwd=tcp::2222-:22 \
    -device e1000,netdev=mynet0 \
    -drive file=/opt/homebrew/share/qemu/edk2-aarch64-code.fd,format=raw,if=pflash,readonly=on \
    -drive file=disk.raw,if=virtio,cache=writethrough,format=raw

$ ssh redhat@localhost -p 2222

$ cd ~/output

$ qemu-system-x86_64 \
    -m 8G \
    -cpu Broadwell-v4 \
    -nographic \
    -netdev user,id=mynet0,hostfwd=tcp::2222-:22 \
    -device e1000,netdev=mynet0 \
    -snapshot disk.raw

$ ssh redhat@localhost -p 2222

Configuring and verifying MicroShift​

After you boot your virtual machine, you can now configure MicroShift as well as verify the connection.

Copying over the OpenShift pull secret​

Before proceeding with verifying OpenShift, the OpenShift pull secret must be copied over so that MicroShift can download Red Hat registry-authenticated container images.

Below we will copy the OpenShift secret you had previously downloaded to the virtual machine.

1. Download your OpenShift pull secret which is downloaded as pull-secret.txt

2. Use scp to copy over to the virtual machine:

$ scp -P 2222 pull-secret.txt redhat@localhost:~/

3. SSH into the VM:

$ ssh redhat@localhost -p 2222

4. Move the secret to /etc/crio/openshift-pull-secret:

$ sudo mv pull-secret.txt /etc/crio/openshift-pull-secret

5. Restart the microshift service:

$ sudo systemctl restart microshift

Listing pods​

Below we will SSH into the virtual machine and confirm that MicroShift is deploying Pods correctly:

1. SSH into the VM:

$ ssh redhat@localhost -p 2222

2. Copy the generated kubeconfig file to ~/.kube/config:

$ mkdir -p ~/.kube
$ sudo cp /var/lib/microshift/resources/kubeadmin/kubeconfig ~/.kube/config
$ sudo chown redhat ~/.kube/config

3. Verify Pods are running by using oc or kubectl:

$ kubectl get pods -A
NAMESPACE                  NAME                                       READY   STATUS    RESTARTS   AGE
kube-system                csi-snapshot-controller-856bb8b9bc-9n7lj   1/1     Running   1          3d23h
kube-system                csi-snapshot-webhook-7c64d4d4d7-98v6l      1/1     Running   1          3d23h
openshift-dns              dns-default-n2td4                          2/2     Running   2          3d23h
openshift-dns              node-resolver-7cslg                        1/1     Running   1          3d23h
openshift-ingress          router-default-7cbc67954b-nqqc6            1/1     Running   1          3d23h
openshift-ovn-kubernetes   ovnkube-master-zcqw5                       4/4     Running   5          3d23h
openshift-ovn-kubernetes   ovnkube-node-crnn9                         1/1     Running   2          3d23h
openshift-service-ca       service-ca-6799f567-k7lsc                  1/1     Running   1          3d23h

Using Podman Desktop to verify MicroShift​

Alternatively, you can copy the MicroShift configuration file to your local machine and test it remotely on Podman Desktop.

1. On your local machine, create the .kube directory if it does not exist already:

$ mkdir ~/.kube

2. Copy the remote kubeconfig file to a local configuration file:

Within MicroShift, a kubeconfig file is automatically created at /var/lib/microshift/resources/kubeadmin/kubeconfig.

Copy the file over to your local system:

scp -P 2222 redhat@localhost:/var/lib/microshift/resources/kubeadmin/kubeconfig ~/config

If you already have a ~/.kube/config, copy the contents of config to the ~/.kube/config file.

3. Use Podman Desktop to verify the MicroShift cluster:

Podman Desktop will automatically detect your .kube/config file.

Note: You may need to modify your .kube/config file to reflect the correct domain or IP address of your cluster.

Storage configuration​

By default, storage configuration requires an LVM partition and LVMS storage manager will not be deployed. This is due to a limitation when building a RAW image. An alternative non-local storage solution is required to use OpenShift artifacts with storage capabilities. The feature to add LVM support is tracked in this pull request.

Conclusion​

This tutorial provided a step-by-step guide on deploying a bootable MicroShift image using Podman Desktop and the BootC extension. By leveraging tools such as BootC and Podman, we've streamlined the process of creating a lightweight, yet fully functional, OpenShift environment suitable for single-node edge computing scenarios.

Thank you for following along, and happy deploying!

Extensions are a powerful tool to customize and extend the functionality of Podman Desktop. Whether you want to add new container management features, streamline current workflows, or create custom UI elements specific to your tech stack, building extensions allows you to tailor the Podman Desktop experience to your specific needs.

In this guide, we'll introduce how you can build your own Podman Desktop extension, with links to detailed documentation that covers each part of the process.

Introduction to extensions​

Extensions are abundant in Podman Desktop and can be found in the Extensions -> Catalog section.

Each extension expands on Podman Desktop, such as providing Kubernetes development clusters with Minikube or even analyzing your image layers.

Below is an example of the layers explorer extension and how it integrates into Podman Desktop:

Getting started with your project​

The first step in creating your extension is setting up the project environment. To learn how to configure the project and add basic components, check out the Templates for creating an extension guide, which walks you through initializing your project from an official template.

Adding UI components​

One of the most common tasks when creating an extension is adding a user interface. Whether it’s adding buttons, panels, or icons, UI components help make your extension more interactive and accessible. Adding a UI component is totally optional and an extension can be ran without UI components. Learn more about this in the Adding UI components documentation, where you’ll find instructions on creating and integrating components into the application’s UI.

Working with icons​

Icons are a great way to make your extension more visually unique. You can learn how to add and style custom icons by following the Adding icons documentation.

Below is an example of how the bootc extension added icons to the image list within Podman Desktop:

Menus and navigation​

Extensions often integrate with existing menus and navigation to offer users easy access to new commands and features. If you want to add items to the context menu, explore the Menu configuration documentation, which explains how to add commands to menus and control when they are displayed using When Clauses.

Below is an example of how the bootc extension added a new menu command to image list:

Adding and configuring commands​

Commands are the backbone of most extensions, allowing users to interact with the application and trigger specific actions.

If you need to define and register custom commands, the Commands guide will show you how to create commands that respond to user actions or input, and tie them into your extension’s workflow.

You can also configure these commands to appear in different contexts. Check out the When clause Contexts documentation to learn more about restricting commands to specific scenarios.

Commands are heavily influenced by VS Code commands and can be configured similarly. See our commands guide for more information.

Setting up onboarding workflows​

Creating a smooth onboarding experience is essential to help users get started with your extension. This includes steps for CLI binary installations or other initial setup values.

You can provide guidance, tutorials, or initial setup steps using the Onboarding workflow guide.

Below is an example of how the built-in compose extension adds onboarding for the compose CLI binary installation:

Configuration settings​

Once you’ve built your components and commands, you may want to setup configuration settings for advanced usage of your extension.

The Configuration documentation outlines the configuration file structure and how to link everything together to use user-specific values.

Publishing your extension​

Publishing enables users to install your extension, you can compile your extension into a container image for users to easily consume. Follow the Publishing guide to learn how to distribute your extension.

Conclusion​

Creating an extension opens up endless possibilities to customize Podman Desktop to your specific needs.

It is also easy to package and publish your extension for others to use.

Have fun exploring our documentation on how to create an extension and happy coding!

Podman Desktop 1.13 Release! 🎉

Podman Desktop 1.13 is now available. Click here to download it!

This release includes:

• Hyper-V support: You can now create and manage Hyper-V Podman machines directly from Podman Desktop.
• Search image feature: Search for an image from Podman Desktop.
• Updated empty state pages: Start your journey in the containers, images, pods, and Kubernetes pages with a click of a button
• New Kubernetes navigation: All Kubernetes related pages have been moved to a separate sub menu for easier and less crowded navigation.
• Image Layer explorer extension: With this new extension, you can explore the various layers of images.
• Experimental Docker compatibility mode page: You can now try out our experimental Docker compatibility mode page.

The integration of Podman Desktop with Kubernetes helps you to run your application on a Kubernetes cluster, such as Kind or Minikube.

This blog covers the following aspects:

• Build a containerized application from registry images
• Create a pod
• Set up a local Kubernetes cluster
• Deploy the application to Kubernetes
• Verify the running service

Building a containerized application​

With this blog, you will build a containerized application that uses:

• a back-end Redis server container
• a front-end Python application container

To do so, you can pull the relevant images from the quay.io registry.

1. Go to the Images component page.

2. Click Pull.

3. Start the first container:

   1. Enter the image name to pull from a registry. For example, quay.io/podman-desktop-demo/podify-demo-backend.
   2. Click Pull image. A download complete notification opens.
   3. Click Done.
   4. Click the Run Image icon corresponding to the new image added.
   5. Enter the container name redis-server.
   6. Click Start Container.
   7. Click the Logs tab to view that the Redis server is running in standalone mode.

4. Start the second container:

   1. Enter the image name to pull from a registry. For example, quay.io/podman-desktop-demo/podify-demo-frontend.

   2. Click Pull image and then Done.

   3. Click the Run Image icon corresponding to the new image added.

   4. Enter the container name python-app.

      note

      If the default port is already in use, you can specify a different port in the Port mapping field.

   5. Select the Networking tab and enter hostname as redis-server and IP address as 10.88.0.2 to enable communication with the Redis server.

      note

      You can find the IP address in the Inspect tab of the redis-server Container Details page.

   6. Click Start Container.

   7. Click the Logs tab to view that the application is running on port 5000.

   8. Click the Open browser icon on the right side of the page.

   9. View the running front-end application.

Creating a pod​

You can use both the containers to create a pod. This way both the front-end and back end container applications can share resources, such as storage and network.

Pod creation with existing containers

1. Go to the Containers page.
2. Select both the front-end and back-end containers.
3. Click the Create Pod button.
4. Click Create Pod.
5. View the newly created pod on the Pods page.
6. Click the name of the pod and then click the Summary tab to view its summary.

Alternative: Pod creation with Kubernetes YAML

You can generate a Kubernetes manifest for any existing pod or container and use it to create a local Kubernetes YAML file. Then, you can customize that file and create a pod from it.

At the time of pod creation, you can select a runtime to indicate whether you want to run the pod on a Podman engine or a Kubernetes cluster. Based on the selection, you get to see the newly created pod running in that environment on the Pods component page.

The following procedure creates a pod that runs on a Podman engine.

1. Go to the Pods page.
2. Click the overflow menu icon corresponding to the pod.
3. Select the Generate Kube option from the dropdown list.
4. View the Kubernetes YAML configuration in the Kube tab.
5. Copy the configuration and paste it into a YAML file on your machine.
6. Edit the YAML configuration and save it.
7. Go to the Pods component page.
8. Click Play Kubernetes YAML.
9. Select the YAML file from your machine.
10. Check that the Runtime field is set to Podman container engine.
11. Click Play and then Done.
12. View the newly created pod on the same page.

After creating the pod, set up a local Kubernetes cluster to deploy the pod.

Setting up a local Kubernetes cluster​

You can set up a local Kubernetes cluster. Once the cluster is connected and running, you can deploy your application on it.

Based on your preference, use the Kind or Minikube extension:

1. Install the extension from the Extensions catalog.
2. Create a Kubernetes cluster. See Kind cluster creation or Minikube cluster creation.

Once a kubernetes cluster is created, you can view a running control plane node and a running Kubernetes service on the Kubernetes component page. The page also shows that the cluster is connected.

Deploying the application to Kubernetes​

You can deploy the application pod to a Kubernetes cluster that has an active connection and access it through a service. Also, any container that is part of a pod is deployable to a Kubernetes cluster.

1. Select your Kubernetes context.

2. Go to the Pods component page.

3. Click the overflow menu icon corresponding to the pod.

4. Select the Deploy to Kubernetes option from the dropdown list.

5. Select the checkbox to expose the service locally using the ingress controller.

   note

   When you configure custom port mapping while running an image, you get the option to select an Ingress host port from the dropdown list. Otherwise, you do not see the option.

6. Click Deploy and then Done.

Verifying the running service​

1. Go the Kubernetes component page.

2. Perform the following steps:

   1. Click the Services option to view the newly created service, my-pod-5000.
   2. Click the Ingresses and Routes option to view the newly created ingress, my-pod.
   note

   Use the Apply YAML button to directly apply a Kubernetes YAML file to create a resource.

Podman Desktop 1.12 Release! 🎉

Podman Desktop 1.12 is now available. Click here to download it!

This release includes:

• Podman remote: We now support remote Podman setups! Manage your remote Podman machines all within the UI.
• macOS GPU support: Container GPU access on macOS is now available. libkrun is now a selectable provider type to allow GPU passthrough enablement.
• Windows GPU support: Want to try out Windows GPU support too? Podman already supports it, but we are now showcasing it in our AI Lab extension
• Podman 5.2.0: This new version of Podman provides GPU access for macOS, as well as a host of new features.
• Light mode out of experimental: Our light mode has been well-received, and we have now marked it as non-experimental! Enjoy the new theme.
• Kubernetes features: ConfigMaps, Secrets and multi-file Kubernetes YAML applying have now been added to our Kubernetes dashboard.
• Improved font consistency: You'll notice a big difference in consistency this release, as we updated all font sizes throughout Podman Desktop.

Red Hat provides a tool called Image Builder that allows developers to build their own custom image of RHEL in a variety of formats. Recently, Image Builder added WSL as a target, enabling you to run RHEL on Windows as a WSL distribution.

This article details the steps and actions required to build and run your RHEL WSL image.

The purpose of this article is to describe the options needed for the RHEL WSL distribution so that it can be used as a Podman machine.

To use the RHEL WSL image as a Podman machine, ensure that the following packages are installed:

• podman
• podman-docker
• procps-ng
• openssh-server
• net-tools
• iproute
• dhcp-client
• sudo
• systemd-networkd

Luckily, all but the last package are available from the pre-configured RHEL 9 repositories. The last package (systemd-networkd) is available from the EPEL 9 repository and will need to be configured when building the image.

Build the image

Navigate to image builder

On the upper right menu, enable the Preview mode.

Click Add blueprint to open the Create image dialog wizard.

On the Image output page, select the following:

• From the Release list, select Red Hat Enterprise Linux (RHEL) 9.
• From the Select target environments option, select WSL - Windows Subsystem for Linux (.tar.gz).
• Click Next.

On the Register page, select Automatically register and enable advanced capabilities.

• From the dropdown menu, choose an activation key to use for the image. See Creating an activation key.
• Click Next.

On the OpenSCAP page, as it is not supported for WSL images, click Next.

On the File system configuration page, select Recommended: Use automatic partitioning.

• Click Next.

On the Content page, complete the following steps to add additional packages to your image:

• On the Repository snapshot step:

  • Select Use latest content.
  • Click Next.

• On the Custom repositories step:

Click on the Create and manage repositories here link. This will open a new tab

Click Add repositories now

Click Add repositories

On the Add custom repositories page, select the following:

• In the Name list, enter EPEL 9.
• In the URL field, enter https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/
• In the GPG key field, enter https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-9
• Click Save.

Close the tab and switch back to the previous one

• In the filter input field, type EPEL
• Select the EPEL 9 repository

Click Next

• On the Additional packages step:

  • On the Available packages search field, enter podman and click the → button.
  • Select the podman and podman-docker packages.
  • On the Available packages search field, enter procps-ng and click the → button.
  • Select the procps-ng package.
  • On the Available packages search field, enter openssh-server and click the → button.
  • Select the openssh-server package.
  • On the Available packages search field, enter net-tools and click the → button.
  • Select the net-tools package.
  • On the Available packages search field, enter iproute and click the → button.
  • Select the iproute package.
  • On the Available packages search field, enter dhcp-client and click the → button.
  • Select the dhcp-client package.
  • On the Available packages search field, enter sudo and click the → button.
  • Select the sudo package and click the > button to add the selected package shown in the package search results to the Chosen packages dual list box.
  • On the Available packages search field, enter systemd and click the → button.
  • Select the systemd-networkd package.
  • Click Next

On the First boot script configuration page:

• Click Next.

On the Details page:

• In the Blueprint name, enter rhel-wsl.
• Click Next.

On the Review page:

• Click Create blueprint and build image.

The image is being built. Once the build is finished, the download link will be available. Click on the Download (.tar.gz) link and save the downloaded file to one of your local folders.

Create the RHEL WSL podman machine

Launch Podman Desktop and go to the Settings -> Resources page:

On the Podman provider, click on Create new ...

On the Create Podman machine page, click the Browse button for the Image Path field and select the file downloaded from Image Builder.

Click on the Create button: the machine will be created and started. After a short time, the operation status should be reported.

Let's play with the RHEL WSL podman machine

Go to the Images page and pull the httpd image

Click on Done

Start the image by clicking on the Run image icon

Once the container is started, the Apache server can be accessed on http://localhost:9000

Podman Desktop 1.11 Release! 🎉

This release introduces:

• Experimental light mode!: Our most-requested feature is here! Try out our new experimental light mode in the settings.
• Rosetta support for Apple Silicon: Build AMD64 binaries near the same speed as ARM64 binaries.
• Kubernetes improvements: Check out our new Node and Volume pages for Kubernetes.
• Improved UI: In addition to our light mode, you'll notice updates to our container listing page.
• Increased manifest support: Images built as a manifest are now grouped together.

Podman Desktop 1.11 is now available. Click here to download it!

Podman Desktop 1.10 Release! 🎉

This release introduces:

• 1 Million Downloads!: Wow, we made it!
• Extension Catalog: Redesigned extensions page and catalog to get the most out of Podman Desktop.
• Podman 5: Podman 5.0.2 now recommended for all users.
• Multi-platform Builds: Build for multiple platforms at once.
• Extension API Improvements: Additional updates to the extension API used by 🦭 Podman Desktop's extensions.

Podman Desktop 1.10 is now available. Click here to download it!

Podman Desktop 1.9 Release! 🎉

This release introduces: 🦭 a splash of innovation, a wave of excitement, and an ocean of possibilities!

• Podman 5! Podman 5.0.1 for new users (and as an experimental upgrade for 4.x users).
• Podman 4.9.4: Podman 4.9.4 is now included in both Windows and macOS installers.
• Backup/Restore Images: Save images or containers to tar archives and restore them.
• Kubernetes Pods Terminal: Connect to a terminal within Kubernetes pods.
• Extension API Improvements: Additional updates to the extension API used by 🦭 Podman Desktop's extensions.

Podman Desktop 1.9 is now available. Click here to download it!

We’re honored to announce that Podman Desktop has been recognized with the prestigious 2024 DEVIES Award in the category of Containers & Kubernetes. This award is a testimony to the effectiveness of the Podman Desktop team and greater open-source community's efforts to help developers. Podman Desktop increases developer container workflow efficiency as well as provides an easy transition of applications from containers to Kubernetes, the leading open-source container orchestration platform.

“While Podman Desktop only went into general availability last year, the community response has been very impressive and incredibly gratifying. We are extremely proud to receive this outstanding recognition which celebrates passion, commitment and innovation for shaping the future of container development backed by the vibrant open-source standards that Red Hat supports. ” said Stévan Le Meur, Product Manager on the Podman Desktop team.

What are the DEVIES awards?​

The DEVIES Awards, presented by DeveloperWeek, recognize the most innovative and impactful tools, platforms, and technologies in the software development community. Podman Desktop's win as the best innovation in Containers & Kubernetes highlights its significant impact on the industry and its role in revolutionizing the way developers build, ship, and run their applications. DEVIES Award winners are selected from hundreds of nominees by the independent, industry-leading DevNetwork Advisory Board.

Join us in celebrating! ​

We’re excited to be receiving this award on stage at DeveloperWeek 2024, happening on February 21-23, 2024, in Oakland, CA and February 27-29, 2024 (Virtually). In addition, Red Hat developer advocate Cedric Clyburn will be presenting a session on Podman Desktop, titled “Going from Containers, to Pods, to Kubernetes – Help for Your Developer Environments!”, with a full presentation on Podman, a demonstration of the Podman Desktop experience, and a multi-tier application going from containers, to pods, to finally Kubernetes!

Finally, it would be seal-y to not include and acknowledge that this award was earned by the entire Podman Desktop community of contributors! We also thank the DevNetwork Advisory Board and DeveloperWeek for this honorable award, and for the opportunity to share Podman Desktop's innovations with the greater developer community.

As developers we constantly improve and refine our applications. One of the challenges we face is quickly iterating when working with container images and kubernetes deployments/pods.

For example, when we want to try a new image in a kubernetes pod, this image needs to be available on a private/public registry or on the nodes of the kubernetes cluster. Sometimes we need to call extra commands such as kind load docker-image or minikube cache add <image> or publish the image first to a 3rd party registry.

You'll agree that trying out a new image in a Kubernetes pod should be as seamless as building the image itself.

In this blog post, we will explore the best practice for streamlining the image iteration process in Kubernetes with Podman Desktop.