I first discovered Podman back in 2022. It was listed as one of the supported engines for Distrobox<\/strong>, a tool I was experimenting with at the time. Back then, I was a dedicated Docker user. While I was vaguely intrigued by Podman’s “daemonless” nature, I didn’t feel a pressing need to switch.<\/p>\n\n\n\n I subscribe to the philosophy: “If it works, don’t fix it.”<\/em> Docker was working for me or so I thought.<\/p>\n\n\n\n My perspective changed when I moved from building simple, small container images to complex, multi-layered ones. I began hitting friction points that turned my workflow into a headache, eventually forcing me to look for a better alternative. That alternative was Podman.<\/p>\n\n\n\n The cracks in my Docker workflow appeared during heavy build processes. I encountered a situation where a build failed because my disk reached capacity. In a perfect world, this should just stop the build.<\/p>\n\n\n\n However, with Docker, this triggered an unrecoverable state in the storage driver. Because Docker relies on a central daemon (a background process that manages everything), when that daemon struggles to write layers to a full disk, it can corrupt the state of the engine. I wasn’t just left with a failed build; I was left with a corrupted installation that required me to completely purge my Docker data and rebuild everything from scratch.<\/p>\n\n\n\n This highlighted a critical architectural flaw: The Single Point of Failure.<\/strong><\/p>\n\n\n\n If the Docker daemon crashes or corrupts, every container it manages goes down with it. It felt fragile.<\/p>\n\n\n\n This led me to seriously investigate Podman. The immediate “lifesaver” feature was its daemonless architecture<\/strong>.<\/p>\n\n\n\n Unlike Docker, which uses a client\u2013server model (the CLI talks to a long-running daemon), Podman works like a traditional Linux command (fork\/exec). When you run `podman build`, it is just a process running under your user.<\/p>\n\n\n\n In a native Linux environment, this performance is raw and direct. There is no middleman. Podman interacts directly with the kernel’s cgroups<\/strong> and namespaces<\/strong>, making it incredibly efficient for system resources.<\/p>\n\n\n\n You might be thinking, “This sounds great for Linux, but I use Windows.”<\/p>\n\n\n\n While both Docker and Podman utilize WSL2 (Windows Subsystem for Linux 2)<\/strong> to run containers on Windows, the way they package this experience is vastly different.<\/p>\n\n\n\n Docker Desktop on Windows bundles the WSL2 backend inside a heavy, commercialized application. It runs a resource-intensive GUI and background services that can eat up significant RAM even when idle.<\/p>\n\n\n\n Podman, on the other hand, offers a cleaner approach for Windows developers:<\/p>\n\n\n\n The end result: Windows stops feeling like a second-class citizen for containers, and your setup is much closer to a \u201creal Linux dev box\u201d with fewer moving parts.<\/p>\n\n\n\n One of my favorite use cases for containers is hosting Neko<\/strong>[1]<\/sup><\/a>, a virtual browser running inside a container. It\u2019s excellent for testing web applications or browsing potentially unsafe sites in an isolated environment.<\/p>\n\n\n\n In the Docker world, updating Neko was a chore:<\/p>\n\n\n\n If you manage a fleet of services, this becomes tedious very quickly.<\/p>\n\n\n\n Podman introduces a game-changer called Auto-Update<\/strong>. By integrating with `systemd`, I can simply run:<\/p>\n\n\n\n Podman checks if a new image is available, pulls it, restarts the container, and even supports automatic rollback<\/strong> if the new container fails to start. It turns a 10-minute maintenance task into a background process I don’t even have to think about.<\/p>\n\n\n\n This approach scales beautifully: from \u201cmy one Neko container\u201d up to a host running multiple services that all keep themselves up to date with minimal manual intervention.<\/p>\n\n\n\n Finally, we must talk about security. Docker has historically suffered from vulnerabilities related to its root-privileged daemon.<\/p>\n\n\n\n One illustrative example is CVE-2018-15664[2]<\/sup><\/a>. In affected versions of Docker, the API endpoints behind the `docker cp` command were vulnerable to a symlink race condition. A malicious process inside a container could:<\/p>\n\n\n\n In other words: the daemon was doing filesystem operations on the host on behalf of<\/em> a container, with full root privileges. That\u2019s exactly the kind of risk you accept when a central, highly-privileged daemon sits in the middle of everything.<\/p>\n\n\n\n Podman drastically reduces this category of risk through two mechanisms:<\/p>\n\n\n\n While Docker now supports “Rootless Mode,” it is often more complex to configure and not how most existing Docker installations are set up. Podman works rootless out of the box, which encourages safer defaults, especially on multi-user systems.<\/p>\n\n\n\n Technically, Podman interfaces directly with the Linux kernel’s cgroups<\/strong> and namespaces<\/strong>, adhering strictly to OCI (Open Container Initiative) standards. It uses the same low-level container runtimes (like `runc`) under the hood that Docker does, but without inserting a long-lived daemon into the middle.<\/p>\n\n\n\n The result is a tool that is:<\/p>\n\n\n\n I didn\u2019t throw Docker out overnight, and you probably shouldn\u2019t either. There are still situations where Docker makes sense:<\/p>\n\n\n\n The point isn\u2019t that Docker is unusable, it\u2019s that, once you\u2019ve seen what a daemonless, rootless-first model feels like, it\u2019s hard to go back.<\/p>\n\n\n\n I didn’t switch to Podman just to be a contrarian. I switched because it treats containers the way they were meant to be treated: as standard Linux processes, not as children of a monolithic server.<\/p>\n\n\n\n We are past the era where we need a daemon to hold our hands. If you value stability, security, and open-source freedom, the question isn’t “Why switch to Podman?” it is “Why are you still tying your containers to a fragile, root-privileged daemon?”<\/strong>.<\/p>\n\n\n\n At the very least, Podman deserves a spot in your toolbox. In my case, it replaced the toolbox entirely.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction I first discovered Podman back in 2022. It was listed as one of the supported engines for Distrobox, a tool I was experimenting with at the time. Back then, I was a dedicated Docker user. While I was vaguely intrigued by Podman’s “daemonless” nature, I didn’t feel a pressing need to switch. I subscribe… Read More »Why I Switched to Podman (And Why You Should Too)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","_themeisle_gutenberg_block_has_review":false,"footnotes":""},"categories":[6,10],"tags":[],"class_list":["post-186","post","type-post","status-publish","format-standard","hentry","category-blog","category-tech"],"_links":{"self":[{"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/posts\/186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/comments?post=186"}],"version-history":[{"count":1,"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/posts\/186\/revisions"}],"predecessor-version":[{"id":187,"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/posts\/186\/revisions\/187"}],"wp:attachment":[{"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/media?parent=186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/categories?post=186"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/wordpress.richardorilla.website\/index.php\/wp-json\/wp\/v2\/tags?post=186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Problem with the Docker Daemon<\/h2>\n\n\n\n
The Podman Difference: Native Linux Architecture<\/h2>\n\n\n\n
\n
Podman on Windows: Escaping the Heavy Desktop<\/h2>\n\n\n\n
\n
Simplified Management: The Power of Auto-Update<\/h2>\n\n\n\n
\n
\t\t\t\t
\npodman auto-update\n\n\t\t\t\t<\/code>\n\t\t\t<\/pre>\n\n\n\nSecurity by Design<\/h2>\n\n\n\n
\n
\n
How it Works Under the Hood<\/h3>\n\n\n\n
\n
When Docker Is Still the Right Tool (Caveats)<\/h2>\n\n\n\n
\n
Conclusion<\/h2>\n\n\n\n