CNP — Internal Developer Platform
A repository-first platform that onboards an application into a standardised cloud-native workflow without it writing a pipeline.
The problem
Onboarding an application into a cloud-native workflow takes days, and how long depends mostly on who on the platform team agrees to help. Every team reinvents its own pipeline, with its own approximations about security and conventions.
CNP turns that path into a product: the standard route becomes the easiest route.
How it works
The approach is repository-first. A GitHub App instruments the application team's repository: it installs the GitHub Actions pipeline, which builds the image, publishes it to GHCR and triggers deployment to Azure AKS.
Behind it, a FastAPI service holds the state of applications and their environments on PostgreSQL via SQLAlchemy, with migrations managed by Alembic. The full development environment runs on Docker Compose.
Python 3.12 · FastAPI · PostgreSQL · SQLAlchemy · Alembic · GitHub App · GitHub Actions · Docker Compose · Kubernetes · Azure AKS · GHCR
What I did
- Built the platform API and its data model (applications, environments, deployments).
- GitHub App integration: installation, permissions, writing the pipeline into the target repository.
- The build → GHCR → AKS deployment chain.
- Alembic migrations and a reproducible development environment.
Outcome
An application team goes from empty repository to first deployment without writing a line of pipeline. [TODO: metric] time-to-first-deploy measured before and after.
What I took from it
An internal platform is not a tool, it is a product whose users are free to bypass it. If the standard path is not the fastest one, nobody takes it — and you end up with governance on paper and chaos in the repositories.