Skip to main content

Terraform

Manage Envshed organizations, projects, environments, members, service tokens, and secrets the same way you manage the rest of your infra — declared in HCL, applied by terraform apply, reviewed in pull requests.

On the roadmap — target Q4 2026

The Terraform provider (envshed/envshed) ships in Q4 2026 on the public registry. Until then, the REST API workaround is enough to bootstrap projects and rotate service tokens from a Terraform pipeline.

How it will work​

  • envshed_project, envshed_environment, envshed_secret, envshed_service_token — first-class resources that map 1:1 to the dashboard.
  • State is the source of truth — drift between Envshed and your .tf files surfaces in terraform plan. No more "did someone rotate that secret in the UI?" surprises.
  • Plan-safe secret values — envshed_secret.value is treated as sensitive: never printed in plan output, stored encrypted in remote state.
  • Read-only data sources — data.envshed_secret and data.envshed_project so you can pull values into other providers (Vercel, AWS) without writing them back.

Workaround today​

Two patterns work today, depending on whether you want full lifecycle control or just one-shot bootstrap.

Option 1 — Terraform http provider for one-shot bootstrap​

Use the http data source with the Envshed REST API to read secrets at plan time and feed them into other providers (for example, Vercel or AWS Secrets Manager).

data "http" "database_url" {
  url = "https://app.envshed.com/api/v1/secrets/my-org/my-project/production/DATABASE_URL"

  request_headers = {
    Authorization = "Bearer ${var.envshed_token}"
  }
}

resource "vercel_project_environment_variable" "db_url" {
  project_id = vercel_project.app.id
  key        = "DATABASE_URL"
  value      = jsondecode(data.http.database_url.response_body).value
  target     = ["production"]
  sensitive  = true
}

This pattern is read-only — Envshed remains the source of truth for the secret value, Terraform just propagates it into the provider that needs it.

Option 2 — null_resource + local-exec for write paths​

For provisioning service tokens or rotating secrets from a Terraform run, wrap the CLI in a null_resource:

resource "null_resource" "rotate_db_url" {
  triggers = { value_sha = sha256(var.new_db_url) }

  provisioner "local-exec" {
    command     = "echo -n \"$NEW_VALUE\" | envshed secret set DATABASE_URL -e production"
    environment = {
      ENVSHED_TOKEN = var.envshed_token
      NEW_VALUE     = var.new_db_url
    }
  }
}

envshed secret set reads the value from stdin to keep it out of shell history and terraform plan output. This pattern is fine for bootstrap and rotation but does not give you drift detection — that gap is what the native provider closes.

Want this sooner?​

The Terraform provider sits in the Q4 2026 batch on the public roadmap. If managing Envshed as code would unblock your team, email hello@envshed.com with a line about which resources you would manage first — that drives which resources we ship in v0.