Terraform provider

The Elido Terraform provider - terraform-provider-elido - lets you manage short links the same way you manage the rest of your infra: declaratively, in version control, with plan / apply semantics and drift detection.

The provider is a thin adapter over the public REST API. Anything you can express in elido_link you can also express via the SDK or a curl to api-core; Terraform just gives you a stable lifecycle contract on top.

When to use it

• Marketing redirects belong with your infra. Cloudflare DNS, S3 lander, CloudFront distribution, and the short link that points at the lander all live in the same Terraform module. Delete the lander → the redirect goes with it.
• Bulk campaign links from a template. A for_each over channels × regions produces dozens of consistently-tagged links in one terraform apply.
• Multi-tenant onboarding. If you provision tenants with Terraform, add an elido_link resource to the module and every tenant gets their branded redirects on day one.

If your only need is “create one link from a script”, reach for the Go SDK or a curl. Terraform is for the case where you want a lifecycle managed.

Status

v0.1.0 MVP, built from source (see Installation). Surface today:

elido_custom_domain registers the domain and, by default, waits until DNS verification passes (wait_for_verified, verify_timeout, default 10m). On timeout it returns the verify_token so you can publish the missing TXT record. Import with <workspace_id>:<domain_id>.

Planned. elido_folder and elido_api_key resources are not in the provider yet. The provider is not published on the Terraform Registry and has no stable release. ADR-0034 has the full deferred-work list.

Installation

The provider is not yet published on the Terraform Registry. Until it is, install via dev_overrides:

git clone https://github.com/elidoapp/elido.git
cd elido/tools/terraform-provider-elido
make install-local

Then add a dev_overrides block to ~/.terraformrc:

provider_installation {
  dev_overrides {
    "elidoapp/elido" = "/Users/<you>/.terraform.d/plugins/elidoapp/elido"
  }
  direct {}
}

Under dev_overrides, terraform init is not required - plan and apply resolve the binary directly.

Configure

terraform {
  required_providers {
    elido = {
      source  = "elidoapp/elido"
      version = "~> 0.1"
    }
  }
}
 
provider "elido" {
  # api_url   defaults to https://api.elido.app
  # api_token reads ELIDO_API_TOKEN
}

export ELIDO_API_TOKEN=ek_...

For self-hosted Elido point api_url at your api-core. Tokens are created at /dashboard/settings/api-keys.

Your first link

data "elido_workspace" "main" {
  id = 42
}
 
resource "elido_link" "spring_campaign" {
  workspace_id    = data.elido_workspace.main.id
  domain_id       = 1
  slug            = "spring-2026"
  destination_url = "https://example.com/landing/spring"
  title           = "Spring 2026 email campaign"
  tags            = ["spring-2026", "email"]
  redirect_status = 301
}

terraform plan
terraform apply

The provider keys state by the numeric link id, so renaming the Terraform resource label or changing the slug does not force replacement - it issues a PATCH. Changing workspace_id or domain_id does force replacement (the link belongs to a different edge route).

Bulk links

locals {
  channels = ["email", "twitter", "linkedin", "reddit", "hn"]
  regions  = ["us", "eu", "apac", "latam"]
}
 
resource "elido_link" "campaign_launch" {
  for_each = {
    for pair in setproduct(local.channels, local.regions) :
    "${pair[0]}-${pair[1]}" => pair
  }
  workspace_id    = data.elido_workspace.main.id
  domain_id       = 1
  slug            = "launch-${each.key}"
  destination_url = "https://example.com/launch?ch=${each.value[0]}&r=${each.value[1]}"
  tags            = ["launch-2026", each.value[0], each.value[1]]
}

20 links, one apply. Delete the block and terraform apply removes them in one transaction.

Importing existing links

Already have links you want under Terraform management? Use the <workspace_id>:<link_id> format:

terraform import elido_link.spring_campaign 42:7

A subsequent terraform plan shows the drift between the live link and your HCL - converge by either updating HCL to match or letting apply push your HCL state to the API.

Reference

Resource - elido_link

Data source - elido_custom_domain

Look up a custom redirect domain by hostname inside a workspace. Use the resulting id as domain_id in elido_link resources.

data "elido_custom_domain" "links" {
  workspace_id = data.elido_workspace.main.id
  hostname     = "links.example.com"
}
 
resource "elido_link" "spring_campaign" {
  workspace_id    = data.elido_workspace.main.id
  domain_id       = data.elido_custom_domain.links.id
  destination_url = "https://example.com/landing/spring"
  slug            = "spring-2026"
}

Data source - elido_workspace

Where to file issues

Bugs, schema gaps, or “I want resource X” - open an issue at github.com/elidoapp/elido  with the area:terraform label.