Back to the project in the portfolio
Architecture diagram

Modular Terraform rebuild — modules v2

Moving from a monolithic Terraform estate to a modular, multi-cloud Infrastructure as Code platform: shared building blocks pooled in one place, an isolated control plane, a management layer, and one implementation per provider (AWS, GCP, Scaleway) behind a single contract. The migration relies on moved blocks to relocate resources without destroying them.

Generic diagram: instances, repositories, channels and modules are named by function. The architecture is shown for illustration, independently of any organisation.

Module or step AWS GCP · external service Scaleway Target state Teardown Repository boundary
01 — from the v1 monolith to v2 modules

Target repository architecture

What the rebuild moves: logic duplicated from one cloud to the next travels up into common/, and each provider keeps only its own implementation. The transition happens through moved blocks, with no resource destroyed.

Before — v1 estate terraform-modules/ Monolithic modules State shared across environments Logic duplicated from one cloud to the next Implicit interfaces, few typed contracts Adding a cloud = copying the whole estate 104 moved blocks state migration without destruction terraform modules v2 control/ — shared control plane Stage foundation Control VM Control network auth and JWT keys, secrets vault, load balancer, metrics Lambda, observability instance and image dedicated VPC Managed database, PKI, DNS and CDN hang off this layer. management/ — orchestration Environment manager Stack generator Deployment tooling queries the control API: environment list and status generates the Terraform stacks, separates legacy from split-state deployment VM and scripts, release, job resumption common/ — blocks shared across clouds environment network cluster configuration control API calls status transitions environment generation metrics cluster deployment workflows log collection tags string helpers instance type fallback cloud-init images One implementation per responsibility, consumed by all three providers. cloud-init images database observability orchestrator metrics vector database Known overlap with the common layer: the two variants have already diverged. providers/ — one contract, three clouds aws database environment cluster foundation teardown kubernetes observability object store network vector database metrics log collection virtual machines in amber: AWS-only modules gcp database environment cluster foundation teardown kubernetes observability object store network vector database scaleway database environment cluster foundation teardown kubernetes observability object store network vector database
All three providers expose the same set of modules; what differs fits into the three amber lines on the AWS card. Estate volumes measured in July 2026.
325.tf files
24,729lines of Terraform
64module directories
453resources
154data sources
1,021variables
228outputs
104moved blocks
52module READMEs
02 — from the control API to teardown

Lifecycle of an environment

The control API is the source of truth: it describes the environments to create, and every status transition is reported back to it. The cloud foundation is always laid before the application layer, and teardown takes a dedicated path.

status transitions Control API source of truth for environments auth Environment manager fetches list and statuses Stack generator produces the Terraform stacks Legacy environments shared state — transitional mode Split-state environments one state per environment — target environment cloud foundation Network / VPC Kubernetes cluster (EKS / GKE / Kapsule) Object stores (S3 / GCS / Object Storage) Observability Vector database (optional) Created before any application layer. application layer Orchestrator PostgreSQL Deployment workflows Prometheus / Grafana Log collection Deployed onto the cloud foundation built at the previous step. Status report back to the control API Teardown purge then cluster terraform layer split Three independent layers, applied in this order. Stage tooling stage tooling and control plane Environment list an apply that exposes the env list Generated stack per environment one per active environment
The green path is the only feedback route back to the control API; the red path is the only one that destroys.
03 — one contract, three implementations

Multi-cloud parity matrix

What each provider substitutes behind the common contract — and the three building blocks that stay cross-cutting whatever the cloud.

FunctionAWSGCPScaleway
KubernetesEKSGKEKapsule
ComputeEC2Compute EngineInstances
DatabaseRDSCloud SQLRDB
Object storageS3GCSObject Storage
NetworkVPCVPC / NATPrivate Network
Cross-cutting DNSRoute53 for all three providers
Application secretsBitwarden for all three providers
ObservabilityOpenObserve and Prometheus for all three providers
The three columns expose the same contract: that is what makes it possible to add a provider without touching the layers above.

All architecture diagrams