Configuration-Driven Developer Platform
The problem it solves is unglamorous and expensive: a product made of several services, four datastores, a queue and a reverse proxy takes a new developer most of a day to stand up, and the environments drift apart afterwards. This platform declares the entire stack in a single configuration file and materialises it from container definitions, with a service catalogue holding the application repositories. Infrastructure provisioning is defined as code alongside it, so local and hosted environments come from the same description.
Platform repository with container definitions, a service catalogue, Terraform modules and Make-based entrypoints
Documented as an architecture record. Internal tooling proves itself by what it removes, which is best explained rather than demonstrated.
From one config file to a running stack
Follow what happens on a first run, and note that application code enters from the side rather than being baked in.
The single declarative description of the environment: services, ports, dependencies.
The onboarding path this exists to shorten.
Highlights
Declare once, materialise anywhere
The platform reads a declarative configuration and composes container definitions into a running environment. Application code is not part of the platform — it is catalogued and mounted, which keeps the two from entangling.
Configuration
The single declarative description of which services run and how they connect.
- An example configuration ships alongside the real one for onboarding.
- Changing the stack is a diff, not a wiki page.
Container definitions
Compose definitions and images for every platform service.
- Datastores, queue, proxy, supervisor and scheduler all defined here.
- Data volumes are managed so state survives a rebuild.
Service catalogue
Holds the application repositories the platform runs.
- Applications are mounted in rather than vendored.
- Platform and products can be versioned independently.
Provisioning
Infrastructure as code for hosted environments.
- Terraform modules with a locked provider set.
- Same description drives local and hosted setups.
Every managed service
This is the base stack one configuration file brings up. Application repositories are mounted in from the catalogue rather than vendored into the platform. 16 units across 4 groups.
Datastores
4Platform services
6Provisioning
5Service catalogue
1Stack by layer
Delivered work
Platform
- Declarative configuration driving the entire service set.
- Container definitions for datastores, queue, proxy, supervisor and scheduler.
- Managed data volumes so local state survives rebuilds.
- Make-based entrypoints wrapping the common operations.
Environments
- Service catalogue holding application repositories separately from the platform.
- Terraform modules with a locked provider set.
- Local cloud service emulation for credential-free integration work.
- Requirement verification step for tooling and port availability.
Modules and demo strategy
Single configuration surface
Turns environment setup into a diff.
- One file describes the stack; changes are reviewable.
- Removes the drift between developers' machines.
Service catalogue
Keeps platform and products decoupled.
- Applications are mounted, not vendored.
- Either side can move without dragging the other.
Infrastructure as code
Makes hosted environments reproducible.
- Locked provider versions prevent silent drift.