Terraform 0.11.8 connects CLI planning to Enterprise

Moving state off a workstation does not necessarily move the computation that uses it. Terraform 0.11.8 introduces a backend that connects those concerns to Terraform Enterprise. The August 15 release notes announce the initial remote backend for hosted and Private Terraform Enterprise. Its initial execution support is deliberately narrower than a complete remote command-line workflow.

The implementation accepts the plan operation and rejects other execution operations with an instruction to use the remote backend's web interface. That includes applying through the CLI. The backend brings remote planning into the terminal while keeping the rest of execution within the Enterprise interface at this stage.

I find the distinction useful because remote state and remote execution solve different problems. A shared state location establishes where records live. Remote execution also establishes where the configuration is evaluated and which service manages that operation. The new backend begins connecting the familiar CLI to that hosted workflow without claiming every command is already supported.

One local workspace can map to one remote workspace

The versioned backend documentation requires an Enterprise account or a Private Terraform Enterprise installation. Its configuration identifies a hostname, an organization, and a workspace mapping. The default hostname is app.terraform.io, while an explicit hostname can identify a private installation.

terraform {
  backend "remote" {
    organization = "example-company"

    workspaces {
      name = "network-production"
    }
  }
}

With name, the local default workspace maps to the named remote workspace. This mode does not support additional local named workspaces. An engineer who manages one remote component from a working directory can use a stable remote name without selecting that name through the CLI workspace command.

This is a mapping between two naming systems. The local name default does not mean that the remote service must also use that name. Backend configuration supplies the relationship, which matters when interpreting command output or locating the corresponding record in Enterprise.

The implementation enforces that relationship. A named local state is rejected when the backend has no prefix mapping. Conversely, default state is rejected when only a prefix is configured. These checks prevent the same backend configuration from assigning inconsistent meanings to local default and named workspaces.

Prefix mapping supports several related workspaces

The other mode uses prefix instead of name. A prefix filters remote workspaces and adds a shared component to their remote names. Local workspace names remain short because the backend removes the prefix when returning names to the CLI.

terraform {
  backend "remote" {
    organization = "example-company"

    workspaces {
      prefix = "network-"
    }
  }
}

A local workspace named production maps to network-production remotely in this example. New workspaces receive the same prefix. The mode supports a related set of workspaces through one configuration while preserving an organizational naming convention in the remote service.

Exactly one mapping mode is allowed. Both the prose documentation and implementation reject configurations that supply neither option or both options. The documentation's initial example happens to show both keys together, but its stated constraint and the code agree that they conflict. Each example here uses one option to follow the actual contract.

Prefix mode also changes initialization around default state. The documentation says an existing default state file produces an initialization error in this mode. If default is selected without that state, initialization can finish with instructions to select or create a named workspace. This prevents default state from silently becoming a member of the prefixed set.

I consider explicit workspace mapping preferable to guessing from directory names. The configuration records which Enterprise component an operation targets. That also makes the backend block operationally significant, since changing a name or prefix changes the remote mapping a reader needs to understand.

Host discovery and credentials remain separate

The implementation discovers the configured hostname's tfe.v2 service before constructing the API client. It rejects a host that does not advertise a remote backend API. A hostname therefore identifies a service to discover, rather than requiring the configuration author to construct the API's base path manually.

Authentication can come from host-specific credentials in the CLI configuration file. The backend documentation recommends that approach instead of embedding the optional token argument in the backend configuration. The implementation checks the CLI credentials first and uses the backend argument when no token is available there.

The source also shows that accessing a missing mapped workspace can create it. For a release candidate or final Terraform build, creation sets the new workspace's Terraform version to the running CLI version. This is part of the initial coordination between the executable in the terminal and the remote workspace that will perform its plan.

None of those facilities extends the supported execution operations beyond the initial plan implementation. The backend's command list includes utilities such as initialization, output, and workspace management, while the execution dispatcher explicitly limits remote operations to planning. Terraform 0.11.8 therefore provides a concrete integration point for Enterprise state and CLI-driven remote plans, with application of those plans still belonging to the web workflow.