Tink vs Caddy
Caddy is an automatic-HTTPS web server and reverse proxy. That is not a mechanic. Tink installs in one command, watches the Linux server, explains what is wrong, and helps you fix it.
Caddy keeps HTTPS green. Tink answers “why is this VPS sick?”
Accidental sysadmins land on Caddy because automatic TLS is the right default. Then the volume fills, Postgres dies, and the site still served a cert — no access-log line matched host fill. A filling /var is a Tink warning; it is not a Caddyfile job unless the proxy 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 Caddy if you already terminate TLS on the box. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | Caddy |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Minutes to hours — Caddyfile, reverse_proxy, automatic HTTPS, and still no host mechanic |
| What you get | Working monitoring, diagnosis, and approved fixes | HTTP serving and TLS. Disk fill, SSH brute-force, and a quiet Postgres stay your problem until the site 502s |
| Pricing | Free (Scout) / $9 / $29 per machine per month | Open-source (Apache 2.0). You still pay the VPS and the person who reads Caddy logs when /var fills |
| Hidden costs | None — fully managed | Caddyfile reloads, ACME failures, admin API exposure, and a second tool that pages you when memory climbs |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | Request access logs and optional Prometheus metrics. Caddy does not watch host fill or auth.log |
| Configuration | None after install — heuristics and AI | Caddyfile site blocks, reverse_proxy, tls, and whether the admin API is bound to localhost |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | You grep access.log for 502s, then SSH in to change the box |
| Fix execution | Proposes and executes approved commands with an audit trail | Proxy only — Caddy cannot free disk, restart Postgres, or fail2ban an attacking IP |
| Alerting | Built-in across 8 channels | Not a Caddy job — scrape metrics or tail logs before anyone is paged about the host |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Never — Caddy answers HTTP after traffic already arrived. It does not forecast a quiet volume filling up |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — Caddy does not read auth.log, journald SSH, or host firewall state |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | Silence if the process dies — unless an outside uptime check already watches the site |
| Public status page | Shareable URL with 90-day history | None — Caddy has no customer-facing fleet status page |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — an access-log line is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire uptime checks into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | journalctl -u caddy. No mechanic you text when /var filled and HTTPS still looked fine |
| Learning curve | None — works after install | Moderate — Caddyfile, ACME, reverse_proxy, and which 502 actually means the box is sick |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run Caddy for HTTPS and still need a separate mechanic for the Linux host |
When Caddy is the right choice
Keep running Caddy when you already want that exact job:
- Automatic HTTPS — you need ACME certs and a reverse_proxy, not a mechanic.
- A small number of sites on one VPS — Caddyfile site blocks matter more than fleet health scores.
- An existing uptime check on the public hostname — you already know the site is up, and someone owns the Caddyfile.
- Hosts that only page on HTTP — you already scrape Caddy metrics, not a sick-box SSH loop.
The real cost of “just run Caddy”
Caddy is a serious web server. A working ops loop for five Linux boxes is not:
- A valid TLS cert still means you SSH in and change the box by hand
- Host fill, Postgres, and SSH brute-force never appear unless something else watched those signals
- A filling /var is a Tink disk warning on every scan — Caddy will stay quiet until the proxy itself 502s
- A single VPS with a dead Caddy still needs a mechanic, not another Caddyfile
For a 5-server team, Tink Mechanic at $45/month is cheaper than Caddy plus the engineer who tails access logs after the disk is already full, and every scan includes a diagnosis a quiet HTTPS handshake will not type.
No Caddyfile homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs ingress-nginx · Tink vs Nginx Exporter · Tink vs UptimeRobot