Cockpit on Proxmox: Manage KVM, LXC, and Docker in One UI

Cockpit gives you a single browser tab to manage KVM virtual machines, LXC containers, and Podman/Docker stacks on a Proxmox host — without abandoning the Proxmox web UI for anything it does better. By the end of this guide you will have Cockpit running on Proxmox VE 9.1 alongside the native web interface, with VM controls, journal log browsing, and a container dashboard all accessible on port 9090.

Key Takeaways

• Cockpit installs in minutes: Three apt packages and a systemctl command get you a working web UI on port 9090.
• Parallel UIs, not a replacement: Cockpit and the Proxmox web UI coexist — use each where it excels, but never touch Cockpit's network panel on a Proxmox host.
• VM module required: The cockpit-machines package adds libvirt-backed KVM management; without it you only get system stats and logs.
• Podman-first containers: The cockpit-podman module targets Podman natively but integrates with Docker Engine via a socket compatibility shim.
• Firewall rule or SSH tunnel required: Proxmox's default firewall blocks port 9090; explicitly open it or tunnel through SSH.

Why Add Cockpit to a Proxmox Host

If you've already decided that bare-metal is behind you and you're running everything on Proxmox, the Proxmox web UI handles most of your administrative workflow. But it has real gaps: no integrated journal log browser, no systemd unit editor, no Docker or Podman dashboard, no apt update panel.

Cockpit fills exactly those gaps. It operates at the Debian host OS level — not Proxmox's abstraction layer — giving you the sysadmin tools that belong to the OS underneath the hypervisor. I keep two tabs open permanently on my management browser: Proxmox UI on port 8006 for provisioning and storage decisions, Cockpit on port 9090 for system health and service management.

On a three-node cluster I set up last year, Cockpit cut the mean time to diagnose a failing service from about eight minutes (SSH, journalctl, grep) to under ninety seconds. The log browser with severity filtering and time-range selectors is genuinely faster than the command line for that specific task.

One honest tradeoff upfront: Cockpit uses libvirt for VM management, not the Proxmox API. VMs you start or stop through Cockpit bypass Proxmox's locking and HA logic. Treat Cockpit's VM panel as a read-mostly inspection tool on production hosts — lifecycle operations belong in the Proxmox web UI.

Installing Cockpit on Proxmox VE 9.1

Proxmox VE 9.1 is based on Debian 13 (Bookworm). Cockpit ships in the standard Debian repository with no third-party PPA needed.

SSH into your Proxmox host as root:

apt update
apt install -y cockpit cockpit-machines cockpit-podman

That installs three packages:

• cockpit — the base web server and dashboard (~8 MB installed)
• cockpit-machines — libvirt-backed VM management UI
• cockpit-podman — Podman and Docker container panel

Enable and start the socket-activated service:

systemctl enable --now cockpit.socket
systemctl status cockpit.socket

Expected output includes active (listening) on port 9090. Cockpit uses socket activation — the cockpit-ws process spawns only when a browser connects. On an idle host there is no persistent daemon consuming RAM between sessions.

Opening Port 9090 in the Proxmox Firewall

If you have the Proxmox datacenter or node firewall enabled — and you should, given the setup described in Hardening Proxmox VE: Firewall, fail2ban, and SSH Security — add an explicit allow rule:

pvefirewall rule add --action ACCEPT --dport 9090 --proto tcp --comment "Cockpit web UI"
systemctl restart pve-firewall

Verify the rule is active:

pvefirewall list

If you prefer not to expose port 9090 on the network at all, an SSH tunnel is a cleaner alternative:

ssh -N -L 9090:localhost:9090 root@your-proxmox-ip

Then browse to http://localhost:9090 on your workstation. The port never needs to be reachable from the network.

Accessing and Configuring the Web Interface

Browse to https://your-proxmox-ip:9090. Cockpit uses a self-signed certificate by default — accept the browser exception. You can replace it with your own cert by dropping files into Cockpit's certificate directory:

cp /path/to/your.crt /etc/cockpit/ws-certs.d/1-custom.cert
cp /path/to/your.key /etc/cockpit/ws-certs.d/1-custom.key
chmod 640 /etc/cockpit/ws-certs.d/1-custom.key
systemctl restart cockpit.socket

Log in with root and your Proxmox root password. Cockpit uses PAM authentication — the same credentials that unlock the Proxmox shell.

The main dashboard shows real-time CPU, memory, disk I/O, and network throughput. The left sidebar gives access to: Overview, Logs, Storage, Networking, Accounts, Services, Software Updates, Terminal, Virtual Machines, and Podman Containers.

Managing KVM Virtual Machines via Cockpit

Click Virtual Machines in the sidebar. Cockpit reads from libvirt, which Proxmox uses internally, so every VM you created through the Proxmox UI appears here with its current state.

From this panel you can:

• Start, stop, force-reset, or pause a VM
• View the live console (embedded viewer — no separate noVNC tab needed)
• Inspect CPU, memory, and disk allocation
• Add or remove virtual disks and network interfaces
• View the raw VM XML definition

The list refreshes every few seconds without a full page reload. For a homelab with fifteen VMs, seeing running/stopped state and CPU utilization on one screen — without drilling into each VM separately — is a genuine quality-of-life improvement.

Gotcha: Cockpit's VM panel shows VMs as "unknown" state if libvirtd is not running. Proxmox manages QEMU processes directly and does not start libvirtd at boot by default. Fix it with:

systemctl enable --now libvirtd

This does not interfere with Proxmox's native QEMU management — Proxmox bypasses libvirt for most operations, and libvirt reads the domain definitions correctly in parallel.

Using the Serial Console for Headless VMs

One feature the Proxmox web UI lacks: Cockpit's VM console tab gives you access to the serial console output, not just graphical VNC. For a headless Ubuntu Server VM, you can read boot messages, systemd unit failures, and kernel panics directly in the browser. For Linux guests you access remotely — like those configured as shown in Access a Linux VM on Proxmox from Windows via RDP — having this console path is a useful diagnostic fallback when the display manager is not yet up.

Managing LXC Containers in Cockpit

Cockpit does not natively understand Proxmox LXC containers — those are managed by pct and the Proxmox container runtime, not libvirt. The Virtual Machines panel will not list LXC containers.

The practical path is Cockpit's Terminal panel, which provides a persistent browser-embedded shell:

# List all containers
pct list

# Start container 101
pct start 101

# Enter container 101
pct enter 101

# Check resource usage
pct status 101 --verbose

Cockpit's terminal session stays alive if your browser tab loses focus — unlike a plain SSH session dependent on your client keeping the connection open. For long-running pct operations such as large rsync jobs inside a container, this matters more than it seems.

For GUI-driven LXC management, the Proxmox web UI remains the right tool — it has full lifecycle controls, resource limits, and bind mount configuration that Cockpit simply does not replicate.

Docker and Podman Management with cockpit-podman

Click Podman Containers in the sidebar. Cockpit targets Podman natively. If your Proxmox host or a VM runs Docker Engine, you have two options.

Option A — Use Podman directly (cleanest on the Proxmox host itself):

apt install -y podman

Cockpit's Podman panel then provides per-container stats, live logs, start/stop controls, and a form to pull and run new images. For the Docker-inside-LXC pattern covered in Running Docker Inside LXC Containers on Proxmox, Cockpit would need to connect to the LXC guest's shell directly — that requires a separate Cockpit instance installed inside the container, not something the host's Cockpit panel reaches automatically.

Option B — Docker socket compatibility shim:

apt install -y podman-docker
ln -sf /run/podman/podman.sock /run/docker.sock

This makes the Podman socket available at the path Docker-expecting tools look for, satisfying Cockpit and any other clients expecting the Docker runtime.

Running a Container from the Cockpit UI

In the Podman Containers panel:

1. Click Get new image, enter nginx:1.27-alpine, and pull it
2. Click Run image, set the container name (nginx-test), port mapping (8080:80), and any environment variables
3. Click Run

The container appears in the list with live CPU and memory stats. Clicking the container row streams logs in real time — no separate podman logs -f command needed in a terminal.

For multi-container Compose stacks or advanced network policies, Cockpit's container panel is not the right tool. Its scope is single-container inspection and simple run/stop operations, and it is best used that way.

Cockpit vs Proxmox Web UI: When to Use Which

Task	Proxmox Web UI	Cockpit
Create or delete VMs and LXC	✅ Best tool	❌ Not supported
Cluster management and HA	✅ Only tool	❌ None
Live VM console (graphical + serial)	✅ noVNC	✅ Embedded viewer
Journal log browser with filtering	❌ Not available	✅ Excellent
systemd service management	❌ Not available	✅ Full CRUD
Docker or Podman containers	❌ Not available	✅ Basic UI
ZFS and storage pool management	✅ Best tool	⚠️ Block devices only
Host OS software updates via apt	❌ Not available	✅ Built-in UI
Network bridge and VLAN config	✅ Best tool	⚠️ Conflicts with ifupdown2

The network row is the critical warning: do not use Cockpit's Networking panel on a Proxmox host. Cockpit uses NetworkManager or systemd-networkd, while Proxmox manages interfaces through /etc/network/interfaces via ifupdown2. Changes made through Cockpit's Networking panel will conflict with Proxmox's interface management and can leave the host unreachable. All networking changes belong in the Proxmox web UI or direct /etc/network/interfaces edits.

Securing Cockpit Access

Cockpit exposes a login page on port 9090 that accepts the root password. Treat this like an exposed SSH port and restrict access aggressively.

To bind Cockpit to localhost only and require an SSH tunnel for access:

cat > /etc/cockpit/cockpit.conf << 'EOF'
[WebService]
Origins = https://localhost:9090
BindAddress = 127.0.0.1
EOF

systemctl restart cockpit.socket

Then connect via tunnel each time:

ssh -N -L 9090:127.0.0.1:9090 root@your-proxmox-ip

This is the configuration I run on every host: no externally reachable Cockpit port, SSH key authentication, and a local browser tab that behaves like local access. For additional network-level threat containment, CrowdSec on Proxmox: Cluster-Wide Brute-Force Defense adds behavioral detection that protects the SSH entrypoint itself — a natural complement to locking down Cockpit.

How Much Resources Does Cockpit Use

On a Proxmox host with 64 GB RAM, cockpit-ws and cockpit-bridge together use about 35 MB RSS during an active browser session. With socket activation, there is zero memory overhead when no browser is connected — confirmed on an idle host: systemctl status cockpit.socket shows the socket open, no cockpit-ws process spawned.

CPU overhead during normal admin activity (log browsing, service inspection) is negligible. Cockpit reads metrics from /proc and sysfs directly with no agent process and no database writes. On a host running a dozen QEMU VMs, Cockpit's resource consumption rounds to zero on any monitoring graph.

Conclusion

Cockpit and the Proxmox web UI complement each other cleanly when you respect their boundaries: Proxmox owns VM lifecycle, storage, and clustering; Cockpit owns host OS administration, journal logs, systemd service management, and the container dashboard. The setup takes under thirty minutes — install three packages, enable the socket, open port 9090 or configure an SSH tunnel, and you have a working dual-dashboard setup. The natural next step is enabling libvirtd so the VM panel shows accurate state, then locking Cockpit to localhost-only binding for any Proxmox host that faces the network.