What it watches
Servers, Docker containers, PM2 processes, systemd units and HTTP/TCP endpoints — grouped into services with check history.
Open source · Self-hosted · MIT
Know when your servers go down. Restart them safely.
Watchtower watches your servers, Docker containers, PM2 processes, systemd services and endpoints over SSH — no agents to install. Get push alerts, see incidents, and restart a service with a typed confirmation and a full audit trail.
Runs on your own infrastructure. Your SSH keys never leave your database, encrypted.
- Servers
- 4
- Services
- 6
- Incidents
- 1
ServiceLast 24hStatus
web-01ServerHealthy
apiPM2Healthy
postgresDockerHealthy
ssh-guardsystemdHealthy
edge-tcpTCPDegraded
status-pageHTTPHealthyIncidentRecovered
INCIDENTedge-tcp · TCP check timing out2m ago
- Next.js
- Fastify
- Prisma
- PostgreSQL
- Web Push
- SSH
Why self-hosted
Your infrastructure, your data, your rules.
Watchtower is deliberately simple software you run yourself, not a service you hand your servers over to.
- 01
No agents
The API talks to your servers over SSH when needed and runs its own in-process scheduler. Nothing to install on the machines you watch — no Kubernetes, no message queues, no custom agents.
- 02
Your keys, your database
SSH keys are encrypted at rest with AES-256-GCM and stored in your own database. They are never returned by any API response, and decrypted only in memory for one operation.
- 03
Small enough to read
A pnpm + Turborepo monorepo with Vitest tests. The codebase is small enough to audit rather than take on faith.
Features
Everything a small ops team actually needs.
Deliberately simple: one dashboard, one API, one scheduler running in-process.
Incidents
Failed checks become incidents you can see, alongside the history of every check result.
Push notifications & PWA
Web Push alerts to your devices, and the dashboard installs as a PWA.
Projects & roles
Multiple isolated projects, each with its own servers, services, checks, incidents, audit logs, API keys and members. Owners/admins manage, members are read-only.
Safe restarts
Restart Docker, PM2 and systemd services: type the exact service name to confirm, the server validates it strictly, and an audit entry records whether it worked.
Audit log
Who restarted what, and whether it worked — recorded for every restart action.
API keys
Per-project API keys, isolated to the project that issued them.
Encrypted SSH keys
AES-256-GCM at rest, master key only in the API environment, decrypted in memory for one operation.
How it works
From zero to watched in four steps.
- 01
Add a server
Paste an SSH key. The API talks to your servers over SSH when needed, and keys are encrypted with AES-256-GCM before they touch the database.
- 02
Choose what to watch
Servers, Docker containers, PM2 processes, systemd units, HTTP and TCP endpoints — grouped into services.
- 03
Get alerted
Push notifications arrive as Web Push, and incidents land on the dashboard — a PWA you can install.
- 04
Restart with confirmation, audited
Type the exact service name. Strict server-side validation runs, the restart happens over SSH, and the audit log records who did it and whether it worked.
Security
SSH keys are the crown jewels. They stay yours.
Watchtower needs SSH access to do its job, so the design assumes your keys are worth stealing and behaves accordingly.
AES-256-GCM at rest
SSH keys are encrypted in the database before they are ever written.
Master key only in the environment
It lives in the API environment, and the API refuses to start without it.
Keys never in responses
No API response ever returns a private key. Decryption happens in memory only for the duration of one operation.
TOFU host-key pinning
Trust on first connect, the same model as OpenSSH known_hosts. A changed host key is refused.
Dedicated monitor user
Grant a restricted SSH user instead of full access — the docs show how. Watchtower runs a fixed allowlist: list, inspect, logs, restart.
Typed-confirmation restarts
Every restart needs an authenticated session, a UI confirmation where you type the exact service name, and strict server-side name validation.
Audit log
Every restart is recorded: who restarted what, and whether it worked.
Compare
Where it fits.
Uptime Kuma is excellent if you only need uptime checks and status pages — pick it for that. Watchtower leans on SSH and audited restarts instead.
| Watchtower | Uptime Kuma | Beszel | Netdata | |
|---|---|---|---|---|
| Strongest at | SSH-based server/Docker/PM2/systemd checks + audited restarts | Simple uptime checks and status pages | Lightweight server metrics with an agent | Deep real-time metrics |
| Needs an agent on your servers | No (uses SSH) | No | Yes | Yes |
| Restart services from the UI | Yes, typed confirmation + audit log | No | No | No |
| Multi-project isolation | Yes | — | — | — |
Comparison reflects the author's understanding and may be out of date. Check each project's docs.
Quickstart
Run it yourself.
Clone, set two secrets, migrate, create your user, and go. No public signup: users are created with a CLI command.
- Node 22+runtime for the monorepo
- pnpm 10+package manager
- Dockerto run Postgres
bash
$ git clone https://github.com/SyedEhsan06/watchtower.git
$ cd watchtower
$ pnpm install
$ docker compose up -d # Postgres
$ openssl rand -hex 32 # AUTH_SECRET and SSH_MASTER_ENCRYPTION_KEY (run twice)
$ pnpm db:migrate
$ cd apps/api && pnpm create-user you@example.com "a-strong-password"
$ cd ../.. && pnpm dev # web :3000, api :4000
Then open the dashboard on :3000 and the API on:4000.
FAQ
Straight answers.
Is it free?
Yes. Watchtower is MIT licensed and free to use.
Is there a hosted version?
No — self-hosted only, by design, because it uses your SSH keys.
Do I need to install anything on my servers?
No agent. The API talks to your servers over SSH when needed. A restricted monitor SSH user is recommended.
Is it safe to give it Docker access?
Be clear-eyed about it: Docker group access is root-equivalent on that host. Grant it only where that trade-off is acceptable, and use a dedicated restricted user for day-to-day monitoring.
Can my team use it?
Yes. Projects have owner, admin and member roles — owners and admins manage a project, members are read-only. There is no public signup; users are created with a CLI command.
How do I contribute?
GitHub issues and pull requests.
Get started
Run it on your own server in about 10 minutes.
A rough estimate: clone the repo, start Postgres, set two secrets, migrate, create your user, and go.