§ 01 / DefinitionWhat Watchtower is
Watchtower is a self-hosted platform for keeping an eye on a fleet of machines — the containers, services, scheduled tasks, and disks across every host you run. A lightweight agent lives on each machine and pushes what it sees to a central hub.
What it deliberately is not is a dashboard you click through. The primary interface is a conversation: you ask an assistant what is wrong, and it reads the fleet's state to answer. The clicking-through-panels model does not scale past a handful of hosts; a question does.
§ 02 / PrincipleSensing, and only sensing
The load-bearing design choice is a subtraction. Watchtower observes and reports — health, state, events, ambient conditions — and it dispatches and executes nothing. Acting on a machine is a separate concern, owned by a separate part of the platform, reached through a separate gate.
Keeping the senses strictly afferent buys a clean guarantee: a component that can only observe cannot be tricked into acting. There is no code path from Watchtower to a changed machine, so a compromised or confused sensor's worst case is a wrong reading — never a wrong action. Readings can be cross-checked, weighted by a source's track record, and audited after the fact. That is a far smaller blast radius than a sensor that can also pull triggers.
§ 03 / TransportThe host always dials out
The hub never dials an agent. Every connection is opened by the agent, outward — the agent pushes its metrics and events on its own cadence, and even live streams (log tails, resource stats) travel back down a connection the agent itself opened. Nothing reaches inward to a managed host.
each managed host central
┌──────────────────┐ ┌──────────┐
│ agent │ ──push metrics──▶ │ │
│ · collectors │ ──push events───▶ │ hub │
│ · watchers │ ◀─pull config──── │ │
│ │ ◀═live streams═══ │ │
└──────────────────┘ (agent-dialed) └──────────┘
the host originates every connection — nothing dials in
This matters for where Watchtower can run. Because agents reach out rather than being reached, a host behind a firewall or on a laptop that comes and goes needs no inbound access, no exposed port, no exception. Missing a push is not an error — the next one supersedes it — and if the hub is briefly unreachable, durable events queue on disk and drain when it returns.
§ 04 / InterfaceManaged by conversation
Watchtower exposes its read surface to an assistant over MCP, so the fleet becomes something you interrogate in plain language rather than navigate:
- You: "This host has been sluggish — what's wrong?"
- Assistant: reads the host's diagnostics — CPU pinned at 94%, a container running eighteen hours with no output, last night's backup job failed at 3am because a volume hit 98%.
- The answer names the cause, not a wall of graphs. The graphs still exist; you just don't have to be the one correlating them.
Everything on this surface is observation. When the same conversation needs to act — kill that container, reclaim that volume — the action does not run through Watchtower. It crosses the platform's authorization gate first, and is carried out by the part of the system whose entire job is doing things carefully. The senses and the hands are different bodies on purpose.
§ 05 / ReflexesFast, local, pre-wired
Not everything should wait for a conversation. Watchtower's hub carries simple local reflexes — a container that crashes, a watched service that stops, a host that goes quiet past its interval — that fire an alert immediately, without troubling the reasoning layer.
Anatomically this is the sensory spinal cord: it relays sensation inward and fires simple reflexes on its own, but it originates nothing and decides nothing. A reflex raises attention; it does not take an action on a machine. Crash and stop detection are event-driven, so the latency between something going wrong and someone knowing is near zero rather than one polling interval.
§ 06 / ScaleOne control plane, many kinds of host
The transport, identity, audit, targeting, and alerting machinery is host-type agnostic. What a host is — its operational vocabulary and its health signals — is contributed by a per-substrate provider, so a new kind of machine plugs in without the core learning about it.
| Stays universal | Contributed per substrate |
|---|---|
| identity | Every host is a stable UUID; the agent authenticates with a key that is only ever stored hashed. The hostname is informational. |
| metrics | CPU, memory, disk, uptime are common to every OS, so threshold alerts work on any host on day one. A substrate adds its own typed snapshot on top. |
| vocabulary | Docker speaks containers and images; Windows speaks services and scheduled tasks. Each provider declares its own; the hub validates against the right one per host. |
| events | A crash is a crash; the universal alert kinds fire everywhere, while a substrate contributes its specific ones (a stopped service, a subsystem ending). |
§ 07 / BoundariesWhat Watchtower is not
- Not an actuator. It does not change hosts. Every action lives behind the authorization gate, in a different part of the platform. This is the invariant, not an accident of the current build.
- Not a click-through dashboard. There are live views, but the intended interface is a conversation. If you want panels to hunt through, this is the wrong tool.
- Not an agent that decides. The hub's reflexes are fixed stimulus-and-response, not judgement. Decisions that need reasoning are made elsewhere and remain accountable there.
- Not an inbound service on your hosts. Agents dial out. Nothing on a managed machine listens for the hub.