Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.equinix.dev/llms.txt

Use this file to discover all available pages before exploring further.

equinix.dev’s compile step emits a fresh main.tf and variables.tf per project. State — the JSON blob Terraform writes to track what it created — is not something equinix.dev manages. You pick the backend.

​
Local state for plan-only

If you’re staying in plan-only mode (no apply), local state is fine. The equinix-dev compile step writes .equinix-dev/terraform/main.tf; you can terraform init and terraform plan against it without remote state at all. 
cd .equinix-dev/terraform
terraform init       # uses local state by default
terraform plan
This is the default for the demo and for any plan-only audit workflow.

​
Remote state for shared workflows

For real deployments, pin to one of the standard remote backends. Three patterns we recommend:
Most common when you already run terraform on AWS and have an S3 + DDB pattern in place.
terraform {
  backend "s3" {
    bucket         = "company-tfstate"
    key            = "equinix-dev/private-ai-iad/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "company-tfstate-locks"
    encrypt        = true
  }
}
equinix-dev compile --backend s3 injects this block at the top of main.tf.
Best when you want the policy-as-code (Sentinel, OPA), drift detection, and policy enforcement HCP gives you.
terraform {
  cloud {
    organization = "your-org"
    workspaces { name = "equinix-private-ai-iad" }
  }
}
Useful pairing: HCP Sentinel policies enforce the same readiness gates that equinix-dev preflight enforces, server-side.
Best when you want a stack-of-stacks model with strong context isolation. Spacelift’s “Terragrunt-style” stack composition pairs naturally with equinix.dev’s per-package generation.
All standard Terraform backends work. Pick whichever matches your hyperscaler footprint.

​
Per-environment state

We recommend one Terraform workspace per (environment, metro) pair. Example workspace naming for the canonical Multi-cloud private interconnect recipe: 
equinix-multicloud-prod-iad
equinix-multicloud-prod-dfw
equinix-multicloud-staging-iad
equinix-multicloud-dev-iad
This keeps blast radius small — a stuck apply on staging doesn’t lock prod state.

​
Equinix-specific gotchas

Fabric Cloud Routers and Connections get fresh UUIDs each time they’re created. If you terraform destroy and re-create, downstream references (route filters, observability subscriptions) need the new UUIDs. Use Terraform outputs to expose UUIDs and pin them with lifecycle.replace_triggered_by only when the recreate is intentional.
Several Fabric resources pull account.account_number server-side after creation, which can show as a diff in subsequent plans. Add lifecycle { ignore_changes = [account, change_log] } to suppress it. The pattern is in every recipe we ship.
The notifications.emails field gets normalized server-side (lowercased, deduplicated, alphabetized). Match this in your HCL or set lifecycle { ignore_changes = [notifications] }.
A service profile UUID looked up via data.equinix_fabric_service_profiles is only valid in your account’s view. Sharing state across accounts requires recomputing the lookup.

​
Drift detection

Use whatever drift tool your stack already uses. Three patterns work well:
  • Atlantis for plan-on-PR. Cheapest to set up.
  • HCP Terraform for native drift + policy enforcement.
  • Spacelift drift detection for cron-style sweeps with custom remediation runs.
Equinix Fabric APIs are stable enough that drift is rare. Most “drift” reports we see are the gotchas above (account references, normalized emails) — not real config drift.

​
Next

Importing existing services

terraform import patterns when adopting equinix.dev for an existing Equinix account.

MCP server

Plug an agent into the Equinix MCP to author Terraform changes.