Alethia Labs
Jobs

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:

  1. Assumes cloud credentials (how)
  2. Generates Terraform variable files from the spec's config snapshot
  3. Runs terraform init with Supabase S3 backend (state management)
  4. Runs terraform plan -out=plan.tfplan
  5. Runs terraform show -json for structured output
  6. Optionally runs Infracost for cost breakdown (cost estimation)
  7. Uploads the plan artifact to Supabase S3
  8. 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:

  1. Downloads the plan artifact from the PLAN job
  2. Validates the config hash — if the spec was modified after planning, the apply fails with a hash mismatch error
  3. Runs terraform apply plan.tfplan
  4. Extracts Terraform outputs (cluster endpoint, database endpoints, etc.)
  5. Installs ArgoCD via Helm (GitOps)
  6. Reports cluster metadata back to Alethia

Finalization

On DEPLOY success, Alethia's finalizeDeployment() server action:

  • Updates spec_cluster with cluster name, endpoint, ARN, ArgoCD URL and password
  • Updates spec_databases with writer/reader endpoints, credentials ARNs
  • Updates spec_caches with 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:

  1. Click Destroy from spec detail
  2. Select a Runner
  3. A DESTROY job is queued
  4. The Runner runs terraform destroy -auto-approve
  5. 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.

On this page