Podman Desktop can run containerized applications on your laptop without needing a separate virtual machine or daemon.

Imagine you’ve got a bunch of development tools or even entire applications that are usually run on servers. Instead of installing them directly on your Mac or Windows machine, potentially messing up your system with dependencies or conflicting versions, you can run them inside containers. Podman Desktop makes it easy to manage these containers right from your desktop environment.

Let’s see it in action. On my Mac, I’ve already installed Podman Desktop. I can search for an image, say docker.io/library/nginx:latest, and pull it down.

podman pull docker.io/library/nginx:latest

Then, I can start a container from that image, mapping port 8080 on my machine to port 80 inside the container.

podman run -d -p 8080:80 --name my-nginx nginx

Now, if I open my web browser and go to http://localhost:8080, I see the default Nginx welcome page.

Click to see Podman Desktop UI example

Podman Desktop UI showing Nginx container running

The magic here is that Podman on macOS and Windows doesn’t use a traditional, always-running daemon like Docker often does. Instead, it leverages the operating system’s native capabilities and, when needed, spins up minimal virtual machines (using qemu on macOS and WSL2 on Windows) to run the container engine. This means it’s more lightweight and integrates more seamlessly with your OS. When you’re not running containers, the underlying engine often isn’t consuming resources.

The core problem Podman Desktop solves is providing a consistent, local environment for developing and testing containerized applications across different operating systems. It abstracts away the complexities of setting up container runtimes, allowing developers to focus on their code. You can manage images, containers, volumes, and pods directly through a graphical interface or the command line, and it all works the same whether you’re on a Mac or a Windows machine.

The key levers you control are primarily through the Podman command-line interface (CLI) or the Podman Desktop GUI:

  • Images: You pull, build, and manage container images. Think of these as blueprints for your containers. podman pull alpine gets the alpine image; podman build -t my-app . builds an image from a Dockerfile.
  • Containers: You run, stop, start, and remove containers from images. podman run -it ubuntu bash starts an interactive Ubuntu container. podman ps lists running containers.
  • Volumes: These are used to persist data generated by and used by containers. If you stop and remove a container, its data in a volume can survive. podman volume create my-data creates a named volume.
  • Pods: (More advanced) A pod is a group of one or more containers that share the same network namespace and other resources. This is useful for co-located containers that need to communicate easily. podman pod create --name my-app-pod creates a pod.

When you install Podman Desktop, it installs the Podman CLI and sets up the necessary backend. On Windows, this typically involves enabling and configuring the Windows Subsystem for Linux 2 (WSL2). On macOS, it uses qemu to create a lightweight Linux VM that runs the Podman service. Podman Desktop then provides the GUI to interact with this backend. The commands you run locally are sent to this Podman service, which executes them and returns the results.

The most surprising thing about how Podman handles networking on macOS and Windows is that it doesn’t maintain a single, persistent virtual network interface for all containers by default. Instead, each container’s network is managed more dynamically, often using a separate virtual network for each Podman machine instance (the VM on macOS, or WSL distro on Windows), and then using NAT and port forwarding to expose container ports to your host machine. This means that while localhost mapping works for direct port exposure, direct container-to-container communication between different Podman machines or other network-aware services on your host might require more explicit network configuration or using Podman’s built-in networking features like Pods.

The next step you’ll likely explore is managing Kubernetes resources directly from Podman Desktop.

Want structured learning?

Take the full Podman course →