Like the known Docker "feature" that it completely bypasses UFW and unless your ports look like "- 127.0.0.1:PORT:PORT" (and many of the examples use "-PORT:PORT") you expose everything to the internet?
This is not a "feature", it's just a by-product of how iptables works. The alternative would be to have a proxy run in userspace, instead of letting the kernel forward packets
My understanding is that docker will expose the ports to the host machine's network interfaces, which is a crucial difference. For my home server running docker that means exposed to the LAN, but not the WAN unless I add in a port forwarding rule on my router. Similarly in an enterprise environment you would be exposing the port on whatever VLAN the host is connected to, which hopefully doesn't have directly transit to the open internet.
Anything you're running on the perimeter with open access to the internet in an enterprise environment probably (hopefully) isn't running docker containers without some additional config and protections.
I was thinking along similar lines to what you've suggested here, but then I considered how many VPS might be configured by folks following some random web tutorial, to set up their LAMP stack (or whatever), that end up doing something like what was described.
A lot of those VPS instructions these days recommend a reverse proxy like Caddy or Traefik for that exact reason. I think it's also a valid argument to say that anyone playing around on a VPS without knowing what they're doing is probably going to learn some hard lessons, and that's kind of the point.
It's not a routing issue, it's a firewall issue. Make sure you have a proper firewall on your network and don't rely on fake firewalls like ufw if you're concerned about this.
Again, if your router or perimeter devices are appropriately managing your network then it's a non-issue. By default most home routers have IPv6 disabled, and if you're setting up an enterprise environment with a VLAN you're probably subnetting IPv4 instead of using IPv6 at all.
All that means that if you're using IPv6 then you're proactively enabling it on whatever is handling your perimeter, which means you hopefully know what you're doing along with all the gotchas that come with that setup.
This was not always true and running rootless has been a benefit of Podman for a long time. Docker also does not run rootless by default afaik, thus making the attack surface greater by default.
The other main improvement of Podman over Docker is that Podman is daemonless and therefor is incredibly lightweight and portable.
Inertia I guess... We try. I managed to remove it everywhere in our stack in CI and such but in dev everyone is used to docker build.
And I don't have the energy for the team meeting to discuss a change.
And honestly docker compose has been ridiculously stable for us. 2+ services on seperate servers behind haproxy has been as stable as our Kubernetes Cluster for a fraction of the (intellectual) cost.
I mean, if you have zero experience with systemd, then yes. By contrast, if you've ever worked with any systemd unit files at all, then all the "systemd stuff" will be very familiar.
Which, if you're doing sysadmin type things on almost (e.g. not Alpine) any mainstream Linux distro in 2026, you should expect to encounter systemd unit files in your day-to-day.
I'm sorry but this is all just apologism/excuses. Docker's had rootless mode for 7 years. The attack surface is the local system, which always has a privilege escalation vuln of some kind, so Docker isn't a game-changer. And lightweight? I have never heard someone say "that Docker daemon is hogging all my resources".