Convox Rack is a self-hosted platform-as-a-service that runs in an AWS account and manages the full lifecycle of containerized applications. The repository is a Go monolith with three coordinated surfaces: a CLI (cmd/convox), an HTTP/WebSocket API server (cmd/rack + pkg/api), and a generated Go SDK (sdk). All operations funnel through the Provider interface defined in pkg/structs/provider.go, and the main production implementation in provider/aws drives CloudFormation, ECS, ECR, DynamoDB, S3, KMS, SSM, CloudWatch Logs, SNS/SQS, and Lambda. In production, the rack creates per-app CloudFormation stacks, builds Docker images through ECS tasks, persists builds and releases in DynamoDB/S3, and promotes releases by updating stacks. Primary entry points are cmd/convox for the CLI, cmd/rack for the API server, cmd/monitor for background workers, and the Lambda functions under provider/aws/lambda for custom CloudFormation resources, autoscaling, instance lifecycle draining, and syslog forwarding. The CLI also supports local development mode via pkg/start and pkg/sync, which builds manifests in Docker and incrementally syncs files into running containers. The manifest layer has two generations: pkg/manifest1 handles legacy docker-compose-style definitions, while pkg/manifest implements the newer convox.yml format with flexible YAML parsing, NLB validation, timers, and internal/external port handling. The codebase contains substantial test infrastructure, including golden-output CLI tests, SDK contract tests, generated mock providers, and the awsutil request/response replay harness. However, it also has accumulated drift: two parallel manifest implementations, version-gated compatibility branches in the CLI/SDK, an embedded CA trust store from 2017, AWS SDK v1 dependencies, and some provider methods that remain unimplemented. Some tests are skipped or commented out. These factors keep the code from being exemplary, but the overall architecture is coherent, professional, and actively maintained. This is purely an application repository; there is no data-science or research component. The only data involved is operational state such as builds, releases, environment variables, and logs, stored in AWS services. Reusable pieces include generic TTL caching, order-preserving YAML unmarshalling, CloudFormation stack helpers, KMS envelope encryption, and a replay-based AWS test harness.