Skip to content

Terraform Operational Model

Status: Candidate Validation: Pending operational use Scope: blueflyio/iac and all Terraform provisioning pipelines.

This document defines the strict separation of duties between developer workstations and GitLab CI regarding infrastructure provisioning.

1. The Core Principle

Your laptop is a Workstation, not an authority. GitLab CI is the Operational Authority.

  • Local terraform plan is an engineering tool for fast iteration.
  • GitLab CI terraform plan is the authoritative review.
  • GitLab CI terraform apply is the ONLY authorized production mutation path.

2. Model A — Workstation (Developer / Architect)

Purpose: Discovery, development, local validation, and debugging. Auth Posture: 1Password op run injection (API Key). State: Local execution may use local state unless a remote backend is explicitly configured for that execution. Local state is not the production source of truth.

Allowed Actions: - terraform fmt - terraform validate - terraform plan (Local drift detection) - Local DDEV / Docker testing

Forbidden Actions: - terraform apply (against staging or production) - terraform destroy - Manual production drift fixes - Committing local terraform.tfstate files

3. Model B — GitLab CI (Operational Authority)

Purpose: Merge validation, authoritative plans, and environment applies. Auth Posture: GitLab CI Variables / OCI Instance Principals / OIDC. State: GitLab Managed Terraform HTTP State.

Pipeline Flow: - feature/*: Triggers authoritative terraform:plan:dev. Applies are structurally blocked. - main: Triggers plan:staging and manual gates for apply:staging. - release/*: Triggers plan:prod and manual gates for apply:prod.

4. Emergency Procedure

In the event of a total CI/CD failure where production is down and GitLab is unreachable, "Break Glass" applies from a developer workstation are permitted only if: 1. The operator uses op run to securely inject the production provider credentials. 2. The operator explicitly downloads the latest state file from the GitLab state backend to prevent state corruption. 3. The incident is logged in the Decision Ledger (ContractPlane) immediately following recovery.