Can a bad change lock me out?

That is the exact case Atlas guards. Risky changes keep a way back; a configuration that cuts management access does not become permanent.

Does Atlas replace the interfaces file?

No. Atlas manages the same Proxmox networking underneath; the file stays the source the host boots from. Atlas edits it through guided, checked flows.

Yes. VLAN aware bridges and per guest tags are shown on the map and editable in the flows, with overlapping segments visible.

Does it handle bonds?

Yes. Bonds and their member NICs are drawn and managed, and the chain from bond to bridge to guest is visible as one line.

Does it work alongside the Proxmox UI?

Yes. Nothing is forked or hidden; a change made in Atlas is ordinary Proxmox networking, and the PVE UI keeps showing the same truth.

Does my network layout leave the host?

No. The map is drawn locally on the host. Names, addresses and the details of the topology are not sent anywhere. When the optional usage statistics setting is switched on, only aggregate counts go out; the full content is listed on the Privacy screen inside the product.

Proxmox networking without the lockout fear

Network changes carry the scariest failure mode on a remote host: one wrong bridge edit and the connection that carries the fix is gone. Atlas draws the network as a live map, shows what a change touches before it is applied, and keeps a way back open when a change goes wrong.

Why network changes feel risky

Proxmox networking is edited as text: bridges, bonds and VLANs live in an interfaces file, and the picture of what connects to what stays in the admin’s head. The screen that applies the change does not show which guests ride on the bridge being changed.

The failure mode is absolute. A typo in a bridge or a wrong VLAN tag does not degrade the host politely; it can drop the SSH session, the web UI and every guest at once, and the fix then requires physical access or a console.

So teams freeze their network config, postpone cleanups, keep dead bridges around. Not because the changes are hard, but because the cost of one mistake is a drive to the server.

The careful way to change networking by hand

Without tooling, a safe network change is a small ceremony:

Map which guests, bridges and physical NICs are involved before touching anything.

Prepare the change in the interfaces file and read it twice; a missing line takes the host down.

Schedule a maintenance window, because a mistake cuts management access too.

Keep a separate console ready in case the SSH session dies with the change.

Apply, then race to confirm the host and every guest came back reachable.

Write down what changed, because the next person cannot read the topology from the file.

How Atlas changes the picture

Networking stops being a text file and a prayer; it becomes something drawn, checked and reversible.

The network as a live map

Bridges, bonds, VLANs and physical NICs are drawn with the guests riding on them. What connects to what is read from the screen, not reconstructed from a file.

Bridges, bonds and VLANs in one flow

Creating and editing bridges, bonds and VLAN aware setups runs through guided flows, with the resulting layout visible as it will be.

Impact before apply

Before a change is applied, the affected guests and interfaces are listed. A bridge edit that would touch twelve guests says so first.

Lockout protection

Risky network changes keep a way back: if the new configuration cuts the host off, it does not become permanent. The drive to the server stays unnecessary.

Guest connectivity, visible

Each guest NIC, its bridge, its VLAN tag and its state are visible in one place, so network debugging starts from the map instead of from qm config.

OVS and STP, readable

Open vSwitch setups and spanning tree state are presented in topology language, so advanced layouts stay as readable as simple ones.

Frequently asked

Can a bad change lock me out?: That is the exact case Atlas guards. Risky changes keep a way back; a configuration that cuts management access does not become permanent.
Does Atlas replace the interfaces file?: No. Atlas manages the same Proxmox networking underneath; the file stays the source the host boots from. Atlas edits it through guided, checked flows.
Are VLANs supported?: Yes. VLAN aware bridges and per guest tags are shown on the map and editable in the flows, with overlapping segments visible.
Does it handle bonds?: Yes. Bonds and their member NICs are drawn and managed, and the chain from bond to bridge to guest is visible as one line.
Does it work alongside the Proxmox UI?: Yes. Nothing is forked or hidden; a change made in Atlas is ordinary Proxmox networking, and the PVE UI keeps showing the same truth.
Does my network layout leave the host?: No. The map is drawn locally on the host. Names, addresses and the details of the topology are not sent anywhere. When the optional usage statistics setting is switched on, only aggregate counts go out; the full content is listed on the Privacy screen inside the product.

Related entries

I wrote a firewall rule and nothing happens: the three level switch The Proxmox firewall is switched on at three levels, and a rule does nothing unless all three are on. The most common situation is a correct rule sitting under a switch that is off.
I changed the network settings and lost access: sawing the branch you sit on Network configuration is applied over the very connection you are using to apply it. A small mistake cuts the connection at the moment of applying, and without a prepared way back you need physical access.
Separating with VLANs: one cable, several networks, and where the tag sits The point of separation is to limit how far a bad day can reach. A VLAN does this over one cable, but where the tag is applied and whether the bridge is allowed to carry tags can go wrong silently.
A virtual machine has no network: looking in the right order Most people start the search inside the machine, which is the last place to look. The chain has four links, and the symptom tells you which one is broken.