Operations overview

How to run VerifAIer in production, documented exactly as implemented. Where a capability is a metadata foundation or delegated to your infrastructure, this says so plainly.

Operations overview

VerifAIer is a self-hosted, local-first FastAPI service. The backend runs as a container (or a plain uvicorn process); the docs site, marketing site and Streamlit dashboards are separate static/UI surfaces. There is no managed SaaS control plane: you operate it on your own infrastructure.

pyproject.toml · Dockerfile · docker-compose.yml · vercel.json · src/vailidator/

flowchart LR
  subgraph HOST["Your host / VPC (local-first)"]
    RP["Reverse proxy, TLS, rate limit, timeouts (your gateway)"]
    subgraph COMPOSE["docker compose"]
      API["api, FastAPI / uvicorn :8000
vailidator.api.routes:app"]
      DASH["dashboard, Streamlit :8501"]
      CC["cc_dashboard, Streamlit :8502"]
      VOL[("db_data volume
/app/data/vailidator.db")]
    end
  end
  LIVE["Optional live AI provider (egress only if enabled+keyed+live)"]
  RP --> API
  DASH --> API
  CC --> API
  API --- VOL
  API -.->|opt-in| LIVE

Reference topology. Grounded in Dockerfile + docker-compose.yml. Backend is self-hosted; egress is opt-in.

Component	Runtime	Port
API (Evidence Engine)	uvicorn `vailidator.api.routes:app`	8000
Operator dashboard	Streamlit `apps/dashboard/app.py`	8501
Control Center dashboard	Streamlit `apps/cc_dashboard/app.py`	8502
Docs / marketing site	static HTML (`demo/`)	via Vercel / any static host

Operational responsibilities

The clearest way to operate VerifAIer safely is to know exactly which line each concern falls on. The app owns the deterministic evidence path; your infrastructure owns the edge and durability.

Concern	VerifAIer app	You / deployment infra
TLS / HTTPS	n/a	terminate at your reverse proxy / platform
General rate limiting & quotas	login only (per-IP)	gateway (all other traffic)
Request timeouts	upstream provider call only	gateway / client per-request timeout
Secrets storage	reads from env; never logs/echoes	inject via env / secret manager
Database durability	writes SQLite at `DB_PATH`	persist & back up the volume/file
Backup / restore / DR	records metadata only	perform actual backup I/O + restore
Authentication	sessions + API keys (self-hosted)	add SSO/MFA at the gateway if needed
Authorization (RBAC)	authentication-gated; RBAC reserved	enforce fine-grained authz at the gateway
Monitoring / alerting	exposes `/health` + status endpoints + JSON logs	scrape, alert, page
Horizontal scale / HA	single-node SQLite by default	front with LB; use Postgres (`DATABASE_URL`) for multi-node

Read this first. Several enterprise concerns, general rate limiting, RBAC, backup/restore I/O, HA, are deliberately not in the app today. They are documented as known gaps with the responsible layer named, so you can close them at your gateway/infra rather than assume they are handled.

Operations documentation index

#	Topic	Where
1	Configuration reference	ops-config
2	Environment variable reference	ops-config
3	Provider configuration	ops-config
4	Local development runbook	ops-runbooks
5	Docker runbook	ops-runbooks
6	docker-compose runbook	ops-runbooks
7	Production deployment guide	ops-deploy
8	Vercel / static site deployment	ops-deploy
9	Backend hosting requirements	ops-deploy
10	Health checks	ops-runbooks
11	Logging posture	ops-observability
12	Secret handling	ops-resilience
13	Backup posture	ops-resilience
14	Restore posture	ops-resilience
15	Disaster recovery posture	ops-resilience
16	Upgrade guide	ops-deploy
17	Release checklist	ops-hardening
18	Smoke tests	ops-observability
19	Monitoring checklist	ops-observability
20	Security hardening checklist	ops-hardening
21	Known production gaps	ops-hardening
22	Operational responsibilities	this page