Docker

1 / Containerization as Standard Practice

Docker is present in nearly every project I build. It eliminates the 'works on my machine' problem by packaging applications, dependencies, and runtime environments into reproducible containers. Across Cairn, Phoenix, Shard, Trajectory, and Vigil, Docker provided the deployment substrate.

2 / Docker Compose Orchestration

Multi-container applications — an app server, PostgreSQL, Redis, Nginx — were orchestrated through Docker Compose. A single `docker-compose up` command brought up the complete development environment with all services networked and configured. This development-production parity prevented environment-specific bugs from reaching deployment.

3 / Programmatic Container Management

In Vigil, Docker became a runtime tool rather than just a deployment tool. The docker-py SDK programmatically launched ephemeral, resource-constrained container sandboxes for Agent Evaluation. Each sandbox had explicit CPU, memory, and PID limits. Network isolation prevented sandboxed agents from accessing external services. Container lifecycle management — creation, execution monitoring, log capture, and cleanup — was fully automated.

4 / Multi-Stage Builds

Multi-stage Dockerfile builds separated build-time dependencies from runtime images, dramatically reducing production container sizes. A Java application that needed Maven and the full JDK during compilation shipped as a slim JRE-based image. A Python application that needed build tools for native extensions shipped with only the compiled artifacts.

5 / Security Consideration

Dropping unnecessary root privileges inside Dockerfiles — defining dedicated non-root execution users — was a lesson from Vigil's sandbox security requirements. Running containers as root grants unnecessary capabilities that a compromised process could exploit. The principle applies beyond sandboxes: production application containers should run as non-root by default.