The Case for Web UIs on Servers You’re Already SSHing Into
The conventional wisdom in sysadmin circles is that if you need a web UI to manage your server, you’re doing something wrong. Real sysadmins use the terminal. GUIs are for people who haven’t memorized systemctl flags yet.
This is partially true and mostly snobbery.
Web UIs for servers exist for real, legitimate reasons that aren’t about avoiding the terminal:
- Onboarding: New team members can check service status and read logs before they’ve memorized the full systemd CLI
- Quick tasks from unfamiliar machines: When you’re on a client’s laptop and don’t want to SSH from their machine or set up keys
- Oversight: Non-technical co-owners who need to see that the server is healthy without a CLI lesson
- Mobile checks: Seeing that your services are green from your phone at 11pm without setting up a terminal app
The caveat is real though: a web UI on a server is another attack surface. You’re trading convenience for security complexity. Use HTTPS, use authentication, put it behind a VPN or firewall rule, and don’t expose it to the open internet.
With that out of the way — two tools: Cockpit and Webmin. One is what the Red Hat engineering team built in 2013. One is what the late 1990s built, and it’s still technically alive.
Cockpit: The Modern One
Cockpit is an open source Linux server management web console developed primarily by Red Hat. It ships by default on RHEL, Fedora, and CentOS Stream, which means it has serious institutional backing and isn’t going anywhere.
The design philosophy is “be a thin layer over existing Linux interfaces, not a replacement for them.” Cockpit uses existing APIs — systemd, NetworkManager, udisks, podman — rather than implementing its own management layer. This means changes you make in Cockpit are the same changes you’d make in the terminal. There’s no Cockpit config database separate from the system’s config.
What Cockpit Gives You
System overview: CPU, memory, disk I/O, network throughput — live graphs, clean layout.
Services: Start, stop, restart, enable, disable systemd services. See logs. Identical to systemctl but clickable.
Storage: Manage disks, partitions, LVM, RAID, LUKS encryption through a UI that actually makes LVM comprehensible. Creating LVM volumes through Cockpit’s storage page is legitimately easier than the command line for people who don’t use LVM daily.
Networking: View interfaces, manage bonds and bridges, configure firewall zones through firewalld.
Logs: A journald browser. Search, filter by time and service, view live. Useful for quick log checks without crafting journalctl flags.
Terminal: A full SSH-like terminal in the browser. This is surprisingly good — it’s not a replacement for a real terminal but it works for quick tasks when you’re on a device without an SSH client.
Container management (Podman): The cockpit-podman extension gives you a Podman-based container UI. Pull images, create containers, manage volumes — all in the browser. If you run Docker, there’s a community plugin but Podman is the first-class experience.
Modular extensions: The base Cockpit install is lean. Extensions add capabilities: cockpit-podman, cockpit-machines (for virtual machines via libvirt), cockpit-packagekit (for package updates), etc. Install only what you need.
Installing Cockpit
On RHEL/CentOS Stream/Fedora (it may already be installed):
sudo dnf install cockpit
sudo systemctl enable --now cockpit.socket
sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload
On Ubuntu/Debian:
sudo apt install cockpit
sudo systemctl enable --now cockpit.socket
Access it at https://your-server:9090. Use your existing system credentials to log in — no separate Cockpit user database.
Adding Podman Container Management
sudo dnf install cockpit-podman # RHEL/Fedora
# or
sudo apt install cockpit-podman # Debian/Ubuntu
Refresh Cockpit. A “Podman containers” section appears in the nav.
Cockpit and Docker
Cockpit doesn’t have first-party Docker support (Red Hat and Docker have a relationship that’s diplomatically described as “complicated”). For Docker, the cockpit-docker community project exists but has had maintenance gaps. If you’re already using Docker, you might get more value from Portainer for container management and Cockpit for the system-level stuff.
Webmin: The Veteran That Refuses to Retire
Webmin has been around since 1997. It predates not just modern Linux distributions but most of the tools Cockpit wraps around. Its UI looks like it was designed in 2003 because most of it was, and it’s been accumulating features like a filing cabinet accumulates paper since then.
That description sounds like an insult but it isn’t entirely. Webmin’s breadth is actually its superpower. Where Cockpit is carefully scoped to core system management, Webmin will manage your entire server ecosystem from one panel:
- Apache, Nginx, Lighttpd web server config
- MySQL, PostgreSQL, MariaDB databases
- DNS zones (BIND, dnsmasq)
- Mail servers (Postfix, Dovecot, SpamAssassin)
- FTP servers
- Cron jobs (with a GUI!)
- SSH server configuration
- Firewall rules (iptables and nftables)
- SSL certificate management (including Let’s Encrypt integration)
- Samba and NFS shares
- User and group management
- Software package management
- And approximately 100 more modules
For a homelab running multiple services, Webmin is like having a control panel for everything — even if some of that panel was clearly last painted in 2006.
Installing Webmin
# On Debian/Ubuntu
curl -o setup-repos.sh https://raw.githubusercontent.com/webmin/webmin/master/setup-repos.sh
sudo sh setup-repos.sh
sudo apt-get install --install-recommends webmin
# On RHEL/CentOS/Fedora
curl -o setup-repos.sh https://raw.githubusercontent.com/webmin/webmin/master/setup-repos.sh
sudo sh setup-repos.sh
sudo dnf install webmin
Access at https://your-server:10000. Log in with root or any sudo-capable user.
Virtualmin: Webmin’s Hosting Control Panel Extension
If you’re running a web hosting environment — multiple domains, multiple sites, user isolation — Virtualmin is Webmin’s extension that turns it into something like cPanel. It manages Apache/Nginx virtual hosts, DNS zones, mail accounts, databases, and SSL certificates per-domain, with a permission model that lets you delegate management to individual domain owners.
Virtualmin is free for up to a certain number of domains (the GPL version). A commercial Virtualmin Pro license adds more features and support.
Cockpit vs Webmin: Side by Side
| Feature | Cockpit | Webmin |
|---|---|---|
| Age | 2013 | 1997 |
| Default port | 9090 | 10000 |
| Maintained by | Red Hat + community | Jamie Cameron + community |
| Ships with | RHEL, Fedora, CentOS Stream | Self-installed |
| UI quality | Modern, clean | Functional, dated |
| System monitoring | Excellent (live graphs) | Basic |
| Service management | Excellent (systemd-native) | Good |
| Container management | Podman (first-class), Docker (community) | Basic Docker module |
| Web server config | No | Apache, Nginx, Lighttpd |
| Database management | No | MySQL, PostgreSQL, MariaDB |
| DNS management | No | BIND, dnsmasq |
| Mail server management | No | Postfix, Dovecot, etc. |
| LVM management | Yes | Yes |
| Terminal in browser | Yes | Yes |
| Security posture | Lean, fewer attack surfaces | Larger surface, more modules |
| Modular architecture | Yes | Yes |
| Hosting control panel | No | Virtualmin extension |
When to Use Which
Choose Cockpit when:
- You’re on RHEL/Fedora/CentOS and want something that just works out of the box
- You primarily need system monitoring, service management, and container oversight
- You value modern UI and security posture over feature breadth
- You’re managing servers in a team environment (Cockpit’s multi-server support is good)
- The server does one thing well and you don’t need 40 management modules
Choose Webmin when:
- You’re running a multi-service homelab and want one panel for everything
- You need web server, database, or DNS configuration through a UI
- You want Virtualmin for hosting multiple domains
- You’re on a non-RHEL Linux where Cockpit isn’t the default
- Feature breadth matters more to you than UI aesthetics
Use both when:
- You’re an overachiever running both on different ports for different purposes (genuinely fine)
The real answer is that for modern server management, Cockpit is the better starting point — it’s leaner, better maintained, and integrates more cleanly with the modern Linux stack. But Webmin earned its longevity by being genuinely useful, and if you need to manage an Apache virtual host config through a browser, Cockpit won’t help you and Webmin will.
Neither of these replaces knowing your way around the terminal. They’re supplements, not substitutes. But as supplements go, having a live system dashboard in your browser is a lot more useful than people who’ve memorized every sysctl flag will admit.