I started using Cockpit after one particularly rough night — SSH’d into the server at 2 AM to restart a service, fumbling through the terminal half-asleep — and thought: there has to be an easier way. After 6 months running it on a production Fedora Server, here’s what I actually found worth sharing.
Three options I tried — and why I ruled out the first two
Before settling on Cockpit, I went through three main approaches, each with a clear reason to eliminate it:
1. Pure SSH + CLI tools
No introduction needed here. Nothing extra to install, solid security, minimal attack surface. But for a small team or when onboarding someone new, it’s a real barrier. Asking someone to memorize systemctl, journalctl, df, netstat, and lsblk syntax in their first week is unrealistic. And if you’re on a work machine, a client’s laptop, or a tablet — no SSH client, you’re completely stuck.
2. Webmin
Webmin was the go-to choice back in the 2010s. Feature-rich UI, but it shows its age quickly: outdated interface, slow updates, and it doesn’t feel native to the Fedora/RHEL ecosystem at all. Installing it pulls in a pile of packages from third-party repos — not something you want on production, where you need to know exactly what’s running at all times.
3. Cockpit — the built-in web console
Cockpit differs from the other two at a fundamental level: it’s not a separate layer running on top of your server — it’s a web interface for the system tools that are already there. When you view logs in Cockpit, you’re reading journald. When you manage services, you’re using real systemd. No separate database, no heavy daemon, no hidden magic.
What Cockpit can do — and what it can’t
Real strengths
- Real-time system monitoring: CPU, RAM, disk I/O, and network at a glance — no need for htop or iotop
- Log viewer backed by journald: Filtering by service, severity, and time range is far easier than journalctl
- systemd service management: Start/stop/restart/enable with one click, view status and logs side by side
- Integrated web terminal: SSH into the server without needing a separate client
- Deep Fedora/RHEL integration: Red Hat develops Cockpit, so the ecosystem fits perfectly
Things to know before installing
- Not a hosting control panel: Cockpit doesn’t manage Apache/Nginx virtual hosts like cPanel — don’t confuse the roles
- Advanced features require plugins: Podman container management, KVM, and advanced storage all need separate modules installed
- Port 9090 needs protection: It adds an attack surface, even though Cockpit uses TLS by default
Why Cockpit is a better fit for Fedora Server
I’ve been using Fedora as my main development machine for 2 years and appreciate how fast packages move — Fedora always gets the new kernel and new systemd before other distros. Cockpit keeps pace with that. Red Hat backs both Fedora and Cockpit, so the integration is natural, not bolted on version by version.
Since Fedora 36, Cockpit has been included in the minimal image (disabled by default). That means no external repos, no compatibility worries — install it from the official repo like any other package. On a production environment, that matters more than most people realize.
Installing Cockpit on Fedora Server
Step 1: Install Cockpit and the modules you need
On Fedora Server, Cockpit is often already available. Check and install if it isn’t:
sudo dnf install cockpit -yInstall commonly used modules:
# Podman container management
sudo dnf install cockpit-podman -y
# Disk, LVM, and RAID management
sudo dnf install cockpit-storaged -y
# KVM/libvirt VM management (if needed)
sudo dnf install cockpit-machines -yStep 2: Enable the service
sudo systemctl enable --now cockpit.socketCockpit uses socket activation — the service only actually starts when a request hits port 9090. When idle, it uses almost no RAM. Check the status:
sudo systemctl status cockpit.socketStep 3: Open the firewall
Fedora Server uses firewalld by default:
sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload
# Verify it was added
sudo firewall-cmd --list-servicesStep 4: Access and log in
Open a browser and navigate to:
https://[server-IP]:9090You’ll get an SSL warning on the first visit due to the self-signed certificate — skip it or add an exception. Log in with a system user that has sudo privileges. Once in, check “Reuse my password for privileged tasks” so you can perform admin actions without re-entering your password constantly.
Step 5 (optional): Replace the SSL certificate with Let’s Encrypt
If your server has a public domain, swap out the self-signed cert using Certbot and Let’s Encrypt:
sudo dnf install certbot -y
sudo certbot certonly --standalone -d your-domain.com
# Copy the certificate to the directory Cockpit reads from
sudo cp /etc/letsencrypt/live/your-domain.com/fullchain.pem \
/etc/cockpit/ws-certs.d/1-custom.cert
sudo cp /etc/letsencrypt/live/your-domain.com/privkey.pem \
/etc/cockpit/ws-certs.d/1-custom.key
sudo systemctl restart cockpit.socketHardening Cockpit security
Restrict access by IP
Instead of leaving Cockpit fully public, use firewalld rich rules to allow only specific IPs:
# Remove the public rule first
sudo firewall-cmd --remove-service=cockpit --permanent
# Allow only your IP (replace with your actual IP)
sudo firewall-cmd --add-rich-rule=\
'rule family="ipv4" source address="203.0.113.10/32" service name="cockpit" accept' \
--permanent
sudo firewall-cmd --reloadSSH tunnel — the safest option when you don’t want to expose the port
Don’t want to expose port 9090 to the internet? Use an SSH tunnel — run this command on your local machine:
ssh -L 9090:localhost:9090 [email protected] -NThen visit https://localhost:9090 in your local browser. Cockpit runs through the SSH tunnel with no additional firewall rules needed. This is my go-to approach — no SSL configuration overhead and completely secure.
My actual workflow after 6 months
I don’t use Cockpit as a full SSH replacement. In practice, I combine both depending on the task:
- Daily monitoring: Open Cockpit and check the dashboard — are CPU/RAM/disk stable, any alerts? Takes 30 seconds instead of SSH-ing in and running multiple commands
- Debugging a broken service: Go to Services, click the service, logs appear right below — much faster than
journalctl -u service-name -n 100 - Storage management: View per-partition usage visually, no need to remember lsblk or df -h
- When I need complex operations: Open the terminal right inside Cockpit — no app switching, no extra SSH tab
The biggest time-saver? The log viewer. Instead of typing journalctl with a bunch of flags, I filter directly in the UI: select the service, choose “Error and above”, pick a time range — done in 10 seconds. Most useful during a late-night incident investigation when your brain can no longer remember command syntax.
When Cockpit isn’t the right choice
Hosting with multiple virtual hosts? cPanel or DirectAdmin make more sense. Orchestrating dozens of servers at once? Ansible or AWX is the right direction. Cockpit shines in exactly one scenario: a single server, you want a convenient web console, and you don’t want to install anything heavyweight.
What makes me confident running it in production comes down to three things combined: it ships with Fedora, it’s maintained by Red Hat, and it doesn’t depend on external repos. The dependency stack is lean and fully auditable — enough to trust it for the long haul.
