Cockpit

Last reviewed Aug 26, 2026 · 808 words

If your server runs Fedora, RHEL, Rocky or AlmaLinux, Cockpit is probably already installed and one systemctl enable --now cockpit.socket away from listening on port 9090. That is the whole pitch: a web console for a Linux box, maintained by Red Hat, LGPL-2.1, about 15,000 GitHub stars, which uses your existing system accounts, runs nothing while nobody is looking at it, and needs roughly 128 MB when someone is. It is not a container platform and it is not configuration management. Knowing what it is not is most of what you need to use it well.

It is a package, not a container

Cockpit manages the host, so it has to run on the host. On Debian and Ubuntu it is apt install cockpit, and on Debian you want the version from backports because the stable one lags by a year or more. On the Fedora family it is dnf install cockpit if it is not there already. The socket activation matters: cockpit.socket listens on 9090 and the web service only starts when a browser connects, then exits after the session ends, so the idle cost on a homelab box is effectively zero. Login goes through PAM with normal users. Root login is refused by default on current releases, so use a user with sudo rights and click the "administrative access" toggle in the top bar when you need to change something.

The add-ons are where the value is

The core gives you an overview with load graphs, the systemd services list, the journal with filters, storage, networking, user accounts, software updates and a terminal in the browser. Each is a competent replacement for remembering the right command at 11 p.m. The optional modules extend it in the directions self-hosters care about. cockpit-machines manages KVM virtual machines through libvirt, including console access, and is the reason many people use Cockpit as a lighter Proxmox on a single host; my Proxmox versus Docker piece covers when that trade makes sense. cockpit-podman runs and inspects Podman containers. cockpit-storaged handles disks, partitions, LVM and mdraid. cockpit-files adds a file browser. The community modules from 45Drives fill the remaining gaps: Samba and NFS share management, a ZFS manager and a file navigator, all installed as packages alongside the official ones.

What it will not do

Docker. There was a Docker module years ago and it was dropped; Podman is the supported container runtime, and if your stack is Docker Compose you will still want a separate container UI. On Ubuntu, the networking page manages interfaces through NetworkManager, and server installs use netplan with systemd-networkd, so the network tab shows less than you expect until you move the interfaces under NetworkManager. Multi-server is a convenience rather than a fleet tool: you can add hosts over SSH and hop between them from one browser tab, but there is no inventory, no bulk actions and no state enforcement. Ansible remains the answer for "make these 6 machines identical", and Cockpit is the answer for "why is machine 4 slow right now".

Do not put it on the internet

Cockpit generates a self-signed certificate on first start; a real one goes in /etc/cockpit/ws-certs.d/ and the service picks it up. Even with proper TLS, this is a login page that hands out a root shell, and it does not have 2FA on its own. Keep 9090 reachable only from the LAN or over Tailscale, the same rule I apply to every tool in the remote access category that ends in a terminal. If you insist on exposing it, put it behind a reverse proxy with an authentication layer in front and PAM rate limiting behind.

Cockpit versus Webmin

Webmin is the older idea: hundreds of modules that each edit the configuration files of a specific daemon, from BIND to Postfix to Apache. Cockpit is thinner and closer to how a modern sysadmin already works: systemd units, the journal, NetworkManager, udisks. If you administer a mail server or DNS through a browser, Webmin still does that and Cockpit never will. If you want to see what the machine is doing and fix the obvious things without a fuss, Cockpit does that with far less surface area and, on the Red Hat family, with the distribution's own testing behind it.

What I'd do

Install it on every Linux host you own, Debian from backports, and leave it socket-activated on 9090 behind Tailscale. Add cockpit-machines on any box that runs VMs and cockpit-podman if you use Podman. Treat it as the dashboard you open when something is wrong, not the tool you build the homelab with, and keep Compose and Ansible for the building.