Skip to main content
Software Engineering Daily

Podman with Brent Baude

43 min episode · 2 min read
·
Brent Baude

Episode

43 min

Read time

2 min

Topics

Design & UX, Software Development, Product & Tech Trends

AI-Generated Summary

Key Takeaways

  • Daemonless Architecture: Podman eliminates the daemon process, using ConMon (a small C program) to monitor containers instead. This frees resources when containers aren't running, reduces attack vectors, and prevents catastrophic failures where one daemon crash affects all containers.
  • Rootless Container Execution: Containers run with unprivileged user permissions by default, leveraging Linux kernel security features to minimize damage from container escapes. Even if attackers breach a container, they lack root privileges on the host system, significantly reducing the attack surface.
  • Docker Migration Path: Existing Docker Compose files work directly with Podman through socket-activated systemd services that provide REST API compatibility. Users can type "podman compose" instead of "docker-compose" without modifying scripts, enabling seamless transitions between runtimes.
  • Kubernetes YAML Generation: Podman generates Kubernetes YAML from running containers, allowing developers to prototype locally, snapshot configurations, and deploy to Kubernetes orchestrators. This bridges single-node development and production-scale deployment without rewriting infrastructure definitions.

What It Covers

Brent Baude, Red Hat architect, explains Podman's daemonless container architecture, rootless security model, OCI compliance, and how it differs from Docker while maintaining compatibility with Docker Compose and Kubernetes workflows for developers.

Key Questions Answered

  • Daemonless Architecture: Podman eliminates the daemon process, using ConMon (a small C program) to monitor containers instead. This frees resources when containers aren't running, reduces attack vectors, and prevents catastrophic failures where one daemon crash affects all containers.
  • Rootless Container Execution: Containers run with unprivileged user permissions by default, leveraging Linux kernel security features to minimize damage from container escapes. Even if attackers breach a container, they lack root privileges on the host system, significantly reducing the attack surface.
  • Docker Migration Path: Existing Docker Compose files work directly with Podman through socket-activated systemd services that provide REST API compatibility. Users can type "podman compose" instead of "docker-compose" without modifying scripts, enabling seamless transitions between runtimes.
  • Kubernetes YAML Generation: Podman generates Kubernetes YAML from running containers, allowing developers to prototype locally, snapshot configurations, and deploy to Kubernetes orchestrators. This bridges single-node development and production-scale deployment without rewriting infrastructure definitions.

Notable Moment

Podman started as a small debugging utility called k-pod within the Cryo project before evolving into a standalone container runtime. The team initially viewed it as a library (LipPod) before recognizing its potential as a full Docker alternative.

Know someone who'd find this useful?

Episode Transcript

Podman is an open source container management tool that allows developers to build, run, and manage containers. Unlike Docker, it supports rootless containers for improved security and is fully compatible with standards from the Open Container Initiative or OCI. Brent Boddy is a senior principal software engineer at Red Hat, where he works on Podman. In this episode, Brent joins the show to talk about the project. This episode of Software Engineering Daily is hosted by Jordi Mon Companies. Check the show notes for more information on Jordi's work and where to find him. Hi, Brent. Welcome to Software Engineering Daily. Yeah. Welcome. I appreciate that. So what did you introduce yourself? Yeah. My name is Brent Boudy, and I currently work for Red Hat as the architect of Podman. And been with Red Hat about eleven years. Prior to that, I was with IBM for seventeen and change, and I'm located in United States in the great state of Minnesota. Beautiful state. So we're here to talk about Podman as you mentioned in your part of your title, but there is a GitHub containers organization, github.com/containers that contains, no pun intended there, a few projects, and you probably don't maintain and certainly are not the architect of the others. But can you give us a sense of what is the overarching theme of all the projects hosted within the containersorg? The obvious answer here is they have something to do with containers. Many of them are maybe library oriented that are brought into larger applications that you might know, but you might not know the libraries. We do prefer some affiliation with OCI and OCI standards, And there's certainly outliers on those kinds of ideas, but that's the general theme throughout. Container related, OCI related, and either they're gonna be small applications or libraries that build up much larger applications. What is the Open Container Initiative like? Could you describe what the standards there what is the difference without it? What came before maybe? And what did it come about? The OCI standards give us a road map, if you will, or or a skeleton in which we can program and be able to have a standard that will work, for example, with an application like Podman, but also could work with Crayo, which is another one of those projects in the containers area that we handle containers and images in particular in the same manner. Yeah. Is it a way of making container images agnostic of the container run time, right, of the multiple and As long as we follow the standard, of course. Yeah. Exactly. So the grunt of the work is on the container run times project maintainers like yourself. Yep. So how does Portman fit into this containers org? Like, is it the central project, or what is it? It's certainly the most active and popular. I believe that it's actually one of the more popular in GitHub, period. But, yeah, Podman fits into that …

Get the full transcript (6,920 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Software Engineering Daily transcripts →

You just read a 3-minute summary of a 40-minute episode.

Get Software Engineering Daily summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Keep Reading

Books, tools, and gear mentioned in this episode

SignalCast may earn commission on purchases via these links.

Tools

  • Podman generates Kubernetes YAML from running containers, allowing developers to prototype locally, snapshot configurations, and deploy to Kubernetes orchestrators.
  • by Red Hat

    Brent Baude, Red Hat architect, explains Podman's daemonless container architecture, rootless security model, OCI compliance, and how it differs from Docker while maintaining compatibility with Docker Compose and Kubernetes workflows for developers.
  • Existing Docker Compose files work directly with Podman through socket-activated systemd services that provide REST API compatibility. Users can type 'podman compose' instead of 'docker-compose' without modifying scripts.
  • how it differs from Docker while maintaining compatibility with Docker Compose and Kubernetes workflows for developers.

More from Software Engineering Daily

We summarize every new episode. Want them in your inbox?

Similar Episodes

Related episodes from other podcasts

Explore Related Topics

This podcast is featured in Best Cybersecurity Podcasts (2026) — ranked and reviewed with AI summaries.

Read this week's Software Engineering Podcast Insights — cross-podcast analysis updated weekly.

You're clearly into Software Engineering Daily.

Every Monday, we deliver AI summaries of the latest episodes from Software Engineering Daily and 192+ other podcasts. Free for one show.

Start My Monday Digest

No credit card · Unsubscribe anytime