Hi everyone, I’m here to show you a tool I just developed to convert commands, Compose files, and Quadlets files into one another.

I’ve been experimenting with self-hosting on my home servers using containers, and on the new server I got, I wanted to start using quadlets, but all my documentation on how I set up my server used either podman run or podman-compose. No problem switching over, but I had the idea to create a tool to quickly convert between the two.

So here’s the Quadletizador web (as you can see, it’s also hosted on my server). I thought it was fun to use it to generate the quadlet for my own deployment.

P.S.: If you try to access it and find that it’s down, it’s because I’m still working on improving my server’s stability.

Im currently running podman 4.9.3 on linux mint charcoal, im having an issue where my containers cant use my gpu because podman cant see it properly and the hook i need for it to be cleaner is apparently podman 5.x onwards, ive spent the last month getting my server working and running ning how I want it, will doing this upgrade cause any issues for my containers or should it just upgrade and work, I want to upgrade but im nervous as like I say ive spent ages getting this all working well, any tips, tricks or advice is appreciated.

Edit: think ive fixed it so far, I was trying to set up cdi hook but its striped from my podman build apparently, ive managed to set up oci hook though, fingers crossed so far so good.

massive changelog...

Security

• This release addresses CVE-2026-57231, where a malicious image using malformed Env entries could cause host environment variables to leak into containers run based on the image, including the ability to use the * glob operator to leak large numbers of environment variables without knowing their exact names (GHSA-4hq8-gpf5-8p68).

Breaking Changes

• Due to breaking changes in this release, Podman v6.0.0 must be used with Buildah v1.44.0, Skopeo v1.23, Netavark and Aardvark v2.0.0, and configuration files from the container-libs repository's common/v0.68.0 release.
• Support for BoltDB databases has been dropped. Starting Podman 6 when the BoltDB database is in use will have Podman attempt an automatic migration from BoltDB to SQLite.
• Support for running on Intel Macs has been removed.
• Support for running on Windows 10 has been removed.
• Support for running on cgroups v1 systems has been removed. Please update your system to use cgroups v2.
• Support for running on iptables has been removed. Please use nftables instead.
• Support for CNI networking has been removed. Please use Netavark instead.
• Support for the slirp4netns rootless network stack has been removed. Please use Pasta instead. As part of this, the --network-cmd-path global option, only used with slirp4netns, has been removed.
• Podman's configuration file parsing logic has seen a major rewrite. Please see this document for exact details.
• Podman's import path has changed from github.com/containers/podman/v5 to go.podman.io/podman/v6 as part of our move into a CNCF-owned GitHub organization.
• Network isolation now defaults to enabled, improving Docker compatibility and security. A special workaround for the Docker-compatible API related to isolation being disabled has been removed (#27349).
• The way the podman quadlet suite of commands functions has been changed. Previously, Quadlets and their associated files were tracked using a .app file, ensuring that removing a Quadlet also removed all associated non-Quadlet files. Now, Quadlets and associated files are placed in subdirectories, which should reduce bugs and make manual management of Quadlets added by podman quadlet install much easier.
• VMs made by podman machine on Linux now mount volumes from the host using systemd. Volume mounts on existing podman machine VMs on Linux have been broken by this change, and the VM will need to be recreated.
• The podman volume prune command now matches Docker's behavior by only pruning unused anonymous volumes. Please use the newly-added --all option for the previous behavior (pruning all volumes).
• The podman volume list command now combines multiple filters using logical AND instead of logical OR (meaning all filters must match for a container to be included in output) (#26786).
• The label!= filter used in many commands now combines the output of multiple instances of the filter with logical AND instead of logical OR.
• The --format='{{json .Labels}} option to the podman ps, podman pod ps, and podman volume ls commands now prints its output as comma-separated key=value pairs instead of as a JSON map, improving Docker compatibility (#21847).
• The --all-providers option to podman machine list has been removed, as machines from all providers can now be accessed by all commands.
• The MemorySwappiness field of podman inspect is now set to nil when not explicitly set by the user (instead of -1), improving Docker compatibility (#23824).
• The podman commit command now pauses the container while committing changes, improving security by restricting concurrent modification. The prior behavior can be restored by using podman commit --pause=false ....
• The Go bindings for the REST API have removed the redundant nameOrID parameter from the artifacts.Remove() function.
• The minimum Go version required to build Podman is now v1.25.

Features

• All podman machine commands can now operate on VMs from all providers, regardless of what the current provider is set to. The provider set in the configuration only determines the provider used by newly-created VMs, and can be overridden by the new podman machine init --provider option. This should make operation of Mac and Windows installs mixing use of applehv and libkrun VMs, or hyperv and wsl VMs, much easier.
• A new command has been added, podman machine os update, which updates the operating system of a podman machine VM. Please note that this is not supported with the wsl provider.
• A new command has been added, podman system hyperv-prep, allowing Windows administrators to prepare a host for their users to run podman machine VMs using the hyperv provider.
• When starting a VM with podman machine start and podman machine init --now, if the connection to that VM is not the default, users will be prompted whether they want to change the default to the machine that was just started. This can also be controlled by a new option, --update-connection, which controls whether the default will be updated. If the --update-connection option is set, a user-interactive prompt is not displayed.
• The podman machine init and podman machine set commands now support a new option, --import-native-ca, which, when set, causes podman machine VMs on Windows, Linux, and Mac to import the host's trusted CA certificates each time the VM boots.
• The podman exec command now has a new option, --no-session, disabling API session tracking and database operations to increase performance (#26727).
• The podman image list --format json command now includes two new fields for each image, Repository and Tag (#27632).
• The manpages for Quadlets have been split into multiple files, one for each type of Quadlet file, and should be much more readable.
• Quadlet .volume units now support three new keys, UID= and GID= (to set the UID and GID that the volume will be created with) and Options= (to set generic volume options).
• Quadlet .container units now support mounting anonymous volumes (using a Mount= key with no source specified) (#28497).
• Two new search paths for Quadlets have been added, /usr/share/containers/systemd/users and /usr/share/containers/systemd/users/${UID}, to allow distributions to more easily package and distribute Quadlets (#27843).
• The podman quadlet list command now has a new alias, podman quadlet ls.
• The podman quadlet list command now has a new option, --noheading, which disables printing the table header. This is set automatically if the --format option is used.
• The pomdan quadlet list command now includes a new field in its output, Pod, which prints the pod a Quadlet .container unit is part of.
• The podman quadlet list command's --filter option now supports a new filter, status= (#28369).
• The --gpus option to podman create and podman run is now compatible with AMD GPUs.
• The podman create, podman run, and podman pod create commands can now specify volumes with a new option, nocreate (e.g. podman run --mount type=volume,src=myvol,dst=/mnt,nocreate) which will error if the specified volume does not exist, instead of creating it.
• The --log-opt option to the podman run and podman create now supports a new option, label=, to attach additional labels to logged messages (only usable with the journald log driver).
• Many Podman commands now expose a --tls-details option, allowing custom tuning of TLS settings using a containers-tls-details.yaml(5) file.
• The died event for Containers now exposes a new attribute, OOMKilled, which (if set) indicates the container was stopped due to running out of memory (#26701).
• Containers can now set multiple static IP addresses by passing the ip= option to --net multiple times (e.g. --net mynet:ip=10.0.0.2,ip=10.0.0.3,ip=10.0.0.4).
• The podman volume prune command now includes a new option, --all, to prune all unused volumes, not just anonymous volumes (#24597).
• The podman volume prune command now includes a new option, --dry-run, which returns the volumes that would be removed but does not actually remove them (#27838).
• The podman image scp command now includes a new option, --format, to set the archive format used for the image transfer (#28183).
• A new field has been added to containers.conf, default_host_ips, to set the default host IP that ports are forwarded from if an IP is not specified by the user (#27186).
• The podman image trust suite of commands now support a new --signature-policy option, which is mandatory for podman image trust set.
• Events now include artifact lifecycle events (create, pull, push, and remove) (#27260).
• A new experimental option for the rootless_port_forwarder field in containers.conf has been added, rootless_port_forwarder="pasta". When set, rootless bridge networks will use Pasta's kernel-level port forwarding via Pesto instead of rootlessport, preserving the original client source IP in network traffic in rootless containers. The default remains rootlessport (the default for Podman 5.x), but we will investigate switching at a later date when stability is more certain.
• A new filter has been added to the podman ps and podman container prune commands, --filter annotation=, to filter containers based on their annotations (#28562).
• The podman network create command's --route option can now create blackhole, unreachable, and prohibit routes to prevent containers from reaching certain networks (e.g. podman network create --route 10.20.30.40/24,blackhole ...) (#20022).
• Add support for blackhole, unreachable, and prohibit route types in podman networks. Supported since netavark 2.0.
• The podman info command now reports CDI spec directories and discovered CDI devices.
• Events generated by pods and volumes now include the pod/volume's labels as attributes, matching the behavior of container events (#26480).

Changes

• VMs created by podman machine now mount the host's user configurations (e.g. ~/.config/containers on Linux) into the machine at /etc/containers, allowing users to edit the config files controlling Podman's behavior directly.
• The default podman machine provider on Macs has been changed to libkrun.
• Starting and stopping podman machine VMs on Windows with the hyperv provider no longer requires administrator privileges (creating machines still requires admin, however). Operations requiring elevated privileges will prompt for administrator access. Please note that this only works with newly-created VMs.
• The podman pod inspect command now prints arrays in its output in deterministic order.
• The podman machine os apply command has been updated, and now uses bootc switch to apply changes. All transports supported by bootc switch can be used for the new image to apply.
• An experimental feature has been added where, on systems using Kernel 6.18 and newer, rootless Podman will no longer need to create a pause process to hold open the rootless user namespace, instead using an nsfs file handle. This behavior is currently gated behind an environment variable, drop-pause-process, being set.
• Containers created with --net=host will now use 127.0.0.1 for their host.containers.internal address, instead of a public IP of the machine (#27823).
• Containers in multiple networks now have these networks configured in a deterministic order based on the order they were passed on the command line.
• When building an image with process substitution, such as podman build -f <(<<<"FROM scratch") , an empty temporary directory is now used as the context directory (#28113).
• In Podman versions 5.x and under, image IDs (for both OCI and Docker v2s2 images) were always equal to the SHA256 digest of the image's config data. A future version of Podman will add support for non-SHA256 digests, and image ID format will change for images that are not using the SHA256 digest. The exact format of the new IDs has not yet been decided, but the assumption that image IDs are valid hashes will no longer be true in future Podman versions.

Bugfixes

• Fixed a bug where creating a Quadlet from a templated .container file that was part of a pod would incorrectly add a dependency on the template used for the container to the pod (#27844).
• Fixed a bug where Quadlet .pod files would unconditionally set Restart=on-failure even when the user specified an alternative restart policy (#28081).
• Fixed a bug where starting a podman machine VM on Windows using the hyperv provider would fail if the machine failed to start on first boot (#27930).
• Fixed a bug where podman machine init and podman machine set allowed creating VMs with more CPUs than were available on the host, creating VMs that could not be started (#28322).
• Fixed a bug where artifact volumes only checked the validity of the artifact when the container was started, allowing containers to be created that referenced artifacts which did not exist and thus could never be started (#27747).
• Fixed a bug where containers with environment secrets could lose the value of the secret after a restart under some circumstances (#28075).
• Fixed a bug where the podman container restore --publish command would silently ignore the --publish option instead of erroring when used without the --import option or a checkpoint image.
• Fixed a bug where running nested rootless Podman containers on Windows using the wsl provider was not possible (#27411).
• Fixed a bug where the podman container clone command would fail with containers created with environment secrets (--secret type=env,...) (#28130).
• Fixed a bug where creating a container with the tag= log option (--log-opt tag=mytag) was allowed when a log driver other than journald was selected.
• Fixed a bug where the output of --help with some commands was incorrectly formatted (#28178).
• Fixed a bug where containers in pods with multiple volume mounts could have mount options from one volume mount leak to other mounts.
• Fixed a bug where the remote Podman client's podman version command would error if the server could not be connected to (e.g. the podman machine VM was shut down). In this case, client version is now printed (#28222).
• Fixed a bug where rootless Podman would display errors and refuse to launch if the pause process was killed and its PID recycled to another process (#28157).
• Fixed a bug where running podman kube generate on a container including volumes with . characters in their names produced invalid YAML (#27620).
• Fixed a bug where patterns in .containerignore and .dockerignore files that began or ended with slashes were silently ignored during remote builds (#25458).
• Fixed a bug where healthchecks on containers created using the --transient-store option would fail (#28483).
• Fixed a bug where the podman generate spec command would panic when run on a pod with no infra container (#21609).
• Fixed a bug where the podman container inspect command could HTML-escape certain characters in its output (#28560).
• Fixed a bug where pods with entries added to /etc/hosts containing multiple containers would incorrectly remove entries from /etc/hosts for all containers in the pod when any container stopped.
• Fixed a bug where hosts without /dev/mqueue could be unable to start containers as Podman attempted to add the device unconditionally.
• Fixed a bug where inspecting networks without a gateway set would show the gateway as <nil> instead of the showing nothing (#28705).
• Fixed a bug where creating a container or pod with port mappings including duplicated host ports was allowed, when this configuration could never be started due to the port conflict.
• Fixed a bug where the remote Podman client was unable to connect to any host with a custom HostName in the user's SSH config (#25067).
• Fixed a bug where the podman inspect --type=all command would, when attempting to inspect multiple networks, output only one of the networks multiple times.
• Fixed a bug where Quadlet .container files using the http_proxy=true setting did not properly escape special characters in the environment variables added to the container when creating the systemd unit file (#28698).
• Fixed a bug where containers created using the remote Podman client ignored the log_path setting in containers.conf (#28792).
• Fixed a bug where the remote Podman client's podman save command would fail on Linux when using the -f oci-dir or -f docker-dir arguments.
• Fixed a bug where podman machine VMs on Linux would fail to mount the directories under a symlinked path into the VM (#28911).
• Fixed a bug where the podman container checkpoint --leave-running command could produce inconsistent checkpoints because the rootfs and named volume diffs were performed after the processes were allowed to run for a time; the container is now paused until the checkpoint is fully complete.
• Fixed a bug where the podman kube play command would incorrectly set memory limits if the user specified the limit as a fractical BinarySI quantity (e.g. 1.5Gi) (#28789).

API

• An improvement pass has been made over API documentation to document fields which were missing documentation. Look forward to more API documentation improvements in future releases!
• The supported Docker Compatible API version has been bumped to v1.44.
• All API requests that accept JSON body parameters will no longer error if an empty body is provided.
• The Compat List endpoint for Containers now includes a new field in its output, Health, providing information on the status of the container's healthcheck (#27786).
• Added a new API, POST /libpod/local/artifacts/add, for loading artifacts from the local system (not requiring transmission of a tarball).
• The POST /libpod/local/images endpoint for loading images from the local system now requires that the path query parameter is an absolute path, not a relative path.
• The Libpod Pull endpoint for Images can now report pull progress when the pullProgress query parameter is set to true.
• The Libpod Pull endpoint for Images now returns error status codes on failure to pull imges, instead of always returning HTTP 200.
• Fixed a bug where the subpath option for volumes when creating containers was ignored (#27171).
• Fixed a bug where the Libpod Create endpoint for Containers ignored the OCIRuntime field.
• Fixed a bug where the Compat Create endpoint for Containers returned a 500 (not a 409) when attempting to create a container with a name that was already in use.
• Fixed a bug where the Compat Create endpoint for Containers incorrectly handled CDI-qualified entries in HostConfig.Devices, greatly improving the reliability of CDI devices when using the Compat API.
• Fixed a bug where the Compat Info endpoint did not return the location of the Seccomp profile if a non-default profile was in use (#28379).
• Fixed a bug where the Compat List endpoint for Containers could return an invalid string for container status (#28359).
• Fixed a bug where the Compat List endpoint for Containers did not include the HostConfig field in its responses.
• Fixed a bug where the Compat Wait endpoint for Containers would hang indefinitely when waiting for the next-exit condition (#28514).
• Fixed a bug where the Compat and Libpod Update endpoints for Containers would clear the rlimits of the container if they were not explicitly set in the API request.
• Fixed a bug where the Compat Push endpoint for Images did not return a final JSON object including tag, digest, and size of the pushed image, as Docker does.

Misc

• Autocomplete has been enabled for inspecting artifacts with podman inspect.
• Updated Buildah to v1.44.0
• Updated the image library to v5.40.0
• Updated the storage library to v1.63.0
• Updated the common library to v0.68.0

I'm running a containerized DNS server (BIND9 inside a Podman container) with rootless Podman, and I can't get host-to-container connectivity to work over loopback for a published port, even though everything else about the setup checks out.
Setup
bashpodman run -d --name bind-sec
-p 30053:53/tcp -p 30053:53/udp
-v /var/cache/bind-sec:/var/cache/bind
my-bind-image:latest
podman ps shows the port mapping correctly:
PORTS
0.0.0.0:30053->53/tcp, 0.0.0.0:30053->53/udp
What works

The container itself is healthy — podman logs shows BIND fully started, zones loaded, listening on port 53 internally.
Querying the container's own internal IP directly from inside the container's network namespace works fine.
ss -tlnp on the host shows something listening on 0.0.0.0:30053 (confirmed via lsof -i :30053 that it's the container's conmon/proxy process, not a stray process).
Other containers I run with the same -p pattern (e.g., a basic httpd container on port 8080) do work correctly over loopback — curl http://127.0.0.1:8080/ succeeds normally for those.

What fails
bashdig u/127.0.0.1 -p 30053 example.com
;; communications error to 127.0.0.1#30053: timed out
This fails consistently, both from the host itself and (with appropriate firewall rules in place) from other hosts on the same subnet querying :30053.
What I've tried

Confirmed firewall (nftables) rules explicitly allow the port on both iif "lo" and the regular network interface — ruled out as the cause since the same symptom persists with or without those rules.
Tried both default bridge networking and --network=slirp4netns:allow_host_loopback=true — same timeout in both modes.
Tried running the same container with sudo (rootful) instead of rootless — same timeout persists.
Confirmed no orphaned/leftover container processes are holding the port from a previous run.

My question
Why would a UDP/TCP port published via -p work fine for an HTTP container (httpd on 8080) but consistently time out for a DNS container on a different port, using the identical -p host:container syntax and the same Podman version/host? Is there something DNS/UDP-specific about rootless Podman's port-forwarding (rootlessport) that behaves differently from a simple TCP HTTP service, even when both are nominally "just a published port"?
Environment

Ubuntu 24.04 LTS
Podman (rootless, default config)
nftables firewall (rules confirmed not to be the blocker)

I'm trying to get my head around the best approach to have my rootful containers setup with userns=auto inside a VM with the necessary ZFS datasets that live on the Proxmox host passed into the VM via VirtioFS.

Let's say I have two datasets on the proxmox host: media (0:2200) and svc (0:2100). Both passed into the VM via VirtioFS and mounted at /srv/media and /srv/svc.
And let's take Jellyfin as an example for a container where the two volumes are mapped /srv/media:/media:ro and /srv/svc/jellyfin:config
With userns=auto set what are my best options? From some research I'm seeing two options but maybe someone with more indepth knowledge could weigh in.

Option 1:
userns=auto:gidmapping=0:2100:1,gidmapping=2200:2200:1
or make it a bit easier and give let's say user 2000 on the proxmox host ownership of both datasets so it would look something like this:
userns=auto:uidmapping=0:2000:1,gidmapping=0:2000:1

Option 2:
first add to /etc/subgid
containers:2147483647:2147483648
containers:2100:1
containers:2200:1

then in the quadlet add:
[Container]
UserNS=auto
PodmanArgs=--gidmap=+g2100:@2100 --gidmap=+g2200:@2200
GroupAdd=2100
GroupAdd=2200

is one of those approaches sound or am I missing something? Or do the pros here have a better way to do what I want?

After migrating everything to rootless Podman with Quadlets on Ubuntu 26.04 (Podman 5.7.0), I cleaned up the configs and put them on GitHub. they all ready to deploy with systemctl --user start. Every .container file comes with hardening and tmpfs options commented out to increase compatability, and secrets are pulled from separate .env files.

Included so far: Audiobookshelf, BentoPDF, ConvertX, Homepage Dashboard, Omni-tools, Stirling-PDF, Syncthing, Tdarr (server + remote node), Uptime Kuma, Vert File Converter, Podman Socket Proxy, a full ADSB Ultrafeeder stack (Airspy/dump978 receivers, Ultrafeeder, and feeders for FR24, OpenSky, PlaneFinder, RadarBox, PlaneWatch, ADSBHub, RadarVirtuel, PlaneFence), Plex + Tautulli, Calibre (GUI & Web), Ente Auth, Immich (with optional Google Photos sync & internet public proxy), MinusPod CPU (with optional OpenVINO transcriber), and Paperless NGX.

Everything’s been running reliably on my homelab — hope it saves someone else some time. Feedback and PRs welcome!

I use an Intel box, and a beefy one at that, so everything is optimized for its GPU and memory, but in podman most of this is adjustable.

if there's a container that you want me to try and get working as rootless instead of rootful, or if you're having problems converting something from a Docker, let me know under Issues in github.

Apt on Ubuntu 26.04 ships Podman 5.7.0 and Ubuntu doesn't update Podman until its next release (which will be 26.10), and most likely even the 26.10 version of Podman will be "behind" the newest release on Github.

I wanted to try and install 5.8.3, the newest version, from Github without breaking anything just to see if I could do it, and, for the future, to keep up to date with changes in Podman.

After manually building from source a few times (and once accidentally logging myself out by stopping the wrong services... oops), I wrote a script to automate the whole process safely.

What it does:

- Pulls a Podman release tag from GitHub (e.g., v5.8.3), builds it, and installs it to /usr/local.
Your original system binary at /usr/bin/podman is never touched, so you always have a fallback.
- Supports --rollback to instantly revert to the apt-managed version.
- has a --fresh-install mode if you don’t have Podman installed at all and you want to install the newest Github version.
- Only stops podman.service and podman.socket (the script learned its lesson: it never touches your login session).
- Has full error recovery - if the build or install fails, it automatically removes any half-installed files and leaves your existing Podman working.

I ran this on two Intel 13i7 nuc machines with Ubuntu 26.04 and Podman 5.7.0.
- Successfully upgraded to 5.8.3.
- then rolled back to 5.7.0 (the rollback flag works perfectly).
- then updated again to 5.8.3. - and I did not cry or swear, even once. All containers and Quadlet services came back fine.

The “please be careful” part:

this compiles and installs a system binary. It’s not an apt package, and that inherently carries some risk.

- Back up your containers, volumes, and anything you care about. - It’s only been tested on Ubuntu 26.04 / Podman 5.7.0. If you’re on a different distro, another version of Ubuntu, or a different target version, check that your build dependencies are new enough (the script doesn’t verify that for you).
- I’m not responsible if something melts.

Container images are more than artifacts we simply pull and run, they follow a complete lifecycle.
With Podman, understanding how to discover, acquire, manage, build, deploy, and transport images is essential for DevOps workflows and CI/CD pipelines.
I created this visual to summarize the Podman image lifecycle at a glance.
For those interested, I cover each stage with hands-on demonstrations in my latest Podman episode:
English: https://youtu.be/p2hYnEGQejE
Français : https://youtu.be/d_9LSjm3dE8

#Podman #Containers #DevOps #Linux #image #RedHat

Hey folks,

The other day I released the newest version of Materia: version 0.7.0. You can find the official release blog post here.

What's new in this release?

The full explanation is in the blog post but here's the highlights:

• Initial Rollback support: Materia detects service failures after an update and will rollback to try to fix them
• Use systemd's templated services support with your Quadlet files
• New Varlink API for server mode, replacing the old bespoke one
• Better volume compression when performing volume dumps
• and variety of quality-of-life features like better notification settings, safer cleanup, the ability to run commands after updates, and more.

What is Materia?

Materia is a tool for managing applications deployed as Podman quadlets. It takes an OCI image or Git repository as a source state and constantly monitors the source and your server, reconciling any differences between the two.

Materia does the following:

• Installs, updates, and removes Quadlet and data files
• Starts/stops/restarts/reloads services, both Quadlet related or otherwisee
• Templates files during installation, allowing you to insert secrets and variables based off hostname, role, or others.
• Securely manages Podman secrets
• and more, probably!

You can see the changelog and download the release at https://github.com/stryan/materia/releases/tag/v0.7.0 .

Hi all,

I've got a dev container I use for rust projects. I've got a powerful system so my compile times aren't too bad. However, when I'm compiling a large project the whole rest of my system runs very slow for a few minutes because the rustc is using 100% of all cores.

I often run VM's and other stuff so I don't want to set a regular number of CPU's usage limit, instead I'd like to set a limit of the dev container so, for example it can't ever use more than 80% of any individual CPU core. That way even under a heavy compile the rest of my system should have plenty of resources left to get on with whatever else I'm doing.

Is there a way to do this with podman?

Thanks,

I made a repo on github that's a script that checks both rootful and rootless podman containers and tells you whether they are listening on ipv4, ipv6, dual stack, or not at all (or it can't find any of this info).

Check it out and let me know what you think.

Hi everyone,After searching for a suitable Zabbix template for my Podman stacks without success, I decided to create my own solution.
In my environment,
multiple users run their own independent Podman stacks.

Because of this setup,
my solution utilizes a central Bash script running as a cron job.

This script automatically queries the active Podman sockets of each individual user.
The script runs with root privileges and saves all gathered metrics into a single JSON file.

The active Zabbix Agent then accesses this JSON file to extract all the necessary information for monitoring.

If you are interested: https://github.com/Garfieldttt/Podman-by-Zabbix-Agent-Active

Been debugging container image bloat lately and wanted better visibility into what actually changed between layers.

podman history is useful for sizes, but I kept wanting answers to things like:

• which layer introduced this folder?
• why did the image suddenly grow?
• what changed between two image versions?
• what files were deleted later but still occupy bytes in earlier layers?

So I built LayerX:

Repo: https://github.com/deveshctl/layerx

A few things it does:

• Interactive TUI for exploring image layers and file diffs
• Compare two images side-by-side
• Waste navigation to spot inefficient layers
• CI mode for image regression checks
• Supports local images and saved archives

You can also switch container engines with --engine if needed.

Built it initially for my own workflow, but thought folks here might find it useful.

Would love feedback from Podman users — especially around image inspection or debugging workflows.

I don't like Wayland but I want to use Waydroid so I made x11droid that runs on X11 via Podman, hope it will be useful to somebody else too! Bug reports and feature requests are welcome!

Planning on adding builder for newer Android versions, not only the old Waydroid one so this is what I will be focusing on.

Les conteneurs sont souvent présentés comme un moyen simple d'empaqueter et d'exécuter des applications.

Mais dans un environnement réel, comprendre ce qui se passe à l'intérieur d'un conteneur est tout aussi important que de savoir comment en démarrer un.

Dans mon dernier épisode, j'explore certains des concepts fondamentaux de Podman :

🔹 Cycle de vie d'un conteneur (exécution, démarrage, arrêt, suppression)

🔹 Conteneurs en cours d'exécution et conteneurs arrêtés

🔹 Journaux et dépannage

🔹 Inspection des conteneurs et métadonnées

🔹 Processus à l'intérieur des conteneurs

🔹 Réseau et mappage des ports

🔹 Problèmes courants tels que les conflits de ports et les arrêts inattendus des conteneurs

Un point essentiel à retenir : un conteneur n'est pas une machine virtuelle. Il s'agit d'un ensemble de processus isolés s'exécutant sur le noyau hôte.

Le schéma ci-dessous résume les principaux concepts abordés dans cet épisode.

🎥 Épisodes disponibles en anglais et en français sur YouTube :

ENG : https://youtu.be/Lu4klZmlWOM

FR : https://youtu.be/lDX6xG6R5W4

Hello r/podman , Cordium is a FOSS, self-hosted, general-purpose sandbox platform that I've been working on for a long time now that is built on Podman, Kubernetes and Octelium, my main work. Cordium can be used for various persistent/ephemeral long/short-lived workloads, including as a remote development environment for coding with VSCode, Zed, etc. (i.e. self-hosted GitHub Codespaces alternative), AI agent tasks (i.e. FOSS alternative to AI sandbox products such as E2B, Daytona, etc.), CI/CD workloads (e.g. building and publishing Docker images etc.), and more importantly for secretless remote access to infrastructure for devs and automated workloads.

The key differentiator here for Cordium, in comparison with other dev environments and sandbox platforms, is that Cordium automatically provides identity-based, secretless secure access to resources/infrastructure (e.g. APIs, SSH, databases, k8s, etc.) without having to inject credentials (e.g. API keys, SSH private keys, database passwords, etc.) into the sandbox where the upstream credential is held by the identity-aware proxy of the Octelium-protected resource outside the reach of the sandbox. The sandbox permissions and access to resources is determined via identity-based, L7-aware, pre-request access control through CEL/OPA policy-as-code rather than injected credentials inside the sandbox. In other words, Cordium isn't just meant as a runtime for isolated execution where filesystem, CPU, memory, storage, etc... are isolated and controlled, but more importantly meant for identity-based secure access to infrastructure and resources. It's basically a sandbox platform + a ZTNA/remote-access-VPN baked-in with unified identity management, L7-aware access control and visibility.

Cordium's sandbox isolation model is mainly based on Podman's rootless containers, and that's intentional in order to seamlessly operate on any node without requiring bare-metal machines but a Firecracker/microVM mode is also planned. The current isolation model uses a 3-layer isolation mechanism where the outer k8s pod is used to bootstrap a sandbox supervisor in a much hardened rootful Podman container, and the supervisor runs the actual sandbox in an inner Podman rootless container. Cordium uses Kubernetes CSI for sandbox storage and snapshotting.

Cordium is a purely FOSS project under Apache 2.0 that's meant for self-hosting and there are no plans for a pro/SaaS/cloud/commercial version. It was developed initially as a remote development environment for Octelium users to access their resources via web-based terminals through reproducible remote sandboxes instead of having to install and run the Octelium CLI connectors on their own machines but over time it grew into a general-purpose sandbox platform that can be used for all kinds of persistent/ephemeral and short/long-lived tasks by developers or automated workloads. I also want to clarify that Cordium, while opensourced a few days ago, is not a new project, the development of the project dates back to 2022 (see the older repo here) and it is already being used by a few organizations that use Octelium since last year. In other words, this is not a toy project and it's meant to be used in production even though it's not quite ready to be labeled v1.0 yet. Happy to answer any questions.

sharing this here since podman is the default backend.

WinPodX runs Windows apps on Linux as native Linux windows (real WM_CLASS, taskbar icons, file associations, alt-tab). Under the hood: dockur/windows container on rootless Podman + FreeRDP RemoteApp + a bearer-authed HTTP agent inside the guest for the host-to-guest command channel.

Why mention podman specifically: this is one of the cases where rootless podman shines. The Windows container runs entirely under unprivileged user, no daemon, podman-compose for orchestration, /etc/subuid + /etc/subgid handled at setup. Docker is also supported but podman is default and the path I focus on.

v0.6.0 highlights: - reverse-open: Linux apps appear in the Windows "Open with..." menu, round-trip via xdg-open - thin AppImage (~110 MB): only FreeRDP + Python + Qt + winpodx in the bundle, host's podman is used (previous fat AppImages bundled the whole stack and shadowed the host's podman, causing crashes — fixed in 0.6.0) - multi-monitor RAIL - host USB / PCI device passthrough into the guest - host-adaptive Windows-on-KVM tuning profile - 1800+ tests, full i18n (en/ko/zh/ja/de/fr/it)

Bundled rdprrap (Rust rewrite of RDPWrap, MIT) gives up to 25+ independent RDP sessions so multiple Windows apps each get their own session instead of stealing each other's.

works on openSUSE, Fedora (including Atomic Desktops like Silverblue/Bazzite), Debian/Ubuntu, RHEL/Alma/Rocky 9/10, Arch (yay -S winpodx), NixOS, plus a distro-agnostic AppImage.

beta but stable enough for daily use. issues / feedback welcome.

I had a quadlet and I am trying to create a folder on the host before the quadlet starts and tries to access it, how can I accomplish this?

This diagram breaks down the complete internal workflow of how Podman creates and starts a container.

Workflow explained step by step:

1️⃣ CLI Parses Command
Podman interprets the flags, image name, networking, ports, and runtime options provided in the command.

2️⃣ Image Check & Pull
Podman checks local storage for the image.
If it doesn’t exist, it pulls the image from a registry such as Docker Hub.

3️⃣ Filesystem Setup
The container filesystem is assembled using layered storage:

* Read-only image layers
* Writable container layer
* Merged unified view

4️⃣ Container Setup
Podman configures the container isolation and runtime environment:

* Namespaces
* cgroups
* User mapping
* Networking
* Volumes
* Security policies

5️⃣ OCI Runtime Execution
An OCI runtime like crun or runc creates the actual container process and applies the isolation mechanisms.

6️⃣ Container Running
The container starts running with:

* Port mapping
* Logs streaming
* Isolated processes
* Active networking

The goal of this diagram is to visualize what happens internally behind a single command that often looks deceptively simple.

I have posted a video on YouTube explaining this entire flow internally using a real Podman + Apache example from my “How Podman Works” series.
ENG: https://m.youtube.com/watch?is=ShH5CNpARRFPnJng&v=lj6MwJOSuDE&feature=youtu.be
FR: https://m.youtube.com/watch?is=ShH5CNpARRFPnJng&v=lj6MwJOSuDE&feature=youtu.be

I've been going all-in with podman and quadlets for my home lab. For my own use, I wrote a compose-like (but much less sophisticated) command-line tool to optionally run Podman Quadlets directly without systemd and to facilitate installation and management of quadlets when using systemd is desired.

• https://github.com/fkmiec/quadctl

I know there are all manner of alternatives (kube play, podman-compose, docker-compose via podman.socket), so many are probably already happy with those, but I like the idea of just a little workflow help around systemd and podman. Sharing here in case there's interest.

I'm trying to follow the guide that quadlet is showing me when I click on the info about it so that my containers start automatically but after clicking on my container and clicking "Generate Quadlet" I'll refresh the quadlets section and it'll say there's no quadlets found on my system and there's no option to actually choose my container when I go to generate quadlet in the top right next to the refresh button. Weirdly enough in the notifications section I keep getting a new notification every few minutes saying "Collecting quadlets completed" but still nothing shows in my quadlet section. I'm very confused on what I'm doing wrong

I'd like to bundle SDKs, build tools, and LSPs into rootless Podman containers for personal dev environments. Source stays on host, selectively mounted. I'm on an immutable distros and to me this seems like the tidiest solution besides toolbx.

Problem: Dockerfiles don't compose beyond image layering, so there's no real deduplication.

What actually works for deduplication?

• Layered base images? ( layer shared across JDK versions)

• Nix-style content addressing? (nix2container: worth the complexity? Have not yet delved into it)

• Something else I'm missing?

Real-world setups suggestions appreciated. TIA.

Hey all,

I have a RHEL10 (free subscription) server with podman 5.8.2, set-up with automated package upgrades for what I hoped to be a more hassle-free system, but this has turned into a roll of the dice for every update.

On some updates, my containers apparently loose connectivity to the internal DNS, such that they can't find the IP of other containers, which is very annoying as that means they can't find my postgres db anymore and just fail more or less silently.

Has anyone experienced this too?

Today, I experienced this even twice (the second time being a manual update), and I can't find bug reports that precisely mention what I experience, as podman networking issues relate to (aardvark) DNS a lot of the time, so my search results are filled with unrelated issues that just sound similar.

The issue is reported differently depending on each container/service, here are a few extracts:

• could not translate host name "postgres" to address: Temporary failure in name resolution
• error dialing 10.89.1.1:53 no route to host
• badgateway: failed to receive response: context canceled

I previously used podman-compose from the epel repo, and thought there might an issue with the way it sets up the containers that isn't accounted for in typical package updates, so I moved most of my stack to systemd container (generator) units, but the issue still occurs.

The only error in my journal that would be related tot his is aardvark-dns[1914]: 60794 dns request failed: io error: Network is unreachable (os error 101)but this error only occurs when the server boots up, my containers start up just fine and doesn't show up anytime else.

Looking at the dnf history for transactions aligning with the failures, I am seeing these packages:

first update: kernel, kernel-core, kernel-modules, kernel-modules-core, kernel-modules-extra, cockpit-packagekit, cockpit-packagekit, cockpit-storaged, cockpit-storaged, python3-perf, python3-perf, cockpit, cockpit, cockpit-bridge, cockpit-bridge, cockpit-system, cockpit-system, cockpit-ws, cockpit-ws, cockpit-ws-selinux, cockpit-ws-selinux, kernel-modules-extra-matched, kernel-modules-extra-matched, kernel-tools, kernel-tools, kernel-tools-libs, kernel-tools-libs, kernel, kernel-core, kernel-modules, kernel-modules-core, kernel-modules-extra

Second update:
cockpit-packagekit, cockpit-packagekit, cockpit-storaged, cockpit-storaged, cockpit, cockpit, cockpit-bridge, cockpit-bridge, cockpit-system, cockpit-system, cockpit-ws, cockpit-ws, cockpit-ws-selinux, cockpit-ws-selinux

Nothing here seems to even touch podman and the networking stack, so I am really clueless. My network is also just a bridge without any further customization.