Operate Web Fleet

Architecture

The architecture starts integrated and keeps subsystem boundaries explicit so scale does not require a rewrite.

Initial components

Browser dashboard
       │
       ▼
┌───────────────────────────┐
│ Web Fleet                 │
│                           │
│ API / auth                │
│ fleet queries             │
│ monitor scheduler         │
│ remote check workers      │
│ crawler                   │
│ analytics ingest/rollups  │  implemented
│ retention/maintenance     │  implemented
└──────────────┬────────────┘
               │
           SQLite first
        PostgreSQL at scale

Analytics remains separable

Analytics can share Web Fleet's site/auth/storage foundations while avoiding dependencies on monitoring, crawling, TLS or DNS features. That leaves open a future standalone deployment profile without duplicating the whole product today.

Frontend

The dashboard uses Nift as its build-time templating/dependency layer with ordinary HTML, CSS and JavaScript. Nift composes and tracks the frontend assets; runtime API and SPA behaviour stays in normal Go/browser code.

Data model

Organization
├── users / memberships
└── Groups
    └── Sites
        ├── Domains
        ├── Monitors ── Check results ── Incidents
        ├── Crawl/page/link observations
        ├── TLS/DNS/header observations
        ├── Analytics properties ── Events / rollups
        └── Deployment events

Clustering

Web Fleet can replicate its fleet topology/configuration across an explicit Raft cluster while keeping monitoring observations and external side effects node-local. See Clustering for the authority, storage and recovery contract.

Scale rule

Measure before adding infrastructure. Queues, specialized analytics databases and HA coordination should be introduced only when a documented workload demonstrates that the simpler architecture is insufficient.

Optional process roles

The default remains one integrated process. Larger deployments can separate responsibilities without changing the product model.

webfleet serve
webfleet worker
webfleet analytics-ingest

Web Fleet deliberately does not require Redis, Kafka or Kubernetes. The current CP25 scale decision is to add distributed infrastructure only after repeatable measurements justify it.