Tink vs Vorta
Vorta wraps BorgBackup behind desktop profiles and a schedule. That is not a mechanic. Tink installs in one command, watches the Linux host, explains what is wrong, and helps you fix it.
Vorta runs the archive. Tink answers “why is this VPS sick?”
Accidental sysadmins land on Vorta because a Borg GUI looks cheaper than a NAS. Then the host volume fills, nginx dies, and borg list still looks complete — no profile match for host fill. A filling /var is a Tink warning; it is not a Vorta job unless you scraped the desktop log 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 Vorta if you already run Borg archives. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | Vorta |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Hours — Vorta profile, Borg repo, SSH remote, passphrase, schedule, then a host that still has no mechanic after the last borg create reports finished |
| What you get | Working monitoring, diagnosis, and approved fixes | A Borg GUI and a profile. Disk fill, nginx, Postgres, and certs stay your problem until you SSH past borg list |
| Pricing | Free (Scout) / $9 / $29 per machine per month | Free software. You still pay the person who owns the VPS after the last Vorta schedule stays green |
| Hidden costs | None — fully managed | A quiet overnight borg create, a healthy archive that is not host fill, and a second tool to tell you the box is sick while the last Vorta job still looks complete |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | Vorta profiles, Borg repositories, and a desktop schedule. Vorta does not watch a quiet cert or host auth.log after the last archive finished |
| Configuration | None after install — heuristics and AI | Profiles, repo URLs, include/exclude patterns, schedule slots, and which failed borg create actually pages you |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | You read the Vorta log and borg list, then SSH into the host to change the Linux box Vorta already sits on |
| Fix execution | Proposes and executes approved commands with an audit trail | borg create and restore from an archive — Vorta cannot free host disk, rotate a cert, or stop SSH brute-force unless you archived that path |
| Alerting | Built-in across 8 channels | Not a Vorta job — desktop notifications from a failed profile plus a separate monitoring tool have to fire |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Not a Vorta job — an archive date does not forecast a quiet host filling up |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — Vorta does not read host auth.log, journald, or firewall state after the last archive landed |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | Silence if the Vorta schedule dies after the last run — unless you built a separate uptime check |
| Public status page | Shareable URL with 90-day history | None — Vorta has no customer-facing status page for the Linux host |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — an archive recap is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire failed Vorta/borg create mail into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | Vorta logs and SSH. No mechanic you text when /var filled and the last borg create still showed finished |
| Learning curve | None — works after install | Steep — Borg repos, passphrases, SSH remotes, prune policies, and which failure is Vorta vs the running host |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run Vorta for Borg archives, not a sick-VPS mechanic |
When Vorta is the right choice
Keep using Vorta when you already want that exact job:
- Borg archives from a GUI — you need profiles, repositories, and a schedule, not a mechanic.
- An existing backup stack — borg create, prune policies, and restore from an archive matter more than guest nginx, certs, and SSH on a quiet VPS.
- An existing lab or nested setup — Vorta already runs, the profile already exists, and someone owns the Borg repo.
- Hosts that only page on archive or schedule death — you already run failed-profile desktop alerts, not a sick-box SSH loop.
The real cost of “just watch borg list”
Vorta runs Borg and a profile. A working ops loop for five Linux boxes is not:
- A healthy archive still means you SSH into the host 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 — Vorta will stay quiet until the next borg create fails
- A single VPS with a dead agent still needs a mechanic, not another archive date
For a 5-server team, Tink Mechanic at $45/month is cheaper than the engineer who keeps failed-schedule notifications alive after a green Vorta profile, and every scan includes a diagnosis a quiet borg list will not type.
No Vorta profile homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs Borg · Tink vs restic · Tink vs Kopia