Terraform Enterprise separates its address from Atlas

An infrastructure service's hostname becomes part of other people's automation. Changing it affects more than the browser bookmark, particularly when integrations submit work and wait for results. HashiCorp's February 20 announcement makes Terraform Enterprise SaaS available at app.terraform.io, while continuing to service requests at the Atlas domain. That compatibility commitment is the consequential part of an otherwise modest address change.

The announcement schedules the old web interface's redirect for February 22 at 9 AM PST. Users will need to log in again. It also encourages customers to update integrations as they upgrade workspaces to the V2 API. These are related activities, but a browser redirect and an API migration have different meanings for a running system.

I like Terraform because a general configuration language can express work against many infrastructure APIs. A hosted service built around it needs comparable care with its own interfaces. Preserving the old endpoint during a transition acknowledges that integrations are part of the product's practical contract.

Workspaces changed the organizational model

The address follows a larger redesign already described in the September 2017 Enterprise beta announcement. HashiCorp replaced environments with workspaces because environment names did not fit how organizations divided infrastructure. Production might contain a network component and several application components, each needing its own management scope.

A workspace groups settings with Terraform configuration and state. That grouping allows separate teams to own components without treating the entirety of production as one configuration. The design also gives the hosted interface a specific object around which to organize runs. Its history can describe changes to a defined component rather than changes to an ambiguous environment name.

This is an architectural choice about ownership. Consider a network configuration and an application configuration maintained independently. Calling both of them production describes their purpose, but it does not establish who can change each one or what a particular run includes. Distinct workspaces provide names for those independently managed units. That makes delegation easier to express, even though the dependencies between components still require design.

The beta also made the APIs used by the graphical interface available to users. Configuration submission and run control could therefore fit into existing CI systems. This matters for the domain transition because the service is both a web application and a machine-facing dependency. The visible hostname cannot be assessed solely as branding.

A new address does not perform a migration

The December 2017 general-availability announcement distinguishes configuration compatibility from hosted-object compatibility. Existing Terraform configurations remain compatible, but Atlas organizations and environments are not compatible with the new organizations and workspaces. The announced migration involves environments and their associated state files.

That distinction prevents a common misunderstanding. Being able to reuse configuration text does not establish that the service has already transferred the records surrounding it. A hosted workspace has identity and authorization in addition to its configuration. Treating the URL redirect as proof of a completed workspace migration would confuse two separate kinds of change.

The GA announcement gives March 30, 2018 as the deadline for migrating legacy environments. February's address announcement says a possible future retirement of the old domain will involve advance notification and a grace period. Those statements concern different objects. The legacy environment model has an announced migration deadline, while the old domain continues to support requests during the address transition.

For operators, that means a successful request to the Atlas hostname is evidence of endpoint compatibility. It does not answer whether a particular environment has become a workspace. Similarly, signing into the new web address says little about whether a CI integration has changed its API usage. Each observation establishes something narrower than completion of the whole transition.

The hosted run becomes part of the system

The GA release describes workspaces connected to version-control repositories and retaining configuration and state history. It also introduces service accounts for API access without interactive login. Together, those capabilities distinguish a hosted execution workflow from a person running a command in a terminal. The service needs to identify both the submitted configuration and the identity that is allowed to act on it.

I find the explicit service identity useful here. Automation should have permissions that can be understood independently of whichever engineer initially connected it. A domain migration is a natural point to examine that dependency, but it does not itself change the permission model. The relevant question is which service identity an integration uses after its endpoint and workspace references have changed.

The tradeoff in centralizing runs is that the execution service becomes another dependency of infrastructure management. Its API and stored workspace records become operational concerns alongside the configuration repository. The benefit is a shared place to inspect run history and authorize work. That benefit depends on keeping the relationships between configuration, workspace, and caller understandable.

February's change gives that service a Terraform-specific address after the earlier product redesign. Existing integrations retain a transition period, and browser users have a stated redirect schedule. The remaining migration work concerns the workspace model and API references, which need to be accounted for independently of whether the old hostname still responds.