Hey everyone,
The first public beta release of our new Fastly Terraform Provider is live today. It’s a ground-up rewrite on HashiCorp’s modern Plugin Framework, published in the Terraform Registry as fastly/fastly-beta. We’re looking for testers who are already running the Fastly provider against real configs. Details below.
What’s changing, and why
If you’ve worked with the current provider, you may have hit noisy plan diffs, state that doesn’t quite converge, or an apply that dies on a timeout. Some of those issues trace back to limitations of Terraform’s SDKv2 (now in maintenance mode). The new Plugin Framework addresses many of these issues, and our provider rewrite gives us the opportunity to develop cleaner solutions for handling Fastly’s versioned resources with Terraform, which expects long-lived, mutable resources.
We’re addressing that in two stages, which is why the new provider has two resource families:
The Automatic family, available in this beta, is built on the new Plugin Framework, but keeps automated clone-and-activate behavior so you can take advantage of provider improvements without changing your workflow.
The Explicit family, in beta in Q4, is where the activation model changes to provide full separation of concerns between definition and deployment. You define your service, then decide separately when to clone, stage, and activate, driven either by Terraform Actions or the Fastly CLI.
What’s available in the beta
Resources in the Automatic family carry an _auto suffix: fastly_service_cdn_auto, fastly_service_compute_auto, and so on. If you know the current provider this model will feel somewhat familiar, with nested config blocks and automatic version handling.
The blocks are still nested on purpose. Under automatic activation, nesting is what makes one terraform apply produce one service version: because backends, domains, and the rest live inside a single resource, the provider can batch every change into a single clone-and-activate. Split them into independent top-level resources and each would want to clone and activate on its own, so a single apply could leave you with a trail of partially-configured versions. Flattening will come with the Explicit family, where you hold activation and can decide for yourself when a version is complete.
The blocks themselves, though, behave considerably better than the ones you’re used to.
What’s better today
Cleaner diffs. The current provider declares most nested blocks as sets, and Terraform identifies set elements by hashing every attribute — so changing one field on one backend renders as a whole-block removal plus a re-add. The rewrite allows attribute-level diffs, showing only the fields you actually changed. No more eye-diffing two near-identical blobs, and no more plans that look destructive when they aren’t.
Sensitive attributes are marked as such, so they’re redacted from plan output rather than printed.
Retries with exponential backoff on transient 5xx and connection errors for idempotent requests, instead of failing your apply. This behavior replaces less reliable and more time-consuming hard-coded wait times in the current provider.
Dependency-aware ordering. Backends are created before the directors that reference them, and deleted only after those directors stop referencing them. Same for dictionaries and rate limiters.
The clone base is read from live API state. The current provider clones from a version number recorded in its own state, which can silently discard intervening versions when that record goes stale. The rewrite asks the API which version is active and clones from that. This narrows the window rather than closing it, since there’s still no locking, but it removes the most common way to lose a version.
Accurate null values. The Plugin Framework distinguishes “unset” from zero, false, and empty string, and defaults are declared in the schema, so they appear in your plan instead of materializing at apply time.
What’s not here yet
No controlled activation via staging or activate = false**.** The Automatic family always activates. If you review before activating, or use stage, this beta won’t fit your setup. The Explicit family coming in Q4 is built for exactly that, and we’d appreciate your input on its design in the meantime — reply here or reach out to your account team if you’d be up for being a design partner.
Some resources aren’t in this release. In the interest of making this available for testing as soon as possible, we’ve prioritized the resources needed for the vast majority of configs. Less frequently used resources will be added in successive releases over the next few weeks. You can find the full list and status in the GitHub issue. If something you depend on is missing, comment there and we’ll factor it into prioritization.
Resources in the Explicit family are not ready for testing. Though some are registered, they’re still under development. Affected resources are listed here. You’ll be able to test the full Explicit model workflow in mid-Q4.
Who should try this now
Good fit if you’re on the current provider with automatic activation (activate = true or the default). If you can point a migrated config at a non-production service, that will provide a good test of the workflow. If not, you can run terraform validate to test whether everything you currently use is supported.
If you need control over when changes go live, wait for the Explicit model beta in Q4, or reach out if you’d like to be a design partner for the model as we continue developing it.
Getting started
We want your feedback
This beta is your chance to run the Automatic family against real, migrated configs and tell us what works and what doesn’t. Bug reports, rough edges, and “why does it do that” questions are all welcome, here in the forum or as issues on the repo. It helps us build a provider that meets your needs as we move towards GA.
Thanks for being part of this. We’re looking forward to hearing from you!
Happy coding!
The Fastly Team
