Docker on Proxmox, without the network pain
Docker itself is easy; its networking is the hard part. Containers hide behind NAT, macvlan leaves the host unable to reach its own containers, and getting an IP from the router turns into a project of its own. Atlas untangles this with Atlas Link: every container lives on the network like a real device. On top of it comes a curated Docker library: pick, install in one click, live instantly.
The familiar headaches
NAT darkness: the container runs but is invisible on the network. Every service is reached through port forwards, and the collisions have to be managed by hand.
The macvlan trap: try to give a container a real IP and the host can no longer reach its own container. The forums are full of this question.
DHCP mismatch: pulling an IP from the router is not Docker’s natural behavior. On restart the address drifts, there is no DNS name, and the “which IP was that on” game begins.
Atlas Link: every container a real LAN device
Atlas Link makes containers a natural part of the local network:
A real DHCP IP from the router
Every container reaches the network with its own MAC; the router hands out its IP and it shows up in the device list like everything else.
Reach it by name: service.local
Every container announces its name over mDNS: jellyfin.local, pihole.local. Memorizing IPs is over.
Host isolation solved
The classic macvlan “host can’t reach its container” trap does not exist in Atlas Link; the host talks to its containers normally.
Identity holds across restarts
Even when a container restarts, its network identity is preserved; Atlas keeps address drift in sync.
A curated Docker library
No writing compose from scratch: selected apps install in one click and go live instantly through Atlas Link:
Every app arrives version-pinned and reviewed; no surprise image changes.
A resource summary before install: how much RAM, how much disk, which network identity. Confirmation comes first, then the install.
A restore point is taken before install; if the result disappoints, the rollback leaves no trace.
An existing compose file is first-class too: bring it, connect it to Atlas Link, same comfort.
VM or LXC?
The clean way to run Docker on Proxmox is a full VM: its own kernel, full isolation, the officially supported path. Docker inside LXC is possible but nested isolation weakens. Atlas manages the Docker host from install onward; it appears on the map like everything else.
Frequently asked questions
- Does the container really get an IP from my router?
- Yes. Atlas Link puts the container on the network with its own MAC; the DHCP server hands out the IP and it appears in the router’s device list. A static reservation can also be set from the router.
- Does the macvlan “host can’t reach the container” problem exist here?
- No. Atlas Link solves that isolation at the bridge layer; the host and containers see each other normally. It is the best-known pain of a classic macvlan setup, and Atlas Link exists precisely for it.
- Can I reach services by name?
- Yes. Every container announces its name over mDNS; devices on the network reach addresses like jellyfin.local. No memorizing IPs, no manual DNS entries.
- Should I run Docker in a VM or an LXC on Proxmox?
- A full VM. With its own kernel and full isolation, that is the officially supported path; Docker inside LXC weakens nested isolation. Atlas manages the Docker host VM from install onward.
- Do I still need something like Portainer?
- Since the library, lifecycle and network identity are in Atlas, most of the time it is not needed. Portainer can still run alongside; they do not conflict.
- Can I use my own compose files?
- Yes. An existing compose file comes as it is; Atlas Link adds the network identity and .local name, and it runs with the same comfort as library apps.
Related entries
- Giving a container its own address on the network: what you gain, what you pay You can publish a container by its own address instead of a port number. The gain is real and so is the price, and the second one is usually discovered after it is built.
- The container changed by itself: what the "latest" tag actually promises You updated nothing, yet the container behaves differently. That is not a fault: latest is not a version, it is a pointer. The real issue is not getting the newest, it is being able to go back.
- Where Docker belongs on Proxmox: the placement decision and the compose trap Where you put containers is not a matter of taste, it is a matter of blast radius. And a compose file looks like configuration when it is in fact a program you run.