THE FIELD GUIDE / OPERATIONS
Workers, databases & scale
Durable jobs, coordinated workers and offline database migration.
Scale workers
docker compose up -d --build --scale worker=3Keep one web process. Workers claim durable SQL jobs and coordinate with per-host locks. An elected coordinator handles polling and scheduling; backpressure, jitter and metadata-cache quotas control pressure.
Choose storage
SQLite workers on one host share the same local app volume. For workers on separate hosts use MySQL with consistent identity and encryption storage. SQLite over NFS and independent identity disks are unsupported.
Migrate deliberately
Settings → Database stages a destination. The offline workflow stops app and workers, checks the source and empty destination, copies application tables, verifies row counts and content fingerprints, then activates the destination. SQLite ↔ MySQL preserves the source. Changing DATABASE_URL alone does not migrate existing records.
Choose the deployment role
Use complete, controller-only or worker-only deployment modes with explicit identity/key provisioning, schema and receipt-protocol compatibility, shared-state checks and independent lifecycle management. Compare deployment topologies.
Readiness and graceful drain
Expected-worker inventory keeps missing workers visible. Distinct worker/boot identities, heartbeats, role-specific readiness and configured capacity distinguish process liveness from permission to claim work. Drain stops new claims and records active-job recovery without blindly replaying target mutations. Read the deployment health guide.
Observe operations
Authenticated metrics, filtered and paginated fleet views, AI activity and durable job history help diagnose the controller. Size compute, database and storage from your own fleet’s telemetry and retention requirements.
Open the application reference for capability scope and technical details.
Open Open DATABASE_MIGRATION.md on GitHub ↗