Short answer
Cockpit for one to three Linux hosts you reach over a VPN, when you want a free, vendor-neutral UI over the system's own services. Servor the moment the questions become “which of my servers is unhealthy”, “who gets paged” and “what did we run last night” — and when you would rather not expose an admin login per machine.
What Cockpit is
Cockpit is a web console sponsored by Red Hat and packaged by Fedora, RHEL, Debian, Ubuntu and most others. You install it on a server, open port 9090, and log in with a Linux account — the same PAM login as SSH. What you get is a well-made UI over what the system already knows: storage and disks, network interfaces, systemd services, the journal, package updates, user accounts, a terminal, and with plugins, Podman containers and libvirt virtual machines. Optional PCP integration adds metric history.
It is deliberately thin. There is no separate database, no daemon of its own beyond a socket-activated bridge, and nothing it can do that the logged-in user could not do in a shell. That honesty is its best property. You can also add other hosts and switch between them, connecting through SSH from the first one.
What Servor is
Servor is a hosted console for a fleet. A small agent on each server dials out over WebSocket; you operate every server from one browser tab. Terminal, file explorer with editor, scheduled commands, live logs, container actions, eleven monitor types with alert rules and on-call escalation, incidents, public status pages, 150+ recipes and an AI copilot. Two servers are free; a team goes up to fifty.
Its security model is the opposite of “a login per host”: no inbound port at all, and a backend that cannot execute on its own — every command is signed in your browser and verified by the agent.
Side by side
| Capability | Cockpit | Servor |
|---|---|---|
| Scope | One host per login; host switching via SSH from the first | Every server in the team, one console |
| Exposure | Port 9090 per host (put it behind a VPN or reverse proxy) | Outbound HTTPS from the agent; nothing listens |
| Authentication | System accounts, per host | Accounts with MFA, roles, vault unlock in the browser |
| System administration | Excellent: storage, network, services, updates, users, journal | Terminal, files, systemd actions, package updates, firewall, SSH key review, storage and SMART health; no partitioning or network config |
| Metrics history | With the PCP plugin, per host | Built in, partitioned history across the fleet |
| Alerting | None native | Rules, 20 channels, cooldown, quiet hours, escalation |
| Scheduled commands | Edit crontab in the terminal | Managed cron with history, Run now, failure threshold |
| Incidents & status pages | None | Yes, with custom domains and subscribers |
| Audit | The journal, per host | Hash-chained audit log for the team, CSV export |
| Containers / VMs | Podman and libvirt plugins | Docker: logs, shell, start/stop/restart, inspect; no VM management |
| Price | Free, open source | Free for 2 servers, from €9/mo |
Where Cockpit wins
- Deep single-host administration. Partitioning a disk, adding a bond interface, reviewing SELinux denials, managing libvirt VMs — Cockpit has forms for things Servor expects you to do in the terminal or through a recipe.
- Nothing leaves the machine. No hosted control plane, no agent, no vendor. For a regulated host or an air-gapped lab, that settles the question.
- Zero cost at any scale. Free on host one and on host one hundred.
- Distribution-native. It is in the repositories, it follows the distribution's release cycle, and it will exist in ten years.
Where Servor wins
- Fleet view. Cockpit answers questions about the host you are logged into. Servor answers “which of the thirty is at 95 % disk” before you knew to ask.
- Someone gets paged. Cockpit shows a red service if you happen to be looking. Servor sends it to one of 20 channels, from Slack to PagerDuty, with cooldown and escalation so it reaches the right person once.
- One attack surface instead of N. Every Cockpit host listens on 9090 with a password login — you need a VPN or reverse proxy per host, or you have exposed an admin panel. Servor's servers expose nothing; the agent only calls out.
- Team semantics. Roles, invitations, a shared zero-knowledge vault, and an audit log that says who ran what across the fleet. Cockpit's answer is Linux accounts on each machine.
- The vendor cannot become the attacker. The obvious objection to a hosted console is “now the vendor can run commands on my servers”. Servor is designed so that it cannot: signed commands, verified on the agent, vault keys that stay in the browser.
Using both
Nothing stops you. Cockpit on hosts where you want its storage and networking forms, bound to a WireGuard interface; Servor for the fleet-wide loop — monitoring, alerting, cron, incidents, status page, the terminal you reach from anywhere. The two do not conflict, and the recipes catalogue includes installing Cockpit itself.
Who should pick what
- One home server or a lab box: Cockpit.
- Two or three production VPS, solo: either; Servor Free adds alerting and a status page for nothing.
- Five or more servers, or anyone else on call: Servor.
- Heavy VM or storage administration: Cockpit on those hosts, whatever else you run above it.
Try it beside Cockpit
Install the agent on the two servers Cockpit already manages. Keep Cockpit. In a week you will know which tab you open first when something goes wrong — and that is the tool you were looking for.