Infrastructure as Code

Eigenoid manages all cloud infrastructure with Terraform using a producer/consumer model. The producer (platform-actions) provides reusable CI/CD workflows. Each infrastructure repo (consumer) declares what to deploy in a terraflow.yaml file and the pipeline handles the rest.

If you just want to create or change infrastructure, you only need to edit Terraform files and open a PR. The pipeline plans, applies, and promotes automatically.

GCP -- three projects

All GCP infrastructure is spread across three independent projects (ADR-0009):

Environment	Project	Purpose
dev	eigenoid-dev	Development, auto-deploy on merge
qa	eigenoid-qa	Staging, approval gates
prd	eigenoid-prd	Production, org-level services, Artifact Registry

Authentication

GitHub Actions authenticates with GCP via Workload Identity Federation (OIDC, no stored secrets):

Resource	Value
WIF Pool	github
OIDC Provider	eigenoid
Terraform CI SA	terraform-ci@eigenoid-{env}.iam.gserviceaccount.com
Bootstrap SA	platform-bootstrap@eigenoid-{env}.iam.gserviceaccount.com

State buckets

Each stack has three Terraform state buckets (one per environment), created automatically when the repo is created (ADR-0012):

eigenoid-2cea55-{stack}-tfstate-{env}

Infrastructure stacks

Stack	Repo	What it manages
Foundation	iac-foundation	WIF pools/providers, service accounts, GCP API enablement
Platform	iac-platform	safe-settings Cloud Run, Docker Artifact Registry
Distribution	iac-distribution	Python Artifact Registry repos for eigenoid + eigenoid-sample
Access	iac-access	Cloud SQL, Cloud Run, Pub/Sub, Scheduler for access management
Template	iac-template	Pre-configured template for bootstrapping new stacks

The producer that powers all of these is platform-actions -- reusable workflows + centralized environment config.

Change flow

Developer → PR in consumer → Automatic plan (dev)
                                     ↓
                            Review + /terraflow apply → Apply in dev
                                     ↓
                            Merge → workflow_dispatch promote → Apply in qa → prd

1. A PR in a consumer triggers an automatic plan against the default environment (dev).
2. The bot posts the plan output as a comment on the PR.
3. An authorized member comments /terraflow apply to execute the apply.
4. After merge, you can promote to higher environments (qa, prd) via workflow_dispatch.

Pages in this section

• Producer/consumer model -- architecture, contracts, versioning
• Terraflow spec -- schema for the terraflow.yaml file
• Repository layout -- file structure of the producer and consumers

Related runbooks

• IaC Bootstrap -- automatic state bucket creation