thats the issue you cant seperate these things.
people not just load that one plain simple docker file
they will relentless copy paste github the nastiest composefile they stumble on
and nothing will work
the things you mention are just a tiny subset what docker does. implementing this is not only ugly (and still barely mangeable) but it would make look proxmox bad.
besides features are expensive, no not in terms of money and time (that too) but in terms of other cost.
like bloat, complexity, time to learn the product
so proxmox ahs to be careful what to implement and weight a cost to result ratio.
theres a reason why proxmox has no built in wireguard management.
@bofh seriously, I’m with you on the dangers. Layer bleed, compose expectations, and host networking landmines are real. That’s exactly why I’m
not asking PVE to expose containers, parse compose, or touch guest networking at all. MVP only, explicitly scoped.
What I’m proposing is smaller than "features," and cheaper than support debt we already see:
- a Container‑Host VM preset (just a cloud‑init snippet with sane defaults for containerd/Docker and overlay2 on ZFS≥2.2/xfs),
- a single optional External Manager URL on a VM that renders one "Open Manager" button (Portainer/K8s dashboard lives in the VM), and
- a clear “no Docker on the node” banner with a one‑click path to create that VM instead.
No Docker on the host, no container introspection, no compose UI, no scheduling semantics. It’s a paved road for the
right pattern and a hyperlink - nothing that makes PVE look responsible for app‑level behavior. Net effect: fewer "I broke my node with Docker" threads, faster on‑ramp for small teams, and zero bloat to core PVE concepts. If even the button feels too much, start with
template + docs only; the win is still there.
I'm talking about an onramp to give a defined path and to begin exploration to see if this makes sense as time progresses.
what an inetresting thread from the pre Aug 2025 confusion that unprivilieged containers running as root in docker run as root (they don't, and anyone who thinks they do has likely forgotton or never realized group and user masks are not a secuity boundary, it why ACLs are more secure)
to this recent conversation on docker
for me (and i am a voice on 1 i get that) proxmox is a hypervisor with the interesting but not that compelling LXC thing tacked on (with a secuity model that is barely better than docker).
- i agree with the assertion that adding docker to the core platform is a lot of work
- i don't agree that the issues with docker networking that folks have articulated are make or break - they can be mitigated and resolved (proof point trunas apps that use docker) - but see point #1 - lot of work... i am not sure it is worth it and I am huge advocate of docker
- I agree that for those that want to use docker in a well behaved way that doesnt tatto the platfom with crud a community script would be useful, i would advocate that could achieve what was asked for by bootstrapping a docker VM and installing portainer CE in it and using virtiofs to surface a bind mount location of the users choice (this is how i do it)
- i don't agree #3 implies the interface has to be in the proxmox ui
i won't pretend to understand what proxmox's paid customers want and how that should inflluence what home labbers want, i do have a preference that promxox is a stable and full features hypervisor first and foremost
of course if the people who wanted docker in the proxmox platform and created PRs that did that and solved all the issues with networking, i am sure they would get considered /s ... sort of ...
@scyto I’m with you on not dragging Docker "into core," and I agree the networking pain is solvable -
inside a VM. What I’m proposing is basically to
codify the good path you already use with the smallest possible change set, shipped as an MVP, not a feature bucket:
- Phase 0 (docs only): An official "don’t run Docker on the node" guardrail with a one‑click link to create a container‑host VM, plus published cloud‑init snippets (containerd/Docker, cgroup v2, overlay2 on xfs/ZFS≥2.2).
- Phase 1 (preset): A first‑class Container‑Host VM preset that’s just GUI sugar over those snippets. No container UI in PVE, no compose parsing, no scheduling, no guest‑networking tweaks.
- Phase 2 (optional nicety): A single External Manager URL field on that VM that renders an "Open Manager" button. If you point it at Portainer running in the VM, great; if not, nothing appears.
On storage: I’m fine with
virtiofs if folks understand the HA/backup semantics, but I’d actually prefer a
dedicated vdisk (or NFS/CephFS) for Docker data to keep PBS and migration clean. On networking: keep all Docker networks
inside the VM; if people need macvlan/ipvlan or to disable Docker iptables, that’s their lane - PVE doesn’t touch it.
This isn’t gate‑keeping; it’s a
paved on‑ramp for newcomers that reduces forum breakage, while leaving power users with Ansible/Terraform exactly as-is. If the community wants to PR Phase 0/1 (snippets + preset) first, even better. If adoption is weak, we stop there; if it’s strong, we can discuss whether Phase 2+ is worth it. Boundaries intact, friction down.
This is the part I don't get. Any sysadmin worth his salt should be able to setup such a thing. I mean I udnerstand that it might be useful to have something like a template for a docker+portainer vm for homeusers. But to be honest ProxmoxVE isn't the best plattform for people who "just want to run some self-hosted services without becoming a sysadmin". A NAS OS with docker and/or VM support is way more suited for that usecase. UnRaid or other NAS OSes obvivouvsly have less features and flexibility than ProxmoxVE. But imho for most homeusers this flexibility and features are not really needed and the additional complexity of administrating PVE not really worth it.But things that "just work" are less suited for generating clicks and revenues for youtubers so here we are ¯\_(ツ)_/¯
@Johannes S sure, any competent admin can roll a Docker+Portainer VM. The value here isn’t capability, it’s
consistency and guardrails. A blessed cloud‑init preset and a one‑click link reduce support noise, shorten onboarding for SMBs and mixed teams, and steer newcomers away from host‑level Docker without turning PVE into a PaaS. AND it tests community interest/participation so it's a win-win for the Proxmox dev team and community.
Think of it like the Ceph/PBS touches PVE already offers: Proxmox stays a hypervisor, but gives a paved road to the tooling most shops actually use. Folks who want Unraid/TrueNAS can absolutely go there; many of us deliberately choose PVE + VMs for isolation, backups, and HA while still living on/handling OCI images.
This proposal serves both camps without bloating core.
I'm more like: If you want an easy way to spin up a service without needing to know the more technical bits this is a solved problem with docker-compose or podman, combined with something like portainer or dockge or your NAS WebUI docker panel if you prefer an UI. The community-scripts are an impressive piece of work but quite tragically one not needed imho since we have already docker. I mean onat work we have some self-written shellscript in our VM template for new Linux VMs which does the initalization at first boot. It does the job but we are at point where we basically have reinvented cloud-init just with extra-steps, less features and more problems. So I will get rid of it as soon as possible and replace it with the standard tool for the job (cloud-init). So my gate-keeping is not about gatekeeping at all, I love that people get empowered to do things on old hardware without needing expensive cloud subscriptions or vendor lockin. But for me empowerment means getting to know how to do things and why you do things not learning how to use a hammer and a nail for everything.