Tink vs XCP-ng
XCP-ng is a XenServer-family hypervisor. That is not a mechanic. Tink installs in one command, watches the Linux host, explains what is wrong, and helps you fix it.
XCP-ng runs the guest. Tink answers “why is this VPS sick?”
Accidental sysadmins land on XCP-ng because a local hypervisor looks like ops. Then the volume fills, Dom0 nginx dies, and xe still shows running — no VM matched host fill. A filling /var is a Tink warning; it is not an XCP-ng job unless you scraped xapi and watched it.
Tink is the other job: detect the issue on the machine, say why it happened in plain English, propose the command, and run it only after you approve. Keep using XCP-ng if you already run VMs. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | XCP-ng |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Hours — ISO, pool master, storage repositories, then a host that still has no mechanic after xe vm-list stays running |
| What you get | Working monitoring, diagnosis, and approved fixes | A XenServer-family hypervisor. Disk fill, Dom0 nginx, Postgres, and certs stay your problem until you SSH into Domain 0 |
| Pricing | Free (Scout) / $9 / $29 per machine per month | XCP-ng is GPLv2. You still pay the engineer who owns Xen Orchestra after the last VM stays running |
| Hidden costs | None — fully managed | A quiet SR at 2am, Dom0 fill, and a second tool to tell you the Linux guest is sick while xe still shows running |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | Guest lifecycle and xapi. XCP-ng does not watch a quiet cert or guest auth.log after the VM started |
| Configuration | None after install — heuristics and AI | Pools, SRs, Xen Orchestra, and which VM death actually pages you |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | You read xe vm-list, then SSH into Dom0 to change the Linux guest the hypervisor already sits under |
| Fix execution | Proposes and executes approved commands with an audit trail | Start and stop VMs only — XCP-ng cannot free guest disk, rotate a cert, or stop SSH brute-force unless you wrote that runbook |
| Alerting | Built-in across 8 channels | Not an XCP-ng job — Xen Orchestra plus a separate monitoring tool have to fire |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Not an XCP-ng job — a green running VM does not forecast a quiet volume filling up |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — XCP-ng does not read guest auth.log, journald, or firewall state after the VM started |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | Silence if the guest dies after the last xapi poll — unless you built a separate uptime check |
| Public status page | Shareable URL with 90-day history | None — XCP-ng has no customer-facing status page for the Linux guest |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — an xe recap is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire failed VMs into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | xe and Xen Orchestra. No mechanic you text when /var filled and the last VM still showed running |
| Learning curve | None — works after install | Steep — pool master, SRs, xapi, and which host failure is the hypervisor vs the running guest |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run XCP-ng pools and need a XenServer hypervisor, not a sick-VPS mechanic |
When XCP-ng is the right choice
Keep using XCP-ng when you already want that exact job:
- XenServer-family virtualization with Domain 0 — you need xe, xapi, and a pool, not a mechanic.
- An existing XCP-ng host — SRs, Xen Orchestra, and isolation matter more than guest nginx, certs, and SSH on a quiet VPS.
- An existing lab or nested setup — guests already start, the hypervisor already ships, and someone owns the pool master.
- Hosts that only page on failed VMs — you already run Xen Orchestra and exporters, not a sick-box SSH loop.
The real cost of “just watch xe vm-list”
XCP-ng runs guests. A working ops loop for five Linux boxes is not:
- A running VM still means you SSH into Dom0 and change the box by hand when it gets sick later
- Host fill, nginx, certs, and SSH brute-force never appear unless a separate tool scraped those signals and a rule fired
- A filling /var is a Tink disk warning on every scan — XCP-ng will stay quiet until the next VM process dies
- A single VPS with a dead agent still needs a mechanic, not another xe line
For a 5-server team, Tink Mechanic at $45/month is cheaper than an XCP-ng host plus the engineer who keeps failed-VM notifications alive, and every scan includes a diagnosis a quiet xe poll will not type.
No hypervisor homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs Xen · Tink vs Proxmox · Tink vs QEMU