Tink vs Unison

Unison reconciles replicas, profiles, and archives. That is not a mechanic. Tink installs in one command, watches the Linux host, explains what is wrong, and helps you fix it.

Unison runs the replica. Tink answers “why is this VPS sick?”

Accidental sysadmins land on Unison because two-way rsync looks cheaper than a NAS. Then the host volume fills, nginx dies, and the archive still agrees — no path match for host fill. A filling /var is a Tink warning; it is not a Unison job unless you scraped the last exit code 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 Unison if you already run replicas. Use Tink if you run Linux servers and want a mechanic.

FeatureTinkUnison
Setup time30 seconds (one curl | sh command)Hours — ~/.unison/*.prf, root paths, ignore patterns, SSH transport, archive files, then a host that still has no mechanic after the last replica stays equal
What you getWorking monitoring, diagnosis, and approved fixesBidirectional file sync, profiles, and a GTK/CLI replica view. Disk fill, nginx, Postgres, and certs stay your problem until you SSH past unison -batch
PricingFree (Scout) / $9 / $29 per machine per monthGPL and free. You still pay the person who owns the VPS after the last archive agrees
Hidden costsNone — fully managedA quiet replica at 2am, skipped conflicts that are not host fill, and a second tool to tell you the box is sick while Unison still shows nothing to propagate
Monitoring approachAgent on the server — CPU, disk, services, logs, certs, portsRoots, archives, and path diffs. Unison does not watch a quiet cert or host auth.log after the last replica finished
ConfigurationNone after install — heuristics and AIprofile.prf, root=, ignore=, sshargs, unison.service, and which skipped conflict actually pages you
Plain-English diagnosisYes — AI explains root cause, impact, and fixYou read the replica diff, then SSH into the host to change the Linux box Unison already sits on
Fix executionProposes and executes approved commands with an audit trailunison -batch and unison-gtk — Unison cannot free host disk, rotate a cert, or stop SSH brute-force unless you wrote that task
AlertingBuilt-in across 8 channelsNot a Unison job — exit codes plus a separate monitoring tool have to fire
Predictive alertsYes — disk fills in ~6 days, memory and CPU trendsNot a Unison job — an equal replica pair does not forecast a quiet host filling up
SSH brute-force detectionBuilt-in — parses auth.log every scanNever — Unison does not read host auth.log, journald, or firewall state after the last replica synced
Machine offline detectionAgent presence monitoring with multi-channel alertsSilence if unison dies after the last cron run — unless you built a separate uptime check
Public status pageShareable URL with 90-day historyNone — Unison has no customer-facing status page for the Linux host
Weekly fleet digestAutomated Monday digest + daily brief when issues are openNone — a replica completion recap is not a plain-English fleet narrative
On-call trackingBuilt-in /oncall command + incident acknowledgmentNot included — wire failed unison into PagerDuty or another incident tool
Conversation interfaceTelegram, WhatsApp, web dashboard, CLIunison-gtk and SSH. No mechanic you text when /var filled and the last archive still agreed
Learning curveNone — works after installSteep — profiles, archives, ignore regexes, SSH roots, and which failure is Unison vs the running host
Best forFreelancers, small teams, accidental sysadmins (1-50 Linux servers)Teams that already run Unison for two-way replicas, not a sick-VPS mechanic

When Unison is the right choice

Keep using Unison when you already want that exact job:

  • Two-way replicas with profiles — you need ~/.unison, archives, and unison-gtk, not a mechanic.
  • An existing file-sync stack — profile.prf, ignore regexes, and SSH roots matter more than guest nginx, certs, and SSH on a quiet VPS.
  • An existing lab or nested setup — unison already starts, the replica already ships, and someone owns the Unison box.
  • Hosts that only page on replica or archive death — you already run cron exit codes, not a sick-box SSH loop.

The real cost of “just watch the archives stay equal”

Unison runs replicas and profiles. A working ops loop for five Linux boxes is not:

  • A healthy replica 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 — the archive will stay quiet until the next unison process dies
  • A single VPS with a dead agent still needs a mechanic, not another replica line

For a 5-server team, Tink Mechanic at $45/month is cheaper than the engineer who keeps failed-app notifications alive after a free Unison install, and every scan includes a diagnosis a quiet replica poll will not type.

No ~/.unison homework. No silent host. One command install.

Start Mechanic

Also compare: Tink vs Syncthing · Tink vs Seafile · Tink vs MinIO