Update: New convenience workflow and what we heard from you

Terraform
,
1

:waving_hand: Thank you to everyone who reached out with feedback on the version-agnostic provider design, either here or through direct conversations. We have been reading every response carefully and wanted to share an update on what we heard and what we are doing about it.

What we heard

Two themes came through clearly in your feedback:

1. The flattened resource model is a welcome change.
You told us that you like the idea of first-class resources for domains, backends, and other configuration objects. Being able to organize these into standard Terraform modules instead of working with deeply nested blocks is something teams have wanted for a while. We are glad this direction resonates.

2. The multi-step version workflow feels like too much overhead for some teams.
Some of you raised concerns about the explicit version lifecycle steps. Teams that treat service versions as disposable, where every change produces a new version and rollback is just another new version, told us that the proposed workflow introduces friction that does not match how they operate today. The concern was not about the architecture itself, but about the number of steps involved: cloning a version, updating version pins in Terraform inputs, applying, and then activating.

We also heard that some of you prefer Terraform Actions over the Fastly CLI for lifecycle operations, and that not all teams can run certain steps locally against production environments.

What we are doing about it

Our goal with this redesign is to provide maximum flexibility and control over how you manage your Terraform configuration and Fastly service versions. Different teams have different operational models, and the provider should support that range rather than force a single workflow.

To that end, we have added a third orchestration example alongside the existing pinned-version workflows:

New: orchestration-latest (convenience workflow)

This example uses the fastly_service_version data source to automatically target the latest service version instead of requiring an explicit version pin in your Terraform variables.

data "fastly_service_version" "service_1" {
  service_id = fastly_service.service_1.id
}

module "service_1" {
  source          = "./modules/service_config"
  service_id      = fastly_service.service_1.id
  service_version = data.fastly_service_version.service_1.latest_version
  domain_name     = "www.service1.example.com"
  backends        = [...]
}

After cloning a new draft version, a normal terraform apply picks up that latest version automatically. There is no need to manually update a version variable in terraform.tfvars.

The day-to-day workflow becomes:

1. Clone affected service versions
2. `terraform apply` (auto-targets the new draft)
3. Activate changed services

This eliminates the manual version pin update step entirely.

The full example, including helper scripts for cloning and activation, is available in the repo:
examples/orchestration-latest

Important caveats

This convenience workflow is intentionally provided as an optional alternative, not as the recommended default. It has tradeoffs worth understanding:

  • It is best suited for single-operator, one-change-at-a-time workflows. If only one person is making changes at a time, the workflow is safe. The provider will reject writes to active or locked versions, so you cannot accidentally modify a production version.
  • It is not recommended for CI/CD systems with concurrent changes. Because the version is resolved dynamically rather than pinned in configuration, multiple pending changes (PRs, branches) can lead to confusing plan output or unsafe apply operations.
  • For teams that need auditability, reproducible plans, and CI/CD safety, the pinned-version workflows (orchestration-cli and orchestration-actions) remain the recommended approach.

Three workflows, one architecture

The proposed provider examples now contains three orchestration examples, all built on the same version-agnostic architecture:

Workflow Version source Best for
orchestration-cli Pinned variable CI/CD, multi-engineer teams, auditability
orchestration-actions Pinned variable Teams preferring Terraform Actions over CLI
orchestration-latest Data source (latest version) Single-operator convenience, fewer manual steps

In all three cases, the core design stays the same: Terraform manages configuration, and version lifecycle (cloning and activation) remains explicit. The difference is how much of the version bookkeeping is automated versus manually controlled.

We believe this gives teams the flexibility to choose the workflow that fits their operational model, whether that is a tightly controlled CI/CD pipeline with pinned versions or a faster, more hands-on workflow where versions are treated as disposable.

Still listening :ear:

We are continuing to refine the workflow guidance and explore ways to reduce overhead further, particularly around activation. If you have thoughts on any of the above or want to share how your team manages Fastly service versions today, we would love to hear from you.

1 Like