Docker Production Checklist for AI Agents
A development Compose stack and a production Compose stack look similar on the surface, but they differ in dozens of important details. Development tolerates loose security, no monitoring, no backups, and no resource limits. Production demands all of these. Skipping any item on this checklist creates a gap that will eventually cause an outage, a data loss event, or a security incident. Work through each step systematically before your first production deployment and revisit the checklist before every major update.
Harden Container Security
Run every container as a non-root user. Create a dedicated user in your Dockerfile with a specific UID and GID, then set the USER instruction before the ENTRYPOINT. Running as root inside containers gives attackers elevated privileges if they exploit a vulnerability in your agent code or its dependencies. Most AI agents have no need for root access, making this a straightforward hardening step.
Drop all Linux capabilities that your containers do not need. Docker containers start with a default set of capabilities that includes several dangerous ones like NET_RAW (allowing packet crafting) and SYS_CHROOT. Use the cap_drop: ALL directive in your Compose service and then selectively add back only the capabilities each service actually needs with cap_add. Most AI agent services need no additional capabilities beyond the dropped defaults.
Set read-only root filesystems where possible using the read_only: true directive. This prevents attackers from writing malicious files, installing backdoors, or modifying application code inside the container. Mount writable tmpfs volumes for directories that need write access (like /tmp and /var/run) and use named volumes for persistent data directories.
Scan your container images for known vulnerabilities before deploying to production. Tools like Trivy, Grype, and Docker Scout analyze your image layers and report vulnerabilities in OS packages and application dependencies. Fix critical and high-severity vulnerabilities before deployment. Run scans automatically in your CI/CD pipeline so new vulnerabilities are caught before they reach production.
Limit network exposure by removing all unnecessary port mappings. Only the entry point to your agent stack (typically the API gateway or agent HTTP endpoint) needs a host port mapping. Internal services like databases, model servers, and message queues should communicate only through Docker internal networks with no host port exposure.
Configure Reliability and Recovery
Set restart: unless-stopped on every production service. This policy restarts containers automatically after crashes, Docker daemon restarts, and host reboots, but respects intentional docker compose stop commands. Without a restart policy, a single container crash leaves that service down until someone manually restarts it.
Configure health checks for every service with appropriate intervals, timeouts, and start periods. Database health checks should use native readiness commands (pg_isready for PostgreSQL, redis-cli ping for Redis). Model server health checks should verify the API is responding. Agent health checks should confirm the agent process is running and connected to its dependencies.
Use depends_on with condition: service_healthy for all service dependencies. This ensures Docker starts services in the correct order and waits for each dependency to be genuinely ready before starting services that depend on it. Without health-based dependency conditions, your agent may start before its database or model server is ready, causing startup failures.
Set stop_grace_period to give your services time to shut down cleanly when stopping or updating. The default is 10 seconds, which may not be enough for services that need to finish in-progress inference calls, flush write buffers, or close database connections. AI agents processing long inference calls may need 30 to 60 seconds to complete gracefully.
Implement Monitoring and Logging
Configure Docker logging drivers to send container logs to a centralized logging system rather than storing them only on the host. The json-file driver (Docker default) stores logs locally and can fill up disk space on long-running production systems. Use the local driver with size and rotation limits, or forward logs to an external system like Loki, Elasticsearch, or CloudWatch using the appropriate logging driver.
Set log level to info or warning for production services. Debug logging in production generates enormous volumes of log data that increase storage costs and make it harder to find important messages. Keep debug logging available but disabled by default, and enable it temporarily through environment variables when investigating specific issues.
Monitor container resource usage with docker stats or a metrics collection agent like cAdvisor or the Docker metrics endpoint. Track CPU usage, memory usage versus limits, network I/O, and disk I/O for each container. Set up alerts for containers approaching their resource limits so you can investigate before the OOM killer or CPU throttling affects service quality.
Monitor AI-specific metrics including model inference latency, tokens per second, request queue depth, and error rates. These application-level metrics reveal performance problems that container-level metrics cannot detect. A model server may be within its CPU and memory limits but still serving requests slowly because of model quantization issues or inefficient batching.
Establish Backup and Recovery Procedures
Schedule automated backups for every persistent data store in your agent stack. Use pg_dump for PostgreSQL (run via docker exec on a schedule), the snapshot API for vector databases, and filesystem copies for file-based data. Store backups outside the Docker volume system on external storage that is not affected by Docker operations.
Test your restore procedure by actually restoring a backup to a test environment at least once before going to production, and periodically afterward. Verify that restored data is complete and consistent. A backup strategy that has never been tested provides false confidence and may fail when you need it most.
Define your recovery point objective (RPO) and recovery time objective (RTO) for each data store. RPO is how much data you can afford to lose (measured in time since the last backup). RTO is how quickly you need to restore service. A 24-hour backup schedule means you could lose up to 24 hours of data. If that is unacceptable, increase your backup frequency or use continuous replication.
Document the complete disaster recovery procedure: where backups are stored, how to restore each service, the order of restoration, and how to verify the restored system is working correctly. Store this documentation outside your Docker environment (in a wiki, shared drive, or printed runbook) so it is accessible even when your production system is completely down.
Optimize Performance for Production Load
Set appropriate resource limits based on observed usage during load testing, not development estimates. Run your agent stack under simulated production load and monitor CPU, memory, and GPU utilization for each service. Set limits to 120 to 150 percent of observed peaks to handle traffic spikes without throttling.
Optimize your model server configuration for production throughput. For Ollama, set OLLAMA_NUM_PARALLEL to allow concurrent inference requests. For vLLM, configure tensor parallelism, batch sizes, and max concurrent requests based on your GPU capacity and latency requirements. A model server optimized for throughput can handle 3 to 10 times more requests per second than a default configuration.
Tune database connection pooling to match your expected concurrency. PostgreSQL creates a new process for each connection, and too many connections waste memory and degrade performance. Use a connection pooler like PgBouncer as a separate Compose service to multiplex many application connections onto fewer database connections.
Review your Docker storage driver and volume configuration. The overlay2 storage driver is the default and best choice for most Linux systems. For high-I/O workloads like vector databases, consider using bind mounts to NVMe storage instead of named volumes to reduce the storage driver overhead. Benchmark your specific workload to determine whether this optimization provides meaningful improvement.
Work through security hardening, reliability configuration, monitoring setup, backup procedures, and performance optimization systematically before deploying to production. Revisit this checklist before every major update to catch regressions and newly relevant items.