What operating systems does Tink support?

Any Linux distribution with curl and Node.js 20 or newer. The installer uses a user-local command and does not require systemd or root access.

Does Tink run commands automatically?

No. Tink suggests fixes and waits for your explicit approval. Nothing runs without you confirming it first.

How much resources does the Tink agent use?

Minimal. The agent idles at under 20MB RAM and near-zero CPU between scans. Scans themselves take a few seconds.

Can I use Tink on containers?

Tink is designed for long-running servers, not ephemeral containers. For Kubernetes, point it at your nodes instead.

What data does Tink collect?

System metrics (CPU, memory, disk, network), running services, and relevant log snippets when diagnosing issues. No application data, credentials, or file contents.

Tink vs Pulumi

Pulumi is infrastructure as code in real languages. It also records previews and ups. That is not a mechanic. Tink installs in one command, watches the Linux server, explains what is wrong, and helps you fix it.

Pulumi updates the stack. Tink answers “why is this VPS sick?”

Accidental sysadmins land on Pulumi because every IaC diagram starts with a preview. Then the volume fills, nginx dies, and the last up still shows green — no resource matched host fill. A filling /var is a Tink warning; it is not a Pulumi resource unless you coded the disk itself.

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 writing Pulumi if you already operate infrastructure as code. Use Tink if you run Linux servers and want a mechanic.

Feature	Tink	Pulumi
Setup time	30 seconds (one curl \| sh command)	Hours — language SDK, stack, backend, Pulumi Cloud org, and a first pulumi up before a run even exists
What you get	Working monitoring, diagnosis, and approved fixes	A green update. Host disk fill, nginx, Postgres, and certs stay your problem until a later preview notices drift
Pricing	Free (Scout) / $9 / $29 per machine per month	Pulumi OSS is free. Pulumi Cloud is paid. You still pay the engineer who owns stacks, state, and the box after up
Hidden costs	None — fully managed	A locked stack, a failed up at 2am, and a second tool to tell you the VPS is sick after the update succeeded
Monitoring approach	Agent on the server — CPU, disk, services, logs, certs, ports	pulumi up exit codes, stack status, and resource drift. Pulumi does not watch a quiet cert unless you coded that resource
Configuration	None after install — heuristics and AI	Pulumi.yaml, language SDK, stacks, backends, and which update notification actually pages you
Plain-English diagnosis	Yes — AI explains root cause, impact, and fix	You read pulumi preview output, then SSH in to change the box Pulumi already updated
Fix execution	Proposes and executes approved commands with an audit trail	Update only — Pulumi cannot free disk, restart nginx, or rotate a cert that is already in state
Alerting	Built-in across 8 channels	Not a Pulumi job — Cloud deploy webhooks and a separate monitoring tool have to fire
Predictive alerts	Yes — disk fills in ~6 days, memory and CPU trends	Not a Pulumi job — a successful up does not forecast a quiet volume filling up
SSH brute-force detection	Built-in — parses auth.log every scan	Never — Pulumi does not read auth.log, journald, or host firewall state
Machine offline detection	Agent presence monitoring with multi-channel alerts	Silence if the box dies after up — unless you built a separate uptime check
Public status page	Shareable URL with 90-day history	None — Pulumi has no customer-facing status page
Weekly fleet digest	Automated Monday digest + daily brief when issues are open	None — an update log is not a plain-English fleet narrative
On-call tracking	Built-in /oncall command + incident acknowledgment	Not included — wire deploy webhooks into PagerDuty or another incident tool
Conversation interface	Telegram, WhatsApp, web dashboard, CLI	pulumi preview and the Cloud console. No mechanic you text when /var filled and the last up still showed green
Learning curve	None — works after install	Steep — TypeScript/Python/Go SDK, stacks, backends, and which update failure is the box vs the program
Best for	Freelancers, small teams, accidental sysadmins (1-50 Linux servers)	Teams that already write Pulumi programs and need stack SLOs, not a sick-VPS mechanic

When Pulumi is the right choice

Keep writing Pulumi when you already want that exact job:

Infrastructure as code in real languages — you need TypeScript or Python programs, stacks, and ups, not a mechanic.
An existing Pulumi estate — SDKs, backends, and stacks matter more than host nginx, certs, and SSH on a quiet VPS.
An existing Pulumi Cloud org — deployments already exist, webhooks already fire, and someone owns the state.
Hosts that only page on update — you already run exporters and PromQL, not a sick-box SSH loop.

The real cost of “just watch Pulumi stacks”

Pulumi is in every modern IaC diagram. A working ops loop for five Linux boxes is not:

A green pulumi up still means you SSH in 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 — Pulumi will stay quiet until the next preview notices drift
A single VPS with a dead agent still needs a mechanic, not another stack update log

For a 5-server team, Tink Mechanic at $45/month is cheaper than Pulumi Cloud plus the engineer who keeps deploy webhooks alive, and every scan includes a diagnosis a quiet update log will not type.

No stack homework. No silent host. One command install.

Start Mechanic

Also compare: Tink vs Terraform · Tink vs Vault · Tink vs Prometheus