Architecture choices

The monitoring runs outbound-only. Everything else is optional to it.

The pieces

#	Piece	Must you host it?	Needs inbound traffic?
1	The executor — the monitoring itself	Yes	No
2	The API — watch management, AI features, mobile backend	No	Yes
3	The panel — the web UI	No	Static only
4	The database	Yes	No (from the pieces above)
5	Alert channels	Yes, at least one	No

Only 1 and 4 are required for Watcher to do its job.

A runner executes the CLI on a cron. No server, no uptime to manage, and it keeps working while everything else is down.

Choose this when you want the cheapest reliable setup and hourly (or slower) checks are enough.

pnpm serve runs the API and an in-process scheduler, so one process does everything.

Choose this when you want sub-hourly checks, or you are already running a container and would rather have one thing to operate.

Minimal — a scheduled CI job plus a managed database. No API, no panel; manage watches with the CLI and receive alerts on Telegram.

Typical — the above, plus the API on a small container host with SCHEDULER_ENABLED=false, and the panel on any static host.

Single box — one container running pnpm serve with the scheduler enabled, plus a database. Simplest to reason about; the box must stay up.

Concern	Guidance
Database	Anywhere the executor can reach it. If it restricts by IP, allow-list your runners
API host	Anything that runs a container. Suspend-when-idle is fine — see API hosting
Panel	Any static host
Region	Put the database near whatever runs most often
Secrets	The platform’s secret store, never the repository

The executor makes outbound calls only: database, model providers, the sites it watches, and the alert channels.
The API additionally accepts inbound HTTPS from the panel and the app.
The panel is static files; it talks only to the API.
Nothing needs a fixed public IP, and no piece needs to reach another piece except through the database.