Core appliance
The app, MariaDB, cron scheduler, and standard Python worker form the local monitoring path.
localOwn your hardware
The Sentinel appliance runs the app, database, scheduler, and worker on infrastructure you control. The result is a monitoring history that belongs with the team responsible for acting on it.
The signal behind the check
Self-hosting changes the responsibility as well as the location: you operate the host, backups, updates, target access, notification credentials, and any proxy or external provider configuration. Outbound target and provider traffic can still leave the box.
Built to be specific
The app, MariaDB, cron scheduler, and standard Python worker form the local monitoring path.
localPro can use a separate Playwright worker for pages that need rendering. Chromium consumes materially more resources.
ProUse durable SSD-backed storage, test backups, keep updates deliberate, and choose retention with the run payload size in mind.
operatorReduce cadence or check count first. Use queue latency and service measurements before adding capacity or changing the deployment shape.
measuredMeasured profiles
These are dated deterministic fixture baselines, not generic hardware recommendations. Full queue, MariaDB, dashboard, storage-growth, and Playwright measurements must be recorded in docs/benchmarks before publishing CPU, RAM, SSD, architecture, or throughput numbers. Pro is uncapped by licence, not by compute or storage.
The network contract
The appliance needs outbound DNS and HTTP(S) access to monitored targets and any configured alert, licence, or provider endpoints. Inbound access and TLS remain operator responsibilities. A supplied proxy can provide the request context a target expects.
Start with the signal