I was tired of containers that never came back after a reboot. So when Fedora 45 arrived with Podman 6, I moved my lab containers off podman run -d and onto Podman Quadlet. A Quadlet is a small unit file that you drop in a systemd directory. On the next daemon-reload, a generator turns it into a normal service with journald logs, restart policies and boot ordering. You do not write the podman run line yourself or babysit it.
These notes cover rootful and rootless .container units, a database stack built from .network, .volume and a Podman secret, a .build plus .pod combination, automatic image updates, and the podman quadlet install and remove commands. Two Podman 6 changes caught me out, and I’ll show both: networks are now isolated from each other by default, and quadlet rm no longer protects a network that a running container still uses. I rebuilt every unit in October 2026 on two lab VMs, box1 on Fedora 45 with Podman 6.1.4 and box2 on Fedora 44 with Podman 5.8.9, and every output below comes from those boxes.
What changed for Quadlet between Fedora 44 and Fedora 45
Every unit file in this guide ran unchanged on both releases. What differs is the behaviour around them, and most of it comes from the jump to Podman 6 on Fedora 45. I ran the same scripts on both VMs and wrote down where the results split:
| Behaviour | Fedora 44 (Podman 5.8) | Fedora 45 (Podman 6.1) |
|---|---|---|
Container on podman network reaching a container on a Quadlet network | Works (got the Adminer page) | Blocked, wget: download timed out |
podman quadlet install of a .quadlets bundle | Writes a hidden .whoami.app tracking file | Writes only the unit files |
podman quadlet rm on a running container plus its network | Refuses both | Removes the network, refuses the container, which is left orphaned |
podman quadlet list | No POD column, no --noheading | POD column, --noheading, ls alias |
| Rootless network, cgroups, database | pasta, v2, SQLite | pasta, v2, SQLite |
Isolation is the change that will break real setups, because a reverse proxy on the default network can no longer reach an app on its own Quadlet network. I cover it in the database section. If you’re upgrading a Fedora 44 machine that already runs containers, read fixing Podman after a Fedora upgrade first, and the Podman 6 breaking changes list for the BoltDB, slirp4netns and iptables removals.
Checking which Podman and Quadlet you have
Quadlet ships inside the podman package, so there’s nothing extra to install on a Fedora 45 or 44 box that already has Podman. If yours doesn’t, the Podman install guide for Fedora covers it. I checked the version, the generator binary and the management subcommands:
podman --version
ls -l /usr/libexec/podman/quadlet
podman quadlet --helpBoth boxes had the generator binary in place and listed the same four podman quadlet subcommands, so the management commands later in this guide work on either release. This is what box1 printed:
podman version 6.1.4
-rwxr-xr-x. 1 root root 2458240 Oct 12 00:00 /usr/libexec/podman/quadlet
Allows users to manage Quadlets
Description:
Allows users to manage Quadlets
Usage:
podman quadlet [command]
Available Commands:
install Install a quadlet file or quadlet application
list List Quadlets
print Display the contents of a quadlet
rm Remove QuadletsQuadlet reads files from a few fixed directories, and which one you use decides who owns the container:
/etc/containers/systemd/: rootful units, managed withsudo systemctl~/.config/containers/systemd/: rootless units for your user, managed withsystemctl --user/usr/share/containers/systemd/: units shipped by packages, which you shouldn’t edit
The rootful directory already existed on both VMs, the rootless one you create yourself in a later step, and SELinux was enforcing throughout. Nothing in this guide needs it turned off, so if a step only works after setenforce 0, treat that as a labelling bug to fix rather than a setting to keep.
Running a rootful container as a systemd service
I started with the simplest case: one Nginx container owned by root that starts at boot. Open a new unit file in the rootful directory:
sudo vim /etc/containers/systemd/web.containerPaste this. The [Container] section is Quadlet’s own, while [Service] and [Install] are plain systemd and get copied through as they are:
[Unit]
Description=Nginx web server (Quadlet)
[Container]
ContainerName=web
Image=docker.io/library/nginx:stable-alpine
PublishPort=8080:80
AutoUpdate=registry
[Service]
Restart=always
[Install]
WantedBy=multi-user.targetBefore I reload systemd, I run the generator in dry-run mode. It prints the service it would write, or the parse error that would make the unit vanish silently, which is far quicker than digging through the journal later:
sudo /usr/libexec/podman/quadlet -dryrunBelow is the complete service it generated on box1. Look at ExecStart, because that’s the podman run line I no longer have to maintain, and note the --replace flag, which comes back to bite in the errors section:
quadlet-generator[6788]: Loading source unit file /etc/containers/systemd/web.container
---web.service---
[Unit]
Wants=network-online.target
After=network-online.target
Description=Nginx web server (Quadlet)
SourcePath=/etc/containers/systemd/web.container
RequiresMountsFor=%t/containers
[X-Container]
ContainerName=web
Image=docker.io/library/nginx:stable-alpine
PublishPort=8080:80
AutoUpdate=registry
[Service]
Restart=always
Environment=PODMAN_SYSTEMD_UNIT=%n
KillMode=mixed
ExecStop=/usr/bin/podman rm -v -f -i web
ExecStopPost=-/usr/bin/podman rm -v -f -i web
Delegate=yes
Type=notify
NotifyAccess=all
SyslogIdentifier=%N
ExecStart=/usr/bin/podman run --name web --replace --rm --cgroups=split --sdnotify=conmon -d --label io.containers.autoupdate=registry --publish 8080:80 docker.io/library/nginx:stable-alpine
[Install]
WantedBy=multi-user.targetReload systemd so the generator writes the unit to /run/systemd/generator/, then start it and check the port:
sudo systemctl daemon-reload
sudo systemctl start web.service
systemctl status web.service --no-pager | head -5
curl -sI http://localhost:8080/ | head -1My first start took about 7 seconds on box1 because Podman had to pull the image before it could run anything. The status line names the .container file as the source and marks the unit generated:
● web.service - Nginx web server (Quadlet)
Loaded: loaded (/etc/containers/systemd/web.container; generated)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Mon 2026-10-26 02:36:03 UTC; 11ms ago
HTTP/1.1 200 OKWhy does the generated label matter? My reflex was to run sudo systemctl enable web.service, and systemd refused with Failed to enable unit: Unit /run/systemd/generator/web.service is transient or generated on both releases. You don’t need it. The generator already created the multi-user.target.wants/web.service symlink from the [Install] section, so the container starts at boot. To stop it from starting, remove or comment out WantedBy and reload.
Moving a container into your user account
Most of my containers don’t need root, so the next unit is a rootless Caddy site served from my home directory. Rootless units belong to your systemd user manager, and that manager stops when your last session closes unless lingering is on. So turn lingering on first, then create the site and the unit:
mkdir -p ~/.config/containers/systemd ~/site
echo 'hello from box1 (rootless caddy)' > ~/site/index.html
sudo loginctl enable-linger $USER
vim ~/.config/containers/systemd/site.containerPaste this unit. %h expands to your home directory, and the :Z suffix tells Podman to relabel ~/site so SELinux lets the container read it:
[Unit]
Description=Caddy static site (rootless Quadlet)
[Container]
ContainerName=site
Image=docker.io/library/caddy:2-alpine
PublishPort=8081:80
Volume=%h/site:/usr/share/caddy:Z
AutoUpdate=registry
[Service]
Restart=on-failure
[Install]
WantedBy=default.targetReload, start and check it with the same commands as before, minus sudo and plus --user:
systemctl --user daemon-reload
systemctl --user start site.service
curl -s http://localhost:8081/
podman quadlet list
ls -Z ~/site/index.htmlMy page came back, podman quadlet list showed the unit as active/running, and the file now carries container_file_t with a per-container MCS pair:
hello from box1 (rootless caddy)
NAME UNIT NAME PATH ON DISK STATUS APPLICATION POD
site.container site.service /home/philip/.config/containers/systemd/site.container active/running
system_u:object_r:container_file_t:s0:c94,c917 /home/philip/site/index.htmlRootless containers use pasta for networking on both releases, and the rootless generator orders units after podman-user-wait-network-online.service rather than the system’s network-online.target. The :Z label is private to one container. If two containers need the same directory, use lowercase :z, and the SELinux survival guide explains what both labels do. Leaving the suffix off gets you a 403, which I show in the errors section.
Wiring a database stack with .network, .volume and a secret
Multi-container apps are the real reason I use Quadlet. I wanted PostgreSQL and Adminer on their own network, the database files on a named volume, and the password kept out of the unit file, because that is how I’d run it on a real host. It takes one secret and four files in /etc/containers/systemd/:
app.network: a bridge with a fixed subnetapp-db.volume: the named volume for the database filesapp-db.container: PostgreSQL with a health checkapp-ui.container: Adminer, ordered after the database
Each file is small, and the generator works out the order between them from the references. Start with the network:
sudo vim /etc/containers/systemd/app.networkA fixed subnet makes the addresses predictable when you debug. The label is optional:
[Network]
Subnet=10.89.10.0/24
Label=app=demoThen open the volume file, which needs even less than the network did.
sudo vim /etc/containers/systemd/app-db.volumeA single label line is enough, because Quadlet creates the volume with default options:
[Volume]
Label=app=demoPut the password into a Podman secret rather than an Environment= line, so it never lands in a file you might commit. Replace the example value with your own:
printf '%s' 'S3cretPass2026' | sudo podman secret create app-db-pass -Now open the database container file, which is where most of the decisions live.
sudo vim /etc/containers/systemd/app-db.containerNotice how it refers to the network and volume by their file names. Notify=healthy holds the unit in activating until pg_isready passes, so anything ordered after it waits for a database that actually accepts connections:
[Unit]
Description=PostgreSQL for the demo app
[Container]
ContainerName=app-db
Image=docker.io/library/postgres:18-alpine
Network=app.network
Volume=app-db.volume:/var/lib/postgresql
Secret=app-db-pass,type=env,target=POSTGRES_PASSWORD
Environment=POSTGRES_DB=app
HealthCmd=pg_isready -U postgres
HealthInterval=10s
Notify=healthy
[Service]
Restart=always
[Install]
WantedBy=multi-user.targetI mounted /var/lib/postgresql, not the old /var/lib/postgresql/data. The PostgreSQL 18 image keeps its data in /var/lib/postgresql/18/docker (I checked $PGDATA inside the container), so mounting the parent keeps the data on the volume. Next, the UI container:
sudo vim /etc/containers/systemd/app-ui.containerAdminer joins the same network and finds the database by container name through aardvark-dns:
[Unit]
Description=Adminer UI for the demo app
Requires=app-db.service
After=app-db.service
[Container]
ContainerName=app-ui
Image=docker.io/library/adminer:latest
Network=app.network
PublishPort=8082:8080
Environment=ADMINER_DEFAULT_SERVER=app-db
[Service]
Restart=always
[Install]
WantedBy=multi-user.targetStarting only the UI unit is enough, because the generator adds Requires= and After= lines for the network and volume services:
sudo systemctl daemon-reload
sudo systemctl start app-ui.service
sudo podman network ls
sudo podman volume ls
sudo podman exec app-ui getent hosts app-dbThat start command blocked for 53 seconds, which surprised me until I realised most of it was two image pulls and the rest was the health gate holding app-db.service until PostgreSQL answered. Note the names, too. Quadlet prefixes the network and volume with systemd- unless you set NetworkName= or VolumeName=:
NETWORK ID NAME DRIVER
2f259bab93aa podman bridge
17fb10155cf2 systemd-app bridge
DRIVER VOLUME NAME
local systemd-app-db
10.89.10.2 app-db.dns.podman app-db.dns.podman app-dbMy secret stayed hidden, too. podman inspect app-db showed POSTGRES_PASSWORD=*******, and psql inside the container reported PostgreSQL 18.6. Below is the whole rootful set as podman quadlet list saw it, with the network and volume units in active/exited because they run once and stop:
Then I tested something I had taken for granted. Can the web container from the first section, which sits on the default podman network, reach Adminer on systemd-app? The name app-ui doesn’t resolve from another network, so look up its address first. On box1 it was 10.89.10.3:
sudo podman inspect app-ui --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'Then try to fetch the Adminer page from inside web:
sudo podman exec web wget -q -T 3 -O- http://10.89.10.3:8080/On Fedora 44 it returned Adminer’s HTML, but on Fedora 45 it hung until the timeout.
wget: download timed outPodman 6 turned on network isolation by default. In nft list ruleset on box1, the NETAVARK-ISOLATION-1 chain sends traffic that leaves podman0 or podman1 for the other bridge to a drop rule, and on box2 that chain was empty. I tried relaxing it from the Quadlet side by adding Options=isolate=false to app.network and recreating the network. podman network inspect then showed map[isolate:false], but the same wget still timed out, because the default podman network is isolated as well and I left it alone. If you run a reverse proxy in its own container, join it to the app’s network with a second Network=app.network line instead of routing across bridges. Published ports are not affected, and Adminer still answered on port 8082 from the host.
Building an image and running it in a pod
For things I build myself, I wanted Quadlet to run the build too, and I wanted two containers sharing one network namespace. That’s a .build unit and a .pod unit. I did this one rootless, and it takes five files in my user’s Quadlet directory:
hello-build/Containerfile: the image recipehello.build: builds and tags itdemo.pod: the pod and its published porthello.containerandsidecar.container: the two members
Create the build directory and the Containerfile first, since the build unit points at it.
mkdir -p ~/.config/containers/systemd/hello-build
vim ~/.config/containers/systemd/hello-build/ContainerfileMy image serves one generated page with BusyBox httpd on port 8000:
FROM docker.io/library/alpine:3.22
RUN apk add --no-cache busybox-extras
RUN echo "built by Quadlet on $(cat /etc/alpine-release)" > /index.html
CMD ["httpd","-f","-p","8000","-h","/"]Next comes the build unit, which tells Quadlet what to build and what to tag it as.
vim ~/.config/containers/systemd/hello.buildSetWorkingDirectory=unit makes the build context the directory the unit lives in, so File= is relative to it:
[Build]
ImageTag=localhost/hello:latest
SetWorkingDirectory=unit
File=hello-build/ContainerfileOne side effect: the context is all of ~/.config/containers/systemd, which the generated podman build ... /home/philip/.config/containers/systemd line made obvious. That’s harmless here. For a big project, point SetWorkingDirectory= at the project directory instead. Now the pod:
vim ~/.config/containers/systemd/demo.podPorts belong on the pod, not on the containers inside it, because every member shares the pod’s network namespace.
[Pod]
PodName=demo
PublishPort=8083:8000Next, the app container, which uses the build unit as its image:
vim ~/.config/containers/systemd/hello.containerAutoUpdate=local restarts it whenever I rebuild the tag locally, which I test in the next section:
[Container]
ContainerName=hello
Image=hello.build
Pod=demo.pod
AutoUpdate=local
[Install]
WantedBy=default.targetLast comes a sidecar that polls the app over 127.0.0.1, which only works because the two containers share the pod’s network namespace. My first version had no [Unit] section at all. On both releases its first request failed with wget: can't connect to remote host (127.0.0.1): Connection refused, because starting the pod launched the sidecar while hello-build.service was still compiling the image. The version below waits for the app container. After=hello.service only waits until the container process is running, which is enough for BusyBox httpd; a slower app needs a HealthCmd= and Notify=healthy on hello.container, as with the database earlier.
vim ~/.config/containers/systemd/sidecar.containerPaste the fixed unit, which only adds the [Unit] ordering lines to my first attempt.
[Unit]
Wants=hello.service
After=hello.service
[Container]
ContainerName=sidecar
Image=docker.io/library/alpine:3.22
Pod=demo.pod
Exec=sh -c "while true; do wget -q -O- http://127.0.0.1:8000/ ; sleep 30; done"
[Install]
WantedBy=default.targetStart the pod unit and nothing else. The generator binds each member container to demo-pod.service, so starting the pod brings up the build and both containers in one go.
systemctl --user daemon-reload
systemctl --user start demo-pod.service
podman pod ps
curl -s http://localhost:8083/Once the build finished, the pod held three containers (infra, hello and sidecar), and the page answered on the pod’s port:
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
61515b610f9f demo Running 14 seconds ago 3a5dd09974b5 3
built by Quadlet on 3.22.7After the fix, the sidecar’s journal showed built by Quadlet on 3.22.7 on its first poll. I rebooted both VMs at the end, and every unit in this guide came back on its own, rootful and rootless. On box1 systemd-analyze blame showed app-db.service at 14.7 seconds, which is the health check gate doing its job.
Turning on automatic image updates
AutoUpdate= only adds a label to the container. Nothing acts on it until podman auto-update runs, and its timer was disabled by default. I checked root and my user on box1, and root on box2. There are two policies:
registry: pull the tag and restart if the digest changedlocal: restart if the local tag now points at a newer image, with no pull- no key at all: the container is skipped
I tested local because I could force a change. I took a dry run, edited the Containerfile, rebuilt the same tag by hand, and compared a second dry run with the real run:
podman auto-update --dry-run
sed -i 's/built by Quadlet on/rebuilt by Quadlet on/' ~/.config/containers/systemd/hello-build/Containerfile
podman build -q -t localhost/hello:latest -f ~/.config/containers/systemd/hello-build/Containerfile ~/.config/containers/systemd
podman auto-update --dry-run
podman auto-updateThe second dry run marked the container pending, and the real run flipped it to true in 24 seconds. Look at the UNIT column: for a container inside a pod, auto-update restarts demo-pod.service, so the sidecar restarts with it. I repeated the test in one continuous session for the capture below. A curl straight after the update returned nothing while the pod came back, and podman pod ps then showed a new pod ID created 8 seconds earlier, because the pod unit runs pod create --replace on every start:
Which timer do you need? Both, if you have rootful and rootless containers. The system timer only updates rootful containers, because it runs podman auto-update as root and never sees your user’s container store, so rootless units need your user’s timer as well:
sudo systemctl enable --now podman-auto-update.timer
systemctl --user enable --now podman-auto-update.timer
systemctl list-timers podman-auto-update.timer --no-pagerEach timer is OnCalendar=daily with up to 15 minutes of random delay and Persistent=true, so a box that was off at midnight catches up when it boots:
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2026-10-27 00:05:16 UTC 21h - - podman-auto-update.timer podman-auto-update.service
1 timers listed.Running sudo podman auto-update --dry-run only listed web.service, which confirms the split. If the restarted unit fails, auto-update rolls back to the previous image by default, and with Notify=healthy a container that never turns healthy counts as a failed start once the unit’s start timeout runs out. I’d still pin a major version tag such as postgres:18-alpine on anything stateful, because a rollback won’t undo a data migration.
Installing and removing Quadlets with podman quadlet
Copying files into the right directory and reloading works fine, but podman quadlet install does both, and it can take several units in one .quadlets file. Each section starts with a # FileName= line, and sections are separated by ---. I wrote this bundle to ~/bundle/whoami.quadlets:
mkdir -p ~/bundle
vim ~/bundle/whoami.quadletsThis bundle holds a container and the network it joins, in that order.
# FileName=whoami
[Container]
ContainerName=whoami
Image=docker.io/traefik/whoami:latest
Network=whoami.network
PublishPort=8084:80
[Install]
WantedBy=default.target
---
# FileName=whoami
[Network]
Label=app=whoamiInstall it, then start it. No manual daemon-reload is needed, because the install reloads systemd itself.
podman quadlet install ~/bundle/whoami.quadlets
systemctl --user start whoami.service
curl -s http://localhost:8084/ | head -1Podman split the bundle into two unit files, picking each extension from the section type:
/home/philip/.config/containers/systemd/whoami.container
/home/philip/.config/containers/systemd/whoami.network
Hostname: 198dc2d7e035On Fedora 44 the same install also wrote a hidden .whoami.app file and filled the APPLICATION column with it. Podman 6 dropped that tracking file. For an application installed with --application, the man page says all files go under a directory with the application’s name, which I read as the replacement for that tracking file. Removal is where the two releases really differ, so try it while the container is running:
podman quadlet rm whoami.container whoami.networkFedora 44 refused both files, which is what I expected. Fedora 45 removed the network file and refused only the container.
whoami.network
Error: unable to remove Quadlet whoami.container: quadlet whoami.container is running and force is not set, refusing to remove: quadlet is running
Error: some quadlets could not be removedAfter the automatic reload, whoami.service went to not-found, because its whoami.network dependency no longer existed. The container itself kept running, though. A later podman quadlet rm --force whoami.container deleted the file but left the container and the systemd-whoami network behind, so I had to clean them up by hand. On Podman 6, stop a stack before you remove it:
systemctl --user stop whoami.service
podman quadlet rm whoami.container whoami.networkStopping first removed both files cleanly, and no whoami container was left. The systemd-whoami network stays until you run podman network rm systemd-whoami. If you already hit the orphan, podman rm -f whoami clears the container first. podman quadlet print whoami.container shows the installed file, which is handy on a box someone else set up.
Mapping docker-compose keys to Quadlet
Podman has no built-in converter from a Compose file to Quadlet. I rewrote mine one service at a time, using one .container file per service and one .network file per Compose network. These are the keys I needed, all of them used somewhere in this guide:
| Compose key | Quadlet equivalent |
|---|---|
image | Image=, or Image=name.build for a .build unit |
ports | PublishPort=8080:80 (on the .pod when the container is in a pod) |
volumes (named) | Volume=name.volume:/path plus a .volume file |
volumes (bind) | Volume=%h/dir:/path:Z |
environment | Environment=KEY=value, one per line |
secrets | Secret=name,type=env,target=VAR |
depends_on | Requires= and After= in [Unit] |
depends_on: condition: service_healthy | HealthCmd= plus Notify=healthy on the dependency |
networks | Network=name.network plus a .network file |
restart: always | Restart=always in [Service] |
command | Exec= |
If you’d rather keep the YAML for now, Podman Compose on Fedora runs it as is, and you can move services across as you touch them. For interactive work, toolbox containers fit better than services, and the Distrobox and Toolbox guide covers that side.
Errors I hit and how I fixed them
Every error below came from box1 or box2 while I wrote this. Most of them are silent until you know where to look, and that place is almost always the generator’s dry run or the user journal.
Failed to start typo.service: Unit typo.service not found
I’d written PublishPorts= with an extra s. The generator skips any file it can’t parse, so daemon-reload succeeds and the unit simply doesn’t exist. The dry run names the bad key:
/usr/libexec/podman/quadlet -dryrun -userBoth releases printed the same message, and it also lands in journalctl --user -b where nobody thinks to look.
quadlet-generator[10003]: converting "typo.container": unsupported key 'PublishPorts' in group 'Container' in /home/philip/.config/containers/systemd/typo.container
quadlet-generator[10003]: processing encountered some errorsFix the key and reload. Drop -user and run it with sudo for files in /etc/containers/systemd/.
403 Forbidden: index.html is forbidden (13: Permission denied)
A rootless Nginx unit with Volume=%h/site2:/usr/share/nginx/html:ro started fine and then answered every request with 403. The container log had the real reason:
2026/10/26 02:40:22 [error] 25#25: *1 "/usr/share/nginx/html/index.html" is forbidden (13: Permission denied), client: fe80::e401:7fff:fe27:38fd, server: localhost, request: "GET / HTTP/1.1", host: "localhost:8086"SELinux blocked the read because the directory still carried its user_home_t label, which ls -Z ~/site2 confirmed. Add :Z (or :z for shared directories) to the mount options, as in Volume=%h/site2:/usr/share/nginx/html:ro,Z, then reload and restart.
Failed to enable unit: Unit is transient or generated
You saw this systemctl enable refusal in the first section. It isn’t really an error: boot start comes from WantedBy= in the [Install] section, and the generator creates the symlink on every reload.
quadlet is running and force is not set, refusing to remove
podman quadlet rm won’t delete the file of a running unit. Stop the unit first rather than reaching for --force, because on Podman 6 --force deleted the file but left the container running with no unit behind it.
A container I created by hand disappeared
Older guides warn that a leftover container with the same name blocks the unit from starting. That’s no longer true. I stopped web.service, ran sudo podman run -d --name web ... sleep 600 by hand, and started the unit again. It came up as Nginx without a complaint, because the generated ExecStart carries --replace, and the hand-made container was deleted. The fix is a naming habit: don’t reuse a Quadlet’s ContainerName for ad hoc containers.
What I still don’t know
A few things I could not settle in the lab, and I would rather list them than guess.
- Whether setting
isolate=falseon both the default network and a Quadlet network restores cross-network traffic. One side alone did not - How
podman quadlet installlays out a multi-file application directory on Podman 6. I only tested the single-file bundle - How rollback behaves in practice on a pod unit. The man page covers a failed restart, but I never got an update to fail on purpose
None of these stopped me from moving every long-running container on box1 to Quadlet. On a host that faces a network, the published ports still need a firewall rule, and the firewalld walkthrough for Fedora covers that part. The full key reference for each unit type is in the upstream podman-systemd.unit man page.
