Scope of This Checklist

Unit 14, Lesson 4 walked through a deployment checklist for one specific capstone app; this unit covers deployment and operations practices generally, for any OpenAI SDK application. This lesson consolidates that general material — from this unit's Lessons 1 through 9 — into a single checklist you can work through before any production deployment, regardless of what the specific application does. Each item names the concern, states why it matters, and points back to where in this unit it was covered in depth, so this lesson functions as a reference rather than a repeat of the explanations already given.

The checklist is organized into five categories: configuration and code readiness, containerization, secrets, background processing and scaling, and reliability and monitoring. Work through it top to bottom before a first production deployment; revisit the relevant section whenever you change something it covers.

Configuration and Code Readiness

1. All configuration is read from the environment, with no hardcoded values in source files. A hardcoded API key or model name forces manual edits before every deploy and risks secrets ending up in version control. (Lesson 1)
2. Configuration is validated once, at startup, and a missing or invalid value causes an immediate startup failure. Lazy validation inside a request handler turns a configuration mistake into a confusing user-facing error instead of a clear, immediate one. (Lesson 1)
3. Dependencies are pinned to exact versions, either in requirements.txt with == or via a lock file from a tool like Poetry or pip-tools. An unpinned dependency can silently change behavior between your tested environment and production. (Lesson 1)
4. The application has a single, clear entry point (an application factory function or equivalent) rather than top-level script logic that runs at import time. (Lesson 1)
5. All logging uses the logging module, not print(), with severity levels and, ideally, structured fields. (Lesson 1, Lesson 9)
6. The environment (development, staging, production) is explicit and validated, not inferred, and each environment has its own configuration defaults and its own API key. Reusing a single key across environments risks a development bug consuming production quota. (Lesson 2)
7. No .env file is committed to version control. Every .env* file is gitignored, with a tracked .env.example containing placeholder values for reference. (Lesson 2)
8. Feature flags gating expensive or unproven functionality are read as configuration, not hardcoded as always-on or always-off, so behavior can be adjusted per environment without a code change. (Lesson 2)

Containerization

1. The Dockerfile pins its base image to a specific version tag, never latest, so builds remain reproducible over time. (Lesson 3)
2. The image is built with a multi-stage build, keeping build-only tooling out of the final runtime image. (Lesson 3)
3. The container runs as a non-root user, set explicitly with a USER instruction rather than left at the default root. (Lesson 3)
4. PYTHONUNBUFFERED=1 is set so that logs are flushed promptly to the container's log stream instead of appearing delayed or missing during a crash. (Lesson 3)
5. A .dockerignore file excludes .env files, .git, test directories, and other files that should never be copied into the image. (Lesson 3)
6. A HEALTHCHECK (or the orchestrator-equivalent probe) is defined, with a reasonable start-period grace window so a normal, slightly slow startup is not mistaken for a failed deployment. (Lesson 3, Lesson 4)

Health Checks and Startup

1. Liveness and readiness are implemented as two distinct endpoints, not conflated into one. Liveness proves the process itself is responsive; readiness proves it can actually serve requests. (Lesson 4)
2. Neither the liveness nor the readiness check makes a real call to the OpenAI API. A shared external dependency's transient failure should not remove otherwise-healthy replicas from the traffic pool or trigger unnecessary restarts. (Lesson 4)
3. Readiness reflects genuinely local state — startup completion and configuration presence — that can be checked without network I/O. (Lesson 4)

Secrets

1. No secret value is baked into the Docker image, in the Dockerfile or otherwise. Images are typically stored in a shared registry and should be safe to store even if broadly readable within the organization. (Lesson 3, Lesson 5)
2. Secrets are delivered at deployment time, via the platform's environment-variable injection or a mounted secret file, and the application can accept either mechanism without code changes. (Lesson 5)
3. A secret rotation is treated as a deployment event that triggers a restart or rolling redeploy of affected services, not something a running process is expected to detect and reload on its own. (Lesson 5)
4. The deployment pipeline's own identity has least-privilege access to only the secrets the service it deploys actually needs. (Lesson 5)

Background Processing and Scaling

1. Long-running AI work (large documents, multi-step agent loops, audio processing) happens in a background worker, not inside a request handler bound by a client timeout. (Lesson 6)
2. Worker task execution is wrapped so that one failing job cannot crash the entire worker loop or process, and failures are recorded rather than silently swallowed. (Lesson 6)
3. Jobs that can fail transiently are retried with exponential backoff up to a bounded limit, and jobs that exhaust retries are routed to a visible dead-letter path, not left to disappear. (Lesson 7)
4. Any job handler with non-idempotent side effects (billing, notifications) has an explicit deduplication mechanism so a retry cannot repeat that side effect. (Lesson 7)
5. The application holds no per-request state only in a single process's memory. Sessions, job status, and rate-limit counters live in a shared external store so any replica can serve any request. (Lesson 8)
6. Rate limiting is enforced against a shared counter (Redis or equivalent), not a per-process counter, once more than one replica is running — a per-process limiter silently multiplies your effective request rate by your replica count. (Unit 12 Lesson 3, Lesson 8)
7. Autoscaling triggers on signals meaningful for an I/O-bound workload — concurrency, queue depth, tail latency — rather than CPU utilization alone. (Lesson 8)

Reliability and Monitoring

1. Every log line for a given request carries a correlation id, so a single request's full history can be reconstructed from logs after an incident. (Lesson 9)
2. Errors are classified by cause (rate limiting, upstream provider failure, client-side bug) rather than tracked as a single undifferentiated error count, so dashboards point directly at the appropriate response. (Lesson 9)
3. Token usage and cost are tracked as an operational metric, not discovered only via a billing dashboard after the fact. (Lesson 9)
4. Alert thresholds require sustained abnormal conditions, not any single error or blip, to avoid alert fatigue that causes genuine incidents to be ignored along with noise. (Lesson 9)

A Pre-Deployment Validation Script

Several of the checklist items above — particularly in the Configuration and Secrets sections — can be checked programmatically before a deployment proceeds, rather than relying on a human to remember each one. A small script run as part of a deployment pipeline can catch an obvious oversight before it reaches production:

import os
import sys


REQUIRED_ENV_VARS = ["OPENAI_API_KEY", "APP_ENV", "OPENAI_MODEL"]
FORBIDDEN_IN_PRODUCTION = {
    "development": False,  # not forbidden in dev
}


def check_required_vars() -> list[str]:
    return [name for name in REQUIRED_ENV_VARS if not os.environ.get(name)]


def check_not_using_dev_defaults_in_production() -> list[str]:
    problems = []
    if os.environ.get("APP_ENV") == "production":
        if os.environ.get("OPENAI_API_KEY", "").startswith("sk-dev-"):
            problems.append("production APP_ENV is using a key prefixed sk-dev-")
        if os.environ.get("LOG_LEVEL") == "DEBUG":
            problems.append("production APP_ENV should not run with LOG_LEVEL=DEBUG")
    return problems


def run_pre_deploy_checks() -> None:
    missing = check_required_vars()
    if missing:
        print(f"FAIL: missing required environment variables: {missing}")
        sys.exit(1)

    problems = check_not_using_dev_defaults_in_production()
    if problems:
        for problem in problems:
            print(f"FAIL: {problem}")
        sys.exit(1)

    print("PASS: pre-deployment configuration checks succeeded")


if __name__ == "__main__":
    run_pre_deploy_checks()

This script does not replace the judgment involved in working through the full checklist above — it automates the narrow, mechanically checkable subset of it: are the required variables present, and is a development-looking key or debug-level logging about to be deployed to production. Wiring a script like this into a deployment pipeline as a step that must pass before the deployment proceeds turns a handful of these checklist items from "something a person has to remember" into "something that fails the build automatically if forgotten" — which is a meaningfully more reliable guarantee for the items it can express in code.

Note: The exact set of checks worth automating depends on your specific application and deployment platform. The pattern shown here — a small, fast script that fails the pipeline on a clear configuration problem — generalizes well beyond the two checks shown; extend it with any project-specific invariant you would otherwise be relying on a person to verify by hand before every release.