Today, we are excited to introduce a new model for domain management: domains are now independent resources, no longer tied to service configuration. We are breaking away from having domains as part of our service configurations to reduce deployment risk, accelerate customer workflows, unlock new flexibility for multi-service architectures, staged migrations, domain-level security, and TLS automation. Customers can now manage domains, certificates, and routing relationships independently, making it faster and safer to operate at scale.
The problems we want to solve are: deploy cycles, versioning complexity, blast radius, and configuration sprawl. Traditionally, managing domains at the edge meant embedding them directly inside service configuration. That created friction by requiring a full service deployment just to add or remove a domain.
Domains now become version-less, or no longer tied to specific service versions. This new way of managing domains offers significant benefits. Changing the service a domain routes to is now just a few clicks or an API call. You no longer have to clone and edit service configurations, then activate the new version of the service to add or remove domains. Our new Domain Management system allows you to switch services the domain points to on the fly, with no downtime. In addition, there is no risk of losing a domain in a service configuration if you need to roll back to a previous service version; the domain will now always point to the active service version.
Domain Management allows you to add a domain and secure it with a TLS certificate. Even if you are not ready to assign it to a service to accept traffic, you can now prepare your domain ahead of time and start servicing traffic when you are ready.
Our new way of managing domains also removes the domain service limit. You can now have as many domains as you need pointing to a service. Large teams and multi-tenant platforms can manage domains separately from application logic and service ownership. Service pinning is no longer a requirement for customers who have large numbers of domains. You can now have multiple services associated with your dedicated Internet Protocol (IP) addresses.
The next time you log into the Fastly Control Panel, you will see a new Domains top-level navigation icon. Under this, you will find our Domains management page. You will also notice we have moved the TLS Management section from Security to Domains. On the Domain management page, we will populate the domains list with any domain listed on any TLS certificate in your account, past and present. You will see in the Service column a “-”, this means that the domain is still currently using our legacy system, or not in use at all, and the new system will not be used until you assign a service to the domain. Assigning or unassigning a service to the domain gives you the flexibility to switch between our legacy and new platforms as you work on migrating your domains to the new platform.
You can also click on the domain link to see a domain details page. This page gives you an overview of where the client request comes into Fastly, the TLS certificate used, and its expiration date, the service that the traffic is routed to, and the associated back end. All in one clear view:
How to Get Started with Fastly's New Domain Management
If you use the user interface, clicking on the Domains page and assigning a service to each of your domains is how to start using the new system. When a request comes into Fastly’s edge, the domain will be looked up in the new system first; if it is not found in the new system, we fallback to the legacy system. Once you have tested the new system, you can remove the domains from the Classic Domains section of your service configurations, and your migration will be complete. For more information, see our migration guide.
If you use the Fastly CLI or Fastly Terraform provider to manage your services and domains, you should upgrade to the new versions, which have support for version-less domains. Fastly CLI version 14.0.0 or higher and Fastly Terraform provider version 8.7.0 or higher have full support for managing domains using this new model. For more information, review the release notes for Fastly CLI 14.0.0 and Fastly Terraform provided 8.7.0.
Please note that the Fastly CLI 14.0.0 includes non-backwards-compatible changes in order to support this new domain management experience: in particular, the 'fastly domain' commands have been renamed to 'fastly service domain', and the 'fastly domain-v1' commands have been renamed to 'fastly domain'.
Cautionary tales
While our new platform has many advantages and will be beneficial in the long run, we do recognize that there are some potential pain points for some use cases.
Multi-level wildcards: In the service configuration, we support wildcard certificates such as *.example.com. However, our service configuration would treat the wildcard to mean anything to the left of the root domain. It would use the * for multiple levels, such as foo.bar.example.com. Our new system will follow the Domain Name System (DNS) and Transport Layer Security (TLS) standards and only support one level on the wildcard sub-domain. In the example above, you can use foo.example.com, bar.example.com, but foo.bar.example.com will need another wildcard or specific certificate for that level.
Purging: It is now possible to have the same domain in multiple accounts. We use the DNS to ensure the correct account receives the traffic, but this will change how purging works. Our purge API now requires a service ID:
curl -i -X POST -H "https://api.fastly.com/service/<$service_id>/purge_url/example.com" Fastly-Key:FASTLY_API_TOKEN
Service switching using shielding: If you are currently using headers to switch services in your shield point of presence (POP), please reach out to your account manager so we can understand this use case.
Platform TLS customers: Contact your account manager. We would love to have a discussion with you on how we may now be better suited to suit your needs.
The Future of Domain Management: Migration Status and Roadmap
We acknowledge that migrations are hard, difficult to prioritize, and can take a long time. We have not set an end-of-life timeline for our legacy system. We do, however, have features on our roadmap that will work only with our new system. Features are planned on our roadmap that will be built on our new platform.
We are excited to release our new domain management system and think you are really going to love the flexibility, simplicity, and security it offers. Start using it today!