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 Amazon VPC CNI

Amazon VPC CNI is EKS's default CNI. It also exposes aws-node, IPAMD, and ENI gauges for Prometheus. That is not a mechanic. Tink installs in one command, watches the Linux server, explains what is wrong, and helps you fix it.

Amazon VPC CNI scrapes ENIs. Tink answers “why is this VPS sick?”

Accidental sysadmins land on Amazon VPC CNI because every EKS getting-started guide ships aws-node. Then the volume fills, nginx dies, and Grafana still shows assigned IPs — no PromQL matched host fill. A filling /var is a Tink warning; it is not an IPAMD job unless the ENI pool itself is the failure.

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 scraping Amazon VPC CNI if you already operate EKS and need CNI SLOs. Use Tink if you run Linux servers and want a mechanic.

Feature	Tink	Amazon VPC CNI
Setup time	30 seconds (one curl \| sh command)	Hours — aws-node DaemonSet, IPAMD warm pool, prefix delegation, security groups for pods, and prometheus.yml scrape
What you get	Working monitoring, diagnosis, and approved fixes	A CNI scrape target. Host disk fill, nginx, Postgres, and certs stay your problem until PromQL fires and you SSH in
Pricing	Free (Scout) / $9 / $29 per machine per month	Open-source (Apache 2.0). You still pay EKS nodes, ENI/IP quotas, Prometheus, Grafana, and the engineer who owns IPAMD
Hidden costs	None — fully managed	ENI exhaustion, prefix-delegation surprises, SNAT hairpins, aws-node CrashLoops, and a second tool to tell you the box is sick
Monitoring approach	Agent on the server — CPU, disk, services, logs, certs, ports	awscni_assigned_ip_addresses and ipamd gauges. Amazon VPC CNI does not watch host fill or a quiet cert unless you added another exporter
Configuration	None after install — heuristics and AI	WARM_ENI_TARGET, WARM_IP_TARGET, prefix delegation, pod ENI, and which PromQL actually pages you
Plain-English diagnosis	Yes — AI explains root cause, impact, and fix	You graph awscni_eni_allocated in Grafana, then SSH in to change the box
Fix execution	Proposes and executes approved commands with an audit trail	Metrics only — Amazon VPC CNI cannot free disk, restart nginx, or rotate a cert
Alerting	Built-in across 8 channels	Not an Amazon VPC CNI job — Prometheus rules and Alertmanager have to fire
Predictive alerts	Yes — disk fills in ~6 days, memory and CPU trends	Not an Amazon VPC CNI job — a CNI scrape does not forecast a quiet volume filling up
SSH brute-force detection	Built-in — parses auth.log every scan	Never — Amazon VPC CNI does not read auth.log, journald, or host firewall state
Machine offline detection	Agent presence monitoring with multi-channel alerts	Silence if the agent dies — unless you built an up{job="aws-node"} deadman check
Public status page	Shareable URL with 90-day history	None — Amazon VPC CNI has no customer-facing status page
Weekly fleet digest	Automated Monday digest + daily brief when issues are open	None — an ENI scrape target is not a plain-English fleet narrative
On-call tracking	Built-in /oncall command + incident acknowledgment	Not included — wire Alertmanager into PagerDuty or another incident tool
Conversation interface	Telegram, WhatsApp, web dashboard, CLI	kubectl and Grafana. No mechanic you text when /var filled and aws-node still showed IPs
Learning curve	None — works after install	Steep — IPAMD, ENI limits, prefix delegation, security groups for pods, PromQL, and which assigned-IP counter actually pages
Best for	Freelancers, small teams, accidental sysadmins (1-50 Linux servers)	Teams that already run EKS and need VPC CNI scrapes, not a sick-VPS mechanic

When Amazon VPC CNI metrics are the right choice

Keep scraping Amazon VPC CNI when you already want that exact job:

EKS CNI SLOs — you need ENI allocation, IPAMD warm pool, and prefix-delegation counters, not a mechanic.
Pod IP density at cluster scale — security groups for pods and WARM_IP_TARGET matter more than host nginx, certs, and SSH on a quiet VPS.
An existing Prometheus + Grafana stack — aws-node already clusters, IPAMD already scrapes, and someone owns ENI quotas.
Hosts that only page on Amazon VPC CNI — you already run exporters and PromQL, not a sick-box SSH loop.

The real cost of “just scrape Amazon VPC CNI”

Amazon VPC CNI is a serious EKS CNI. A working ops loop for five Linux boxes is not:

A healthy awscni_assigned_ip_addresses still means you SSH in and change the box by hand
Host fill, nginx, certs, and SSH brute-force never appear unless Prometheus scraped those signals and a rule fired
A filling /var is a Tink disk warning on every scan — Amazon VPC CNI will stay quiet until the ENI pool itself is the failure
A single VPS with a dead aws-node still needs a mechanic, not another CNI scrape

For a 5-server team, Tink Mechanic at $45/month is cheaper than Amazon VPC CNI plus the engineer who keeps Prometheus scrapes and IPAMD warm-pool rules alive, and every scan includes a diagnosis a quiet Grafana board will not type.

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

Start Mechanic

Also compare: Tink vs Calico · Tink vs Cilium · Tink vs Prometheus