Production Checklist

Use this checklist before promoting your console deployment to production.

Required Environment Variables

These must be set or the server will not function correctly:

Security

• HTTPS enabled — EDICTUM_BASE_URL starts with https://. Without it, session cookies lack the Secure flag and are transmitted in cleartext. The server logs a warning at startup if HTTP is detected.
• CORS origins configured — EDICTUM_CORS_ORIGINS set to your domain(s). The server rejects wildcard * and strips localhost origins when base_url is non-localhost.
• Environment set to production — EDICTUM_ENV_NAME=production hides /docs, /redoc, and /openapi.json endpoints.
• Admin account created — either via EDICTUM_ADMIN_EMAIL + EDICTUM_ADMIN_PASSWORD (min 12 chars) or through the /dashboard/setup wizard on first visit.
• Signing key configured — EDICTUM_SIGNING_KEY_SECRET set. Without it, bundle signing is unavailable and deployments push unsigned YAML.
• Rate limiting verified — default is 10 login attempts per 300 seconds per IP. Adjust with EDICTUM_RATE_LIMIT_MAX_ATTEMPTS and EDICTUM_RATE_LIMIT_WINDOW_SECONDS if needed.
• Trusted proxies set — if behind a reverse proxy, set EDICTUM_TRUSTED_PROXIES to your proxy IPs (comma-separated) to enable correct X-Forwarded-For parsing for rate limits.

Database

• Managed Postgres recommended — use RDS, Cloud SQL, or equivalent for automated backups, replication, and failover. The Kustomize manifests include a single-replica StatefulSet for development only.
• Backup schedule configured — Edictum does not manage backups. Set up daily automated snapshots.
• Backup restore tested — verify you can restore from a snapshot and the console starts correctly.
• Event partitioning verified — the console automatically creates monthly partitions for the Event table (next 3 months). Check the background worker is running: GET /api/v1/health → workers.partition: "running".
• Event retention policy set — configure purge from Settings → Danger Zone (30/60/90 days). Events grow without bounds if not purged.

Redis

• Managed Redis recommended — use ElastiCache, Upstash, or equivalent. The default Kustomize manifests run Redis without persistence (--save "" --appendonly no).
• TLS enabled — use rediss:// URL for encrypted connections (Upstash, ElastiCache with in-transit encryption).
• Understand the failure mode — if Redis goes down, sessions are lost (users must re-login) and rate limiting is bypassed until Redis recovers.

Monitoring

• Health endpoint monitored — poll GET /api/v1/health and alert on status: "degraded". The response includes database latency, Redis connectivity, connected agent count, and worker status.
• Readiness probe configured — GET /api/v1/health/ready returns 503 when Postgres or Redis is down or any worker has crashed. Use as Kubernetes readiness probe.
• Liveness probe configured — GET /api/v1/health/live returns 200 if the process is alive. Use as Kubernetes liveness probe.
• Worker health checked — the health response includes workers.approval_timeout and workers.partition status. Alert on "crashed" or "stopped". A built-in monitor auto-restarts crashed workers within 60 seconds.

Deployment

• Single replica — the console does not support horizontal scaling yet. Run exactly one replica. The deployment strategy should be Recreate (not RollingUpdate) to prevent concurrent Alembic migrations.
• Migration lock — Alembic uses PostgreSQL advisory lock (id=43) to prevent concurrent schema migrations. The startup probe should allow 120 seconds for migrations on first deploy.
• Session TTL reviewed — default is 24 hours (EDICTUM_SESSION_TTL_HOURS). Adjust based on your security policy.

Notification Channels

• At least one channel configured — if using HITL approvals, configure Slack, Telegram, Discord, webhook, or email from Settings → Notification Channels.
• Test button clicked — each channel has a test button. Verify delivery before relying on it for production approvals.
• Routing filters set — configure per-channel filters (environments, agent patterns, contract names) to avoid alert fatigue.
• Understand the failure mode — if a notification channel fails (SMTP down, Slack rate-limited), the approval still proceeds — it just isn't notified. Channels fail independently; one failure doesn't block others.

Agent Connectivity

• Agent SDK version matches — agents should use edictum[server] v0.15.0+. Older SDK versions may omit bundle_name in event payloads.
• API keys created — create environment-scoped API keys from the dashboard. The full key is shown once and cannot be retrieved again.
• SSE connection verified — after connecting an agent, check Fleet Monitoring for the agent's entry. If missing, check the API key, agent ID, and network connectivity.
• Drift monitoring enabled — after deploying a bundle, verify agents show the correct policy_version in Fleet Monitoring. Drifted agents typically resolve automatically when the SSE connection reconnects.

Next Steps

• Console setup — local development quickstart
• Self-hosting guide — build from source, troubleshooting
• Failure modes — what happens when components fail
• Fleet monitoring — drift detection and coverage analysis