What Quadlet actually is, in one paragraph

The simplest possible example

What you actually gain

The comparison that matters: Quadlet vs Docker Compose

When Quadlet is the wrong answer

When Quadlet is genuinely the right answer

The hybrid setup that actually makes sense

The honest closing thought If you run a homelab on Docker Compose, you've probably accepted a quiet trade-off without noticing. Your containers work. They start on boot. They restart if they crash. But they live outside the operating system's service model — orphaned from systemd, invisible to journalctl, dependent on a daemon that has to be alive before anything else in your stack can exist. Your 40 services are really 40 children of a single PID, not 40 first-class citizens of your Linux host. This isn't a problem, exactly. It's just a ceiling. And over the last year a feature from the Podman side of the container world has quietly raised that ceiling in a way that's interesting enough to write about — even if you, like me, have zero intention of ripping out your Docker Compose setup tomorrow. The feature is called Quadlet. It has been around since Podman 4.4, but 2026 is the year it's actually becoming the default way sysadmins on Red Hat-adjacent systems manage containers at home. And it does something I've not seen any other container tool do cleanly: it makes a container behave like a native systemd service. Let's look at what that actually means, what it's good for, and — importantly — when you should probably ignore it. Quadlet is a systemd generator that reads declarative .container files (plus .network, .volume, .pod, .kube, .image and a few others) and converts them at boot time into real systemd service units. You don't run podman run and you don't write unit files by hand. You drop an INI-style file into a specific directory, run systemctl daemon-reload, and now you have a fully managed service with restart policies, dependency management, journal logging, healthchecks, and optional auto-updates — all driven by systemd, not by a background daemon. That's the whole idea. The container is no longer something Podman runs on the side. It's something your operating system runs, the same way it runs sshd or nginx. A minimal rootless Quadlet for something useful — let's say Vaultwarden — looks like this: That's it. There's no vaultwarden.service file on disk — Quadlet generates it on the fly. If you edit the .container file and reload, the generated unit updates. If a newer Podman version ships improvements to the generator, your service picks them up next reboot without you touching anything. The volume referenced as vaultwarden-data.volume is another Quadlet file (a .volume), which generates a named volume managed by systemd the same way. This is the part that took me a while to appreciate. It's not "Podman has replaced Docker." It's that the integration layer is fundamentally different. Unified logging. journalctl --user -u vaultwarden.service gives you the container's logs in the same place and same format as the rest of the system. No docker logs, no parallel logging story. When something breaks at 2am, you're searching one place. Real dependency management. Want your Nextcloud container to only start after MariaDB is ready and network-online.target has fired? Write it in the [Unit] section like any other service. systemd handles the ordering, not a depends_on line that only waits for process start. Restart policies and health-triggered recovery. Quadlet exposes HealthCmd, HealthInterval, HealthOnFailure, HealthRetries directly. Combined with HealthOnFailure=kill and systemd's Restart=always, you get a self-healing service loop that doesn't depend on anything watching from outside. Auto-update with automatic rollback. Add AutoUpdate=registry and the podman-auto-update.timer checks daily for new image digests. If the new image fails the healthcheck after restart, Podman rolls back to the previous image automatically. No Watchtower, no cron hack, no custom script — and crucially, no blind latest tag chasing that silently deploys a broken image. Rootless by default. The file above runs under your user account. A container breakout gets your UID, not root. For a homelab exposing services, this is a meaningful reduction in blast radius. No daemon to keep alive. There's no dockerd that has to be up before your stack exists. Containers are direct children of systemd. If Podman itself has a bug tomorrow, the contract with your services is still "this is a systemd unit" — same tools, same lifecycle, same recovery procedures you already know. I want to be honest here because most of what's written online about Podman/Quadlet treats Docker Compose as the enemy. It isn't. Compose and Quadlet solve overlapping problems with very different philosophies. Docker Compose thinks in stacks. One docker-compose.yml describes a self-contained application: services, networks, volumes, dependencies, all in one file. You docker compose up -d and the stack exists. It's portable across any machine with Docker. You can commit it to a git repo and anyone can reproduce your environment. The mental model is: an application is a folder. Quadlet thinks in system services. Each container is its own unit file. Networks and volumes are their own unit files. The relationships are expressed through systemd's dependency graph, not through a single manifest. The mental model is: a container is a service that happens to run in a container. For development, portability, and throwaway environments, Compose wins. It's simpler, the tooling is mature, and the ecosystem is vast. For a long-lived single-host deployment where you want containers to behave like every other service on your Linux box, Quadlet wins. The honest answer for most homelabbers is that both are valid, and which one fits depends on what you actually value. Skip this feature if any of the following apply: This is where I've landed, and I think it's where most practical people will land: You don't have to pick one. On a Linux homelab you can run both side by side. The Docker daemon and Podman's rootless stack don't fight each other — they just don't talk. Quadlet isn't going to replace Docker Compose in most homelabs, and I don't think it should. Compose is good at what Compose is good for. What Quadlet does is close a gap I didn't realize I had: my containers were never really part of my operating system. They were tenants. With Quadlet, for the services where it matters, they become residents. That's a small distinction until it isn't — until the night something breaks and you realize your recovery story is the same one you use for every other service on the box, instead of a separate container-shaped exception. If you run Linux and you've been curious about Podman but couldn't articulate what the actual upgrade was, this is it. Not the daemon thing. Not the rootless thing in isolation. The integration. Try it on one service. See how it feels. If it clicks, you'll know. If it doesn't, your Compose file is still there, and nothing has been lost. Have you moved any part of your stack to Quadlet, or tried and bounced off it? I'd like to hear which services worked cleanly and which were more trouble than they were worth — drop it in the comments. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse