Managing Podman containers has always been a relatively easy job—simple enough to use podman run, but not quite powerful enough when facing demand for more automation… or dropping into heavyweight orchestration tools like Kubernetes.
Well, now Podman’s giving users a solid middle ground. With its latest update, Quadlet management becomes a first-class citizen right inside Podman. The new podman quadlet command suite brings everything into one cohesive, unified workflow.
But wait, don’t know what Qudalets are? Let me explain very briefly. They are special configuration files that tell your Linux system (via systemd) how to run containers, pods, networks, or volumes automatically. Instead of typing out long podman run commands every time, you create a .container, .pod, .network, or .volume file that describes exactly what you want.
Systemd then takes care of starting, stopping, restarting, and logging for those containers—just like it does for regular Linux services—making container management more reliable and hands-off.
It’s worth also noting that Quadlets aren’t brand‑new—they’ve been part of the Podman ecosystem since around version 4.4, allowing users to drop the aforementioned configuration files into systemd search paths to manage containers under systemd declaratively.
But here’s the big deal: those Quadlets now live natively inside Podman’s own CLI—podman quadlet install, podman quadlet list, podman quadlet print, and podman quadlet rm—so you don’t have to juggle files or manual systemd fiddling anymore. Here’s what each of them does.
podman quadlet installlets you install configurations from local files, directories, or even URLs.podman quadlet listgives you a clean, filterable view of installed Quadlets—great for scripting or just getting your bearings.- Need to inspect the configuration of a Quadlet?
podman quadlet printshows you exactly what’s running. podman quadlet rmremoves Quadlets safely, with options to nuke them all or gracefully ignore ones that may already be gone.
Declarative container management—sounds a bit familiar, right? Probably because it’s a lot like another well-known approach. Yes, I’m talking about Docker Compose. But while they may look alike at first glance, there are some key differences between the two. Here’s a quick comparison table to help clear things up.
| Feature | Quadlets (Podman + systemd) | Docker Compose |
|---|---|---|
| Execution environment | Native Linux, tightly integrated with systemd | Cross-platform, runs through Docker Engine |
| Configuration format | .container, .pod, .volume, .network files (systemd unit extensions) | docker-compose.yml (YAML-based) |
| Service management | Uses systemd’s restart policies, logging, and dependency management | Docker’s built-in restart policies and Compose lifecycle |
| Startup at boot | Automatic via systemd | Requires Compose startup scripts or docker-compose up in a system service |
| Complexity level | Lightweight, perfect for single hosts or small deployments | Can span multi-container apps and networks across machines |
| Learning curve | Easy if you know systemd; less so if you’ve only used Docker | Easy for Docker users, doesn’t require systemd knowledge |
In other words, if you’re running workloads on Linux servers or desktops where systemd is already in charge, Quadlets give you seamless service management without extra daemons. On the other hand, Docker Compose is great for cross-platform workflows and larger development setups that aren’t tied to systemd.
In any case, however, having Quadlets built right into the Podman CLI is a big win for anyone who works with Podman. It gives you the automation you need, wrapped in the control you trust—and all sitting in the tool (systemd) you already use. So, give this new built-in Podman feature a try—you’re probably going to like it.
For more information, see the official announcement.
