Terraform Cloud makes remote runs a shared workflow

Sharing a state file does not determine which machine runs Terraform or which configuration a team approves. Those decisions remain outside the state store. The September 10 Terraform Cloud announcement expands the hosted offering into a workflow for remote plans and applies, with VCS connections and unlimited workspaces.

The launch includes a free tier for up to five users. Its collaboration features include state history and locking, shared runs, and a private module registry. Paid upgrades add team permissions and governance capabilities, including Sentinel and cost estimation. This extends the earlier hosted state offering into a service that can coordinate execution and review.

I value Terraform's reusable configuration language, but configuration reuse does not answer every question about running it with other people. A shared execution workflow can make the chosen configuration and its approval visible to the people responsible for the infrastructure. The useful question is what changes when that workflow moves into the service.

A remote backend is an execution boundary

The remote backend documentation in Terraform 0.12.7 describes the client mechanism behind remote operations. A local plan or apply can cause execution in the hosted environment while output streams back to the terminal. Variable values for those remote operations come from the associated workspace.

That documentation predates today's launch and describes the earlier tier arrangement, including state-only behavior for free accounts. The launch changes the product offering. The client mechanism remains useful for understanding what a remotely executed command actually does, without treating an older pricing distinction as the new service's limits.

This is more than relocating the state file. In a local operation, the local process owns execution. In a remote operation, the command line submits work and observes a service-owned run. A terminal window can display the familiar plan output even though the provider operations happen elsewhere.

The distinction affects how a configuration obtains its inputs. A variable set in a developer's process is not automatically a variable in a remote runner. The workspace and uploaded configuration together define the context the service evaluates. A successful local plan and a remote plan are only comparable when the relevant inputs are also comparable.

A configuration version precedes a run

The remote planning implementation at that tag makes the submission sequence explicit. It first creates a configuration version for the workspace. It sets automatic queuing off because the client will create the run separately. For a plan-only operation, it also marks the configuration version speculative.

The client then uploads the configuration directory to the upload location returned by the service. It checks whether the service has received the configuration before creating the run that references it. Each stage can fail independently, and the implementation reports errors for configuration creation, upload, and run creation separately.

This gives a remote run an explicit relationship to a submitted configuration version. The service is not asking the local process to remain its filesystem for the duration of the operation. The upload creates the configuration input that the later run references.

Working directories complicate the upload. If the workspace specifies a subdirectory, the client calculates the surrounding directory needed to preserve the repository context. The implementation prints an explanation when it uploads a parent directory for that reason. The filesystem package and the directory where Terraform evaluates configuration are related but distinct concepts.

That detail matters for modules using relative paths within a repository. Sending only the immediate configuration directory can omit files the workspace expects beside it. The client's directory calculation is intended to reproduce that context in the remote environment, and its message makes the wider upload visible to the operator.

Workspace names need an explicit mapping

The remote backend can select one full workspace name or use a prefix to map several CLI workspaces to hosted workspaces. The configuration requires one of those choices. This example selects a single workspace using the documented syntax.

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

These identifiers are placeholders. The backend documentation recommends keeping the token in CLI credentials configuration instead of placing it inside the block. A configuration can identify its destination without containing the credential used to access that destination.

With a prefix such as networking-, selecting prod at the CLI maps to the full hosted name networking-prod. In single-name mode, the backend instead uses only the default CLI workspace for the selected hosted workspace. Those modes are useful for different layouts, but they should not be mixed or left implicit.

The distinction also prevents an easy naming mistake. A CLI workspace label and a hosted workspace's full name are not always identical. Reviewing the mapping is part of understanding which configuration and state a remote operation will use.

Applying is a separate permission and workflow

The remote apply implementation checks permission to apply before starting. It then rejects a CLI apply when the workspace has a VCS connection. Its diagnostic explains that such a workspace requires the VCS-driven workflow so the repository remains the source of configuration.

This is a concrete boundary between workflow modes. A developer can possess local configuration and a service token without being able to replace the VCS-controlled apply path with a local upload. Remote execution does not mean every submission route is interchangeable for every workspace.

For a supported CLI apply, the client first runs the planning phase. If there are no changes, or the run is canceled or errored, it does not proceed into an apply. Otherwise it reads the current run state and checks whether confirmation is possible and permitted.

Workspace automatic apply settings affect the confirmation path. When the workspace does not automatically apply, the client can ask for confirmation and then submit an approval for the pending run. This makes the approval refer to a service-side operation, rather than to a plan that exists only in the local terminal's memory.

I find that relationship between review and a specific run valuable. The interface still needs an intentional approval policy, but it gives the decision an object that other participants can inspect. A familiar confirmation prompt is only the visible part of the process.

Remote execution has CLI limits

The same source files document restrictions in the existing client implementation. They reject custom parallelism and resource targeting for remote operations. Planning cannot save its execution plan to a local output file, and applying an existing local saved plan is not supported through this remote path.

These restrictions mean a local automation script cannot assume that changing its backend preserves every command-line option. The remote service owns a run lifecycle, and the client supports a defined set of ways to submit and approve it. A workflow built around a local plan artifact needs to account for that different interface.

Variable delivery also has a specific limit in this implementation. The code rejects per-run variables supplied through the unsupported path and directs users toward automatic variable files or workspace variables. This is why remote execution must be understood together with its input mechanism, even when the source configuration is unchanged.

Those facts describe the client code available before the launch. They are a more precise basis for planning an integration than assuming every behavior of the local backend is reproduced remotely. Today's product announcement broadens access to hosted runs without changing the fact that the client communicates through explicit service operations.

A disconnected terminal is not a stopped apply

The apply implementation's user message distinguishes a pending apply from one that has started. Interrupting the local client can cancel a pending remote apply. Once the apply has started, interrupting the client stops log streaming but does not stop the remote apply itself.

That follows from the execution boundary. The local process observes work that another system owns. Losing that observation does not establish that the infrastructure operation has stopped, and starting another command is not a substitute for checking the existing run's status.

The launch therefore changes the collaboration problem in a specific way. State remains shared, but execution also has a service-side identity, configuration version, and approval state. The terminal becomes one interface to that workflow, while the workspace's settings and submission mode determine how a run can proceed.