$ show convox/rack
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.
The LLM identified 5 files worth highlighting for reuse:
Self-contained TTL cache with namespaced Clear operations. It uses standard Go concurrency primitives and can be dropped into any Go service needing short-lived memoization of external API responses. Demonstrates clean concurrency-safe cache design with expiration and prefix invalidation.
Implements order-preserving YAML parsing and custom UnmarshalYAML methods that accept multiple equivalent shapes (string vs list, string vs map) for fields like commands, ports, and build definitions. This flexible parsing pattern is reusable for any configuration format that must tolerate user input variations while preserving declaration order and duplicate keys.
Package of CloudFormation stack lifecycle helpers that wrap AWS SDK calls with retries, waiters, and output parsing. The functions are parameterized around stack names, templates, and parameters, making this a reusable pattern for managing CloudFormation stacks from any Go tool with minimal Convox-specific coupling.
Envelope encryption combining NaCl secretbox for local symmetric encryption with AWS KMS for key management. The separation between a pure crypto operation and a KMS-backed key provider is a useful pattern for applications that need encrypted secrets without managing raw key material directly.
HTTP test harness that records and replays exact AWS request/response cycles. It allows provider tests to verify precise AWS API calls without real credentials and is self-contained enough to be reused by any Go project testing AWS SDK v1 interactions.