/deploy-production

Operations L4 Production low usage

/deploy-production

Overview

The /deploy-production command executes safe, validated production deployments of the Prismatic Platform to Fly.io infrastructure. Production deployment is the highest-stakes operation in the platform lifecycle -- a failed deployment can result in service downtime, data inconsistency, or user impact. This command wraps the deployment process in comprehensive safety checks, mandatory quality gates, automatic health validation, and prepared rollback procedures to minimize risk.

The command enforces a strict deployment protocol: all staging tests must have passed, the working directory must be clean (no uncommitted changes), quality gates must report green across all 13 domains, database migrations must be validated, and a rollback path must be tested and ready before any production deployment begins. Only after these prerequisites are satisfied does the actual deployment proceed, followed by continuous health monitoring for the first 10 seconds with automatic rollback if health checks fail.

This command operates under the L4 authority level -- the highest non-SUPREME authority in the platform hierarchy -- reflecting the critical nature of production deployments. It is executed by the fly-io-deployment-agent agent and is part of the platform's 216-command slash command registry, built on the AIAD (Autonomous Intelligence Agent Design) standard. The L4 authority requirement ensures that only authorized operators can trigger production deployments, and that every deployment is traceable and auditable.

The Prismatic Platform runs on Fly.io's global edge infrastructure, with the production application accessible at prismatic-prod.fly.dev and the staging environment at prismatic-staging.fly.dev. Deployments use Fly.io's rolling update strategy by default, which replaces instances gradually to maintain availability during the transition. The command also supports manual rollback control for situations where automatic rollback is insufficient.

Architecture

Deployment Pipeline

/deploy-production [version]
    |
    v
PRE-DEPLOYMENT GATES
    +-- Clean working directory verification
    +-- Quality gates pass (all 13 domains)
    +-- Staging deployment verified
    +-- Database migrations validated
    +-- Rollback tested and ready
    +-- Explicit operator confirmation
    |
    v
DEPLOYMENT EXECUTION
    +-- Fly.io deployment trigger
    +-- Rolling update strategy
    +-- Instance replacement
    +-- Health check monitoring
    |
    v
POST-DEPLOYMENT VALIDATION
    +-- Health endpoint verification (10s window)
    +-- Response time validation (< 250ms)
    +-- Error rate monitoring (0% tolerance)
    +-- Database connectivity check
    |
    v
STABILIZATION MONITORING
    +-- 24-hour monitoring window
    +-- Performance metric tracking
    +-- Error rate alerting
    +-- Auto-rollback on degradation

Infrastructure Topology

ComponentStagingProduction
App Nameprismatic-stagingprismatic
URLprismatic-staging.fly.devprismatic-prod.fly.dev
Configfly.staging.tomlfly.toml
Health Endpoint/health/health
Deploy StrategyRollingRolling
Min Instances12

Usage

Standard Production Deployment

# Deploy specific version to production with auto-rollback
/deploy-production v2.1.0

# Deploy with manual rollback control
/deploy-production v2.1.0 manual

# Deploy latest (from current branch state)
/deploy-production latest

Dry Run

# Preview what production deploy would do
/deploy-production v2.1.0 --dry-run

Rollback

# Rollback to previous version
/deploy-production rollback

# Rollback to specific version
/deploy-production rollback v2.0.9

Options & Parameters

ParameterPositionRequiredTypeDefaultDescription
version$1Yesstring--Version to deploy (e.g., v2.1.0, latest)
rollback_strategy$2NostringautoRollback strategy: auto (automatic on failure) or manual
--dry-runflagNobooleanfalseShow what would be done without executing
--skip-staging-checkflagNobooleanfalseSkip staging verification (requires explicit confirmation)
--monitoring-windowflagNointeger10Post-deploy health check window in seconds

Execution Flow

/deploy-production [version] [rollback_strategy]
    |
    v
PHASE 1: PRE-FLIGHT VALIDATION (< 30s)
    +-- Verify clean working directory (git status)
    +-- Confirm version exists and is tagged
    +-- Validate Fly.io credentials and access
    +-- Check staging deployment status
    +-- Run quality gates (mix quality.gates --quick)
    +-- Verify database migration compatibility
    |
    v
PHASE 2: OPERATOR CONFIRMATION (manual)
    +-- Display deployment summary
    +-- Show diff from current production version
    +-- List database migrations to run
    +-- Request explicit "yes" confirmation
    |
    v
PHASE 3: DEPLOYMENT EXECUTION (30-120s)
    +-- Trigger Fly.io deployment (fly deploy)
    +-- Monitor build progress
    +-- Track instance replacement
    +-- Wait for healthy instances
    |
    v
PHASE 4: HEALTH VALIDATION (10s window)
    +-- Poll /health endpoint every second
    +-- Verify response time < 250ms
    +-- Check error rate = 0%
    +-- Validate database connectivity
    +-- Confirm LiveView WebSocket connectivity
    |
    v
PHASE 5: POST-DEPLOYMENT (ongoing)
    +-- Log deployment event to telemetry
    +-- Record deployment in GitLab
    +-- Begin 24-hour monitoring window
    +-- Enable auto-rollback triggers
    +-- Notify stakeholders of successful deployment

Quality Gates Checklist

PRE-DEPLOYMENT QUALITY GATES
=============================
[ ] Compilation: zero warnings
[ ] Credo: zero violations (strict mode)
[ ] Dialyzer: zero warnings
[ ] Tests: all passing
[ ] Coverage: at or above baseline
[ ] Performance: all pages < 250ms
[ ] Database: migrations validated
[ ] Staging: deployment verified healthy
[ ] Rollback: previous version tested

Integration Points

ComponentRelationshipDetails
Prismatic AgentsExecuted by fly-io-deployment-agentAgent manages Fly.io deployment lifecycle
AIAD RegistryCommand specificationOperations category, L4 authority
Quality GatesMandatory pre-deployment validationAll 13 quality domains must pass
TelemetryDeployment metricsDeployment time, health status, rollback events
GitLab CI/CDPipeline integrationDeployment triggered from CI pipeline
Fly.ioInfrastructure providerApplication hosting and scaling
Page Load PerformancePost-deployment validationAll pages must load under 250ms

Fly.io Deployment Configuration

# fly.toml (production)
app = "prismatic"
primary_region = "fra"

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 4000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true

[[services]]
  protocol = "tcp"
  internal_port = 4000

  [[services.ports]]
    port = 80
    handlers = ["http"]

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]

  [[services.tcp_checks]]
    grace_period = "30s"
    interval = "15s"
    timeout = "10s"

  [[services.http_checks]]
    interval = 10000
    grace_period = "30s"
    method = "get"
    path = "/health"
    protocol = "http"
    timeout = 2000

Best Practices

  1. Always deploy to staging first -- Verify the exact same build on staging before promoting to production. Never deploy untested code directly to production.

  2. Deploy during low-traffic windows -- Schedule production deployments during off-peak hours to minimize user impact in case of issues.

  3. Monitor continuously for 24 hours -- The first 24 hours after deployment are critical. Monitor response times, error rates, and resource usage closely.

  4. Have the team on standby -- Ensure someone is available to respond to issues during and after production deployment.

  5. Use version tags, not branch references -- Always deploy tagged versions (v2.1.0) rather than branch tips to ensure reproducibility.

  6. Document deployment notes -- Record any notable changes, migration impacts, or configuration updates in the deployment log for post-incident reference.

Error Handling

ErrorCauseResolution
DIRTY_WORKING_DIRECTORYUncommitted changes presentCommit or stash changes before deploying
QUALITY_GATES_FAILEDOne or more quality domains failingFix quality violations before deployment
STAGING_NOT_VERIFIEDStaging deployment not confirmed healthyDeploy and verify staging first
FLY_AUTH_FAILEDFly.io authentication failureRun fly auth login to refresh credentials
HEALTH_CHECK_FAILEDPost-deployment health check failureAutomatic rollback triggers; investigate root cause
MIGRATION_CONFLICTDatabase migration incompatibilityResolve migration conflicts before deployment
ROLLBACK_FAILEDRollback to previous version failedManual intervention required; check Fly.io dashboard

Automatic Rollback Triggers

ROLLBACK TRIGGERS
=================
- Health endpoint returns non-200 for > 10 seconds
- Average response time exceeds 500ms for > 30 seconds
- Error rate exceeds 1% for > 60 seconds
- Database connection failures detected
- Memory usage exceeds 90% sustained for > 5 minutes

Advanced Usage

CI/CD Pipeline Integration

# .gitlab-ci.yml
deploy_production:
  stage: deploy
  script:
    - flyctl deploy --config fly.toml --strategy rolling
  environment:
    name: production
    url: https://prismatic-prod.fly.dev
  when: manual
  only:
    - tags
  dependencies:
    - deploy_staging
    - quality_gates

Manual Fly.io Operations

# Check current production status
fly status --app prismatic

# View production logs
fly logs --app prismatic

# SSH into production instance
fly ssh console --app prismatic

# Scale production instances
fly scale count 3 --app prismatic

# View deployment history
fly releases --app prismatic

Performance Validation

# Post-deployment performance check
defmodule PrismaticDeploy.PerformanceCheck do
  def validate_production do
    endpoints = ["/", "/perimeter", "/dashboard", "/health"]

    Enum.each(endpoints, fn path ->
      {time_ms, _response} = :timer.tc(fn ->
        HTTPoison.get!("https://prismatic-prod.fly.dev#{path}")
      end)

      time_ms = div(time_ms, 1000)

      if time_ms > 250 do
        raise "Performance violation: #{path} took #{time_ms}ms (limit: 250ms)"
      end
    end)
  end
end

Doctrine Compliance

All commands operate under the NO MERCY, NO DOUBTS doctrine:

  • NO MERCY: Zero tolerance for production deployments that bypass quality gates. Every deployment must pass all 13 quality domains. Every deployment must be health-validated. Automatic rollback is mandatory, not optional. Page load performance under 250ms is enforced, not suggested.
  • NO DOUBTS: Full pre-deployment verification through quality gates, staging confirmation, and migration validation. Post-deployment health checks use active probing, not cached state. Evidence-based deployment decisions with measurable metrics at every stage.
  • /deploy - Deployment to staging environment via GitLab CI/CD
  • /deploy-unified - Safe validated traceable deployment for all environments
  • /deploy-meilisearch - Meilisearch instance deployment and configuration
  • /quality-gates - Enforce quality gate checkpoints with zero-warning compilation validation
  • /commit - Smart commit with quality gates and conventional format
  • /emergency - Emergency response and crisis management activation

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL