DevOps¶

Index of how VeriLib is deployed, scaled, and operated. Detailed AWS setup lives in the component repos — this section is the cross-repo view.

The three deploy targets¶

VeriLib does not have one deployment model. It has three, and they share almost nothing:

Component	Runs on	Deployed by	Detail
verilib-frontend	Apache + PHP-FPM on a server	`scripts/deploy.sh` + GitHub Actions artifacts	Deployment procedure
verilib-atomizer	ECS on EC2 (not Fargate)	`deploy/scripts/build_and_push.sh` → `deploy.sh`	ECR on ECS
local_validate	Long-running Python consumers	`uv run python scripts/run_*_processor.py`	Worker

Nothing serves inbound HTTP except the frontend. The workers are headless queue consumers with no load balancer.

Page	Covers
Deployment procedure	Deploying each of the three components
Scalability	Queue-depth autoscaling, capacity limits, the single-instance constraint
Performance	Timeouts, prefetch, retry timing, and how they interact
Security	Trust boundaries, credential flow, threat model
Local env	Running the stack locally
Logging / Grafana	Log and metric collection
Alert System, Netdata, Betterstack	Monitoring tooling
Incident management	On-call and incident process
Scripts	Ops helper scripts

These come up in almost every incident:

The cert workers hold no database credentials. They are DB-free by design; the frontend applies every result. See Database.
MySQL is managed (Amazon RDS) and not publicly reachable. Connect from a host allowed by its security group, and remember that a restore produces a new endpoint. See Managed.
RABBITMQ_VHOST has different defaults per repo. A vhost mismatch produces no error — just silence. See Configuration.
Queue topology arguments are a joint contract. Changing one side produces a 406 PRECONDITION_FAILED at startup on the other. See Message contracts.
Run at most one promote_processor when mainnet anchoring is enabled — the dedup scan is a check-then-act race.
Durable artifacts belong in S3, never on an ECS instance. See Disk cleanup.