Deployment Automation with Codex

Your deployment process is a wiki page with 23 manual steps, including “SSH into the server and run these four commands.” The last time someone skipped step 14, production went down for 20 minutes. You need to containerize the application, automate the deployment pipeline, and make sure every release is repeatable, testable, and reversible. Codex can generate the Docker configuration, write the deployment scripts, and validate everything in a cloud environment before it reaches production.

What You’ll Walk Away With

• Prompts for generating production-ready Dockerfiles and compose configurations
• A workflow for validating deployment scripts in Codex cloud environments
• Techniques for using the Codex GitHub Action to automate release preparation
• An automation recipe for weekly deployment readiness checks

The Workflow

Step 1: Generate Container Configuration

Start with a Local thread in the Codex App. Give Codex your current deployment constraints so it generates a practical configuration, not a textbook example.

Tip

Copy-paste prompt for Docker configuration:

Generate production Docker configuration for this Node.js/TypeScript project:

Dockerfile requirements:
- Multi-stage build: dependencies stage, build stage, production stage
- Use node:20-alpine as the base
- Install only production dependencies in the final stage
- Run as non-root user
- Include health check endpoint (GET /health on port 3000)
- Set NODE_ENV=production
- Handle SIGTERM for graceful shutdown

docker-compose.yml for local development:
- App service with hot reload (mount src/ as volume)
- PostgreSQL 16 with persistent volume
- Redis 7 for session storage
- Proper dependency ordering (app depends on db and redis)

docker-compose.prod.yml (production overrides):
- No volume mounts
- Resource limits (memory, CPU)
- Restart policy: unless-stopped
- Environment variables from .env.production

Read the current package.json for the build and start scripts.

Step 2: Validate in Cloud

Before trusting the Docker configuration, validate it in a Codex cloud environment. Cloud tasks run in containers themselves, making them ideal for testing container builds.

codex cloud exec --env deployment-test "Build the Docker image using the Dockerfile we generated. Run the container and verify:
1. The health check endpoint responds with 200
2. The application can connect to PostgreSQL (use the compose database)
3. The container starts in under 10 seconds
4. The container shuts down gracefully on SIGTERM (no orphaned connections)
5. The final image size (should be under 200MB for an Alpine-based Node image)

Report the results for each check."

Step 3: Generate Deployment Scripts

Replace the 23-step wiki page with automated scripts:

Tip

Copy-paste prompt for deployment script generation:

Create a deployment script at scripts/deploy.sh that automates our production deployment:

1. Pre-flight checks:
   - Verify the current branch is main
   - Verify all tests pass (npm test)
   - Verify the Docker image builds successfully
   - Verify no uncommitted changes

2. Build and tag:
   - Build the Docker image with the git SHA as the tag
   - Tag as both :latest and :<git-sha>

3. Database migration:
   - Run pending migrations against the production database
   - Verify migrations completed successfully
   - If migration fails, exit with error (do not proceed to deployment)

4. Deploy:
   - Push the new image to the registry
   - Update the running container with zero-downtime (rolling restart)
   - Wait for health check to pass on the new container

5. Post-deployment:
   - Verify the deployed version matches the expected git SHA
   - Run a smoke test (curl the health endpoint and one API endpoint)
   - Log the deployment to a file with timestamp, SHA, and status

Include a rollback script (scripts/rollback.sh) that reverts to the previous image tag.
Make both scripts executable and include error handling at every step.

Step 4: Automate Release Prep with the GitHub Action

Use the Codex GitHub Action to prepare releases automatically when a PR is merged to main:

name: Release preparation
on:
  push:
    branches: [main]

jobs:
  prepare-release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Prepare release with Codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: |
            Analyze all commits since the last git tag. Generate:
            1. A changelog entry following Keep a Changelog format
            2. A suggested version bump (major/minor/patch) based on the changes
            3. A release summary suitable for a GitHub Release description

            Output the results in a structured format.
          sandbox: read-only
          safety-strategy: drop-sudo

Step 5: Schedule Deployment Readiness Checks

Set up an automation in the Codex App that verifies your deployment pipeline is healthy:

Tip

Copy-paste automation prompt for deployment readiness:

Weekly deployment readiness check:

1. Verify the Dockerfile builds successfully (docker build .)
2. Verify docker-compose.yml starts all services (docker compose up -d --wait)
3. Run the health check endpoint
4. Run the smoke test script if it exists
5. Check that scripts/deploy.sh and scripts/rollback.sh are executable and have no syntax errors
6. Verify that the database migration can run from a clean state (fresh database)

Report any failures with specific error messages and suggested fixes.
If everything passes, report that deployment infrastructure is healthy.

When This Breaks

Docker build works locally but fails in CI. Common causes: local Docker cache providing layers that CI does not have, or architecture differences (ARM vs x86). Add --no-cache to your CI build step and explicitly specify --platform linux/amd64 if your CI runs on a different architecture.

Database migration step takes too long in production. If a migration adds an index on a large table, it can lock the table for the duration. Always test migration duration against production-sized data in a cloud environment before deploying. Include “estimate migration duration based on table size” in your migration generation prompts.

Health check passes but the application is not actually ready. A basic health check that returns 200 immediately does not verify that database connections are established or caches are warm. Tell Codex: “The health check should verify database connectivity, Redis connectivity, and that the application has completed initialization. Return 503 until all dependencies are ready.”

Rollback script does not account for database migrations. If you deployed a new version with a schema change and need to roll back, the old code may not work with the new schema. Include down migrations in your deployment process and ensure the rollback script runs them.

What’s Next

CI/CD with Codex GitHub Action Build comprehensive CI/CD pipelines with the Codex GitHub Action

Security Scanning with Codex Add security checks to your deployment pipeline