Cockpit

What is Cockpit?

Cockpit gives a Linux host a browser-based admin interface: services, storage, networking, containers, logs, users and a terminal, all backed by the system's own tooling rather than a parallel abstraction.

Best for

Administering a Linux server from a browser

Why choose Cockpit

Cockpit's strength is that it drives the system's own tooling rather than a parallel abstraction. Services, storage, networking, containers, logs, users and a full terminal are all available from the browser, and actions go through the same systemd and package management the command line uses — which means a change made in Cockpit is a change made on the system, not a setting that lives only inside the interface. It is packaged by most distributions, so installation is one command, and it is the natural administration surface for a headless Linux server you occasionally need to inspect without SSH. It also handles some genuinely fiddly tasks, like managing LVM volumes, far faster than the equivalent command-line work.

Replaces

• Webmin
• Portainer
• cPanel

Key features

• Service, storage and network management
• Integrated terminal and log viewer
• Podman container management
• User accounts and system updates

What to watch out for

Cockpit is an administration interface with real privileges, so anyone who reaches it can do significant damage — it must be behind TLS and strong authentication, and exposing it to the internet is a serious mistake. Its breadth is uneven: some tasks are fully supported, others are read-only and a few simply are not there, so it does not replace knowing the command line. The distribution packaging determines which modules are available, and what is included varies between distributions and versions. Logging in as root rather than a sudo-capable user weakens the audit trail. Some plugins install additional packages, which can surprise you on a minimal server.

How to deploy

• Install from the distribution package manager
• Reach it on port 9090 over TLS
• Restrict access to your network

Getting started

Install it from the distribution's package so the version matches the system tooling. Enable TLS properly rather than relying on the self-signed default for anything beyond localhost, and restrict access by firewall or an SSH tunnel. Create a sudo-capable administration user and use that instead of logging in as root directly. Explore the modules you actually need and note which tasks are read-only, so you know where to drop to a terminal. Add its access path to your documentation, and treat the port with the same care as SSH.

Typical setup

Installed from the distribution's package so its version matches the system tooling, with TLS configured properly rather than relying on the self-signed default beyond localhost. Access is restricted by firewall or SSH tunnel. A sudo-capable administration user is used instead of logging in as root, preserving the audit trail. The modules actually needed are explored and the read-only ones noted, so it is clear when to drop to a terminal. Its port is documented alongside SSH and treated with the same care.

Who should look elsewhere

Do not expose it publicly under any circumstances, because it is a privileged administration surface. Avoid it if you want to manage a fleet from one pane — it is per-host by design, and centralised management is a different product. And if you are comfortable on the command line and rarely need a graphical view, adding a privileged web service to every host is surface area for a convenience you may never use.

Project health

• GitHub stars: 15,173
• Last code push: 2026-10-01
• Open issues: 497
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.