Update: Two resource families, one provider, your call

Terraform
1

I’d like to share a significant update on the Terraform provider redesign. Based on everything we heard from you, we have committed to a direction and development is now happening publicly. You can follow along in the repo.

Your feedback shaped the final design

In our last update we shared the convenience workflow (orchestration-latest) as a response to concerns about multi-step overhead. But the feedback went deeper than workflow ergonomics. The core message was clear: for many teams, automatic versioning behavior should still be available as a first-class option, not just a workaround bolted onto an explicit-only architecture.

The design we landed on gives both workflows equal footing: two distinct resource families that encode different lifecycle models directly in the resource name.

The committed direction: two resource families

Explicit family (default, clean names)

These are the first-class flattened resources. You manage version lifecycle yourself: clone, apply configuration, activate.

resource "fastly_service_cdn" "app" {
  name = "example-app"
}

resource "fastly_service_domain" "www" {
  service_id = fastly_service_cdn.app.id
  version    = var.service_version
  name       = "www.example.com"
}

resource "fastly_service_backend" "origin" {
  service_id = fastly_service_cdn.app.id
  version    = var.service_version
  name       = "origin"
  address    = "origin.example.com"
  port       = 443
}

Best for: CI/CD pipelines, multi-service coordination, staging environments, teams that want full control and reproducible plans.

Automatic compatibility family (_auto suffix)

Nested blocks, provider handles cloning and activation internally. Feels close to the current provider.

resource "fastly_service_cdn_auto" "app" {
  name = "example-app"

  domain {
    name = "www.example.com"
  }

  backend {
    name    = "origin"
    address = "origin.example.com"
    port    = 443
  }
}

Best for: teams that want fire-and-forget behavior, single-operator workflows, teams migrating from the current provider who prefer minimal workflow changes.

Both families, one architecture

Both families are built on the same underlying provider framework. The difference is where version lifecycle decisions live: in your configuration and workflow (explicit), or inside the provider (auto). You choose per-service, and you do not need to adopt one model for your entire organization.

What this means for your team

  • If the current provider works fine for you: use fastly_service_cdn_auto or fastly_service_compute_auto. Nested config, automatic versioning, minimal migration effort. The architecture underneath is better, but your day-to-day workflow stays familiar.
  • If you want modularity, CI/CD safety, or staging support: use the explicit family (fastly_service_cdn, fastly_service_domain, fastly_service_backend). Full version control, clean separation of concerns, composable modules.
  • If you have a mix of services with different needs: a single service should be managed through one family only, but different services in the same configuration can use different families.

Development is happening publicly

We are building this in the open. The implementation branch is live and contains working code:

You can read the code, review the examples, and follow along as development continues.

Timeline

We are prioritizing the _auto family first, targeting Q3 2026, followed by the explicit family. This means teams using the current provider style will have a migration path available sooner. More details on the beta program and migration tooling will follow in a future update.

Keep the feedback coming

If you have questions about how the dual-model approach would work for your setup, want to review the design doc, or have other feedback, we want to hear it.

3 Likes