Vigil Product tour Buy Vigil

Architecture

A small stack.
A clear operating model.

An application, a worker and PostgreSQL. Vigil runs where you deploy it, with optional remote probe agents and a browser runner when you need them.

Deployment model

Two processes.
One datastore.

You operate the infrastructure, backups and upgrades. The software includes Docker setup and ordered SQL migrations.

Application
The Next.js application serves dashboards, status pages and authenticated workflows.
Worker
The worker schedules checks and processes incidents, notifications and recovery through Postgres-backed queues.
PostgreSQL
One datastore holds the application state and queue. Optional remote probes and a synthetics runner add capabilities when you deploy them.

Supported check types

Protocol checks and monitor kinds, from the current registry. Some capabilities require the Commercial edition or an additional runner.

See edition boundaries →
Technical details and implementation notes

The blueprint, how the recovery runtime runs

Two processes. One datastore.

No Redis, no broker, no accidental complexity.

The full rationale ships in ARCHITECTURE.md, readable before you buy.

  • Next.js 16 · TypeScript strict · Postgres 18 · Drizzle · pg-boss · Docker
  • 4870 tests · CI · Multi-stage images

Tier 01 / Clients

  • Team browser
  • Public visitors

Tier 02 / Two processes

  • Web NEXT.JS 16: server actions + RBAC guards; dashboards · status pages (ISR); Anthropic API, optional.
  • Worker NODE 20.9+: cron tick, every minute; fan-out · dedup · adaptive scheduling; forty-two check types against your endpoints; a 500 ms plane beside it for the ones that need it; signed recovery triggers, verified; then runbooks, tasks and objectives on queues of their own.

Tier 03 / One datastore

PostgreSQL 18 DRIZZLE ORM · PG-BOSS

Application data + job queue in one database, no Redis, no message broker, one thing to back up.

First boot

One command. Ten minutes.

The compose file boots Postgres, runs migrations, starts the worker and serves the app. Bare-metal works too. Node 20.9+, two processes, one database.

See what boots

$ git clone git@vigil/vigil.git && cd vigil
$ docker compose up

✓ postgres   ready. :5432
✓ migrate    schema up to date
✓ worker     cron tick, queue live
✓ web        ready, http://localhost:3000

vigil is awake. watching begins now_

Illustrative output, the documented compose flow

The data model

Everything hangs off the organization.

Tenancy is structural, not bolted on. Every table is scoped to an org, and isolation is covered by tests.

organization
├── HAS → member
├── OWNS → monitors
│   └── PRODUCES → monitor_checks
├── RECOVERS VIA → recovery_actions
│   └── RECORDS → recovery_attempts
├── OWNS → incidents
│   └── TIMELINE → incident_events
└── HAS → status_pages
    └── SHOWS → status_page_monitors

Monitors open incidents on repeated failure, recovery fires, verifies, and every attempt stays on the books.

The math

You already know what these weeks cost.

Conservative estimates for one senior engineer building the same subsystems to the same standard, typed, tested, documented, hardened.

Subsystem What it actually involves Time
Auth + RBAC Sessions, orgs, invitations, role matrix, guard chain, tenancy isolation tests 3 wks
Monitoring engine Queue, scheduling fairness, dedup, drift, SSRF guards, state caching 3 wks
Incident system State machine, timelines, auto open/resolve, notifications 2 wks
Status pages Public read models, uptime aggregation, cache strategy, leak review 1.5 wks
AI features Prompting, guardrails, rate limits, graceful degradation 1 wk
Tests, CI, Docker 4870 tests, pipelines, images, architecture docs, seed tooling 3 wks
Total at $8-12k / month fully-loaded senior cost ≈ 13-14 wks

Thirteen weeks of engineering, already debugged.

Buy Vigil $149 Click through the demo

Your infrastructure. Your record.

See how Vigil handles an incident.