Remote State Backend
By default Terraform uses a local backend (terraform.tfstate on disk). This requires zero setup and works fine for solo use. For team workflows or CI/CD, a remote backend gives you shared state, versioning, and locking.
Choosing a Backend
terraform/envs/prod/backend.tf (copied from backend.tf.example) controls the backend:
| |
Terraform supports other backends too (S3, Azure Blob, Terraform Cloud). Any Terraform-compatible backend works — update backend.tf accordingly. Note that S3 requires a separate DynamoDB table for state locking, whereas GCS locks natively.
GCS Setup
GCS is the recommended remote backend: free tier covers Terraform state (5 GB, 5K/50K ops/month), native locking with no extra services, and automatic encryption at rest.
1. Install the Google Cloud SDK
2. Create a GCP project with billing:
| |
3. Enable Cloud Storage and authenticate:
| |
4. Create the bucket:
| |
5. Update backend.tf with your bucket name (Option B above).
Migrating from Local State
If you’ve already run make apply with the local backend:
| |
Terraform will prompt you to copy local state to the remote backend.
CI Authentication (GCS + WIF)
The included Terraform CI workflows authenticate to GCS via keyless Workload Identity Federation — no service account JSON needed. Set these GitHub repository variables:
| Variable | Value |
|---|---|
GCP_WIF_PROVIDER | Full WIF provider resource name (e.g. projects/<n>/locations/global/workloadIdentityPools/github/providers/github) |
GCP_SERVICE_ACCOUNT | Automation SA email (e.g. automation@<project>.iam.gserviceaccount.com) |
See Configuring OIDC in GCP for WIF setup instructions.