Terraform 0.11.13 repairs remote backend initialization

A backend that stores state remotely can still execute Terraform operations locally. That combination requires initialization to reach both the remote state implementation and the local execution implementation. Terraform 0.11.13 fixes a failure in that arrangement, caused by an incomplete backport of the free remote state support.

The March 11 release lists one backend initialization fix. Its implementation and explanation in pull request 20638 are more informative than the short release note. Sander van Harmelen explains that initialization changes were missed during the January backport. A service change the previous week exposed the problem, and testing with TF_FORCE_LOCAL_BACKEND had failed to catch it.

I find this a useful example of the operational complexity behind Terraform's declarative interface. Configuration can describe the same remote workspace while the client takes a different internal route to execute an operation. Correctness depends on initializing the route that the real entitlement decision selects.

Two ways to reach local execution

The patch removes a special case from the backend factory. Previously, constructing the remote backend checked the TF_FORCE_LOCAL_BACKEND environment variable. If it was set, the factory created a local backend with the remote backend embedded inside it. Otherwise the factory returned the remote backend directly.

The remote backend already had its own local execution implementation. That made the factory's wrapper a second way to represent local operations using remote state. The two arrangements looked similar at the command line, but their object ownership differed. One began with a local wrapper around remote state, while the other began with the remote backend and delegated execution internally.

Version 0.11.13 makes the factory return the remote implementation directly. The factory no longer decides whether to wrap it based on that environment variable. This concentrates the decision about local operation handling in the remote backend, where the state-only support already lives.

The removed factory test documents the old assumption. With the environment variable set, it expected a local backend object containing a remote backend. Deleting that test follows the removal of the factory behavior. The patch's small size should not obscure that it changes which implementation owns initialization.

CLI options must reach the delegate

The other half of the fix changes CLIInit. Local backend initialization stops forwarding this method to an embedded backend. The remote backend starts forwarding it to its local implementation when that implementation supports the CLI interface.

This reversal follows the corrected ownership arrangement. When the remote backend owns a local executor, it must pass the CLI options into that executor. The patch then stores the CLI handle, color configuration, and context options on the remote implementation itself. Both pieces receive the options they need through the same initialization entry point.

This is not a change to the configuration language or a provider's resource schema. It repairs how Terraform assembles the components that interpret and run a command. A configuration conversion would not repair an uninitialized execution delegate because the defect occurs beneath the configuration's choice of resource arguments.

The distinction also explains the misleading local test result reported by the author. Setting a force-local flag at the factory selected a wrapper that did not represent the normal path through the remote backend's state-only support. Exercising that substitute path could leave the entitlement-driven path untested. This conclusion follows from the deleted wrapper and the new forwarding call, alongside the author's account.

What a remote configuration actually names

The remote backend documentation at this release describes the organization and workspace selection. For example, a configuration can identify one hosted workspace without expressing the internal arrangement of execution objects.

terraform {
  backend "remote" {
    organization = "company"
    workspaces {
      name = "networking-prod"
    }
  }
}

These names are placeholders. The block tells Terraform which state workspace to use, while the backend implementation handles its supported execution behavior. The documentation recommends supplying authentication through the CLI credentials configuration instead of putting a token in this block.

There is also a workspace prefix mode. A prefix such as networking- maps shortened CLI workspace names onto full names in the hosted service. The documentation requires either name or prefix, and rejects configurations that provide both or neither. These selection rules remain separate from the initialization bug.

A hosted state location therefore does not explain every failure associated with a remote backend. Workspace selection and execution setup are different stages with different inputs. The patch addresses the latter. It does not claim to repair arbitrary authorization failures, unavailable services, or incorrect workspace names.

The significance of the backport

The tagged changelog places this patch after 0.11.12, dated March 8. That preceding release contains several remote backend changes, including retrying server errors and checking for external updates while waiting for input. The initialization correction arrives in a branch that is actively changing its hosted workflow support.

I prefer an execution choice to have one owner inside the client. This patch moves the implementation in that direction by removing the factory wrapper and initializing the local delegate through the remote backend. It also gives a specific reason to distinguish testing a forced mode from testing the normal configuration and entitlement path.

The release documentation describes the remote backend as beta and, beginning with 0.11.12, considers it ready for production workloads while acknowledging possible unexpected issues. Version 0.11.13 addresses one such issue with a targeted initialization repair. Its practical effect is to make the normal remote backend path pass CLI configuration to the local executor it uses for local operations.