Plan & Apply
The Plan-Review-Apply workflow for infrastructure provisioning.
Plan & Apply
Infrastructure provisioning follows a strict Plan-Review-Apply workflow. Nothing is provisioned without explicit user confirmation.
The Workflow
Generate Plan
From the spec detail page, click Plan. Select a Runner to execute. A PLAN job is queued.
The Runner:
- Assumes cloud credentials (how)
- Generates Terraform variable files from the spec's config snapshot
- Runs
terraform initwith Supabase S3 backend (state management) - Runs
terraform plan -out=plan.tfplan - Runs
terraform show -jsonfor structured output - Optionally runs Infracost for cost breakdown (cost estimation)
- Uploads the plan artifact to Supabase S3
- Reports resource change counts and costs
Review Plan
The Plan tab in spec detail shows:
Plan Summary Bar:
- Resources to create (green count)
- Resources to update (yellow count)
- Resources to destroy (red count)
- Estimated monthly cost
Resource Groups: Collapsible sections grouped by resource type (e.g., "AWS EKS", "AWS VPC", "AWS RDS"). Each resource shows:
- Resource address (e.g.,
module.eks.aws_eks_cluster.main) - Action: create / update / delete
- Per-resource monthly cost (from Infracost)
Cost Breakdown: Total estimated monthly cost with per-resource itemization.
Apply
Click Apply to provision. Select a Runner. A DEPLOY job is queued.
The Runner:
- Downloads the plan artifact from the PLAN job
- Validates the config hash — if the spec was modified after planning, the apply fails with a hash mismatch error
- Runs
terraform apply plan.tfplan - Extracts Terraform outputs (cluster endpoint, database endpoints, etc.)
- Installs ArgoCD via Helm (GitOps)
- Reports cluster metadata back to Alethia
Finalization
On DEPLOY success, Alethia's finalizeDeployment() server action:
- Updates
spec_clusterwith cluster name, endpoint, ARN, ArgoCD URL and password - Updates
spec_databaseswith writer/reader endpoints, credentials ARNs - Updates
spec_cacheswith primary/reader endpoints - Sets spec status to
ACTIVE
Config Hash Validation
The DEPLOY job references a specific PLAN job. Before applying, the Runner compares:
- The spec's current configuration hash
- The plan's configuration hash (captured at plan time)
If they differ (user modified the spec after planning), the job fails with:
"Configuration has changed since the plan was generated. Please re-plan."
This prevents applying a stale plan that doesn't match the current desired state.
Destroy Workflow
Destroy follows a simpler flow — no plan step required:
- Click Destroy from spec detail
- Select a Runner
- A
DESTROYjob is queued - The Runner runs
terraform destroy -auto-approve - Spec status → DESTROYING → DESTROYED
Destroy permanently removes all cloud resources (VPC, cluster, databases, etc.). Terraform state is preserved so accidental destroys can be recovered by re-applying, but data in databases will be lost.