Understanding OpenTofu Remote Backends

An OpenTofu backend is where your state files get stored and read from. The state file tracks the current state of your infrastructure, which is how OpenTofu knows what to plan and apply. By default, OpenTofu keeps that state on the local machine where you run the commands. That works fine for one person on a small project, but the cracks show as soon as a team shares the same infrastructure. A remote backend is the usual fix, and it has become standard practice for any team past the first few people.

Advantages to using a Backend

The backend types each have their own trade-offs, which we'll cover further down. First, here are the reasons any remote backend is worth setting up:

• Remote State Storage: OpenTofu backends facilitate the storage of state files remotely, providing a centralized location accessible by multiple team members. This remote storage is crucial for collaboration, as it eliminates the need to share state files manually and ensures that everyone is working with the latest infrastructure state.
• Concurrency and Locking: In collaborative environments, concurrent OpenTofu executions can lead to conflicts if not managed properly. Most OpenTofu backends offer locking mechanisms to prevent multiple users from modifying the state simultaneously, ensuring consistency and avoiding conflicts. This feature is especially vital when multiple team members are working on the same infrastructure.
• Scalability: As infrastructure grows in complexity and spans multiple environments, the need for scalable solutions becomes apparent. OpenTofu backends, particularly remote ones like Scalr, Amazon S3, or Azure Storage provide a scalable platform for storing and managing state files, supporting large and dynamic infrastructures.

Types of remote Backends:

OpenTofu works with two kinds of remote backend: a standard backend and a remote operations backend. Here is how they differ.

Standard:

A standard remote backend is one in which you store OpenTofu state only. An example of this is storing the state in an AWS S3 bucket. The S3 option provides a locking capability through DynamoDB, but the main reason to use this type of backend is to ensure state is stored remotely and not on individual machines.

Example Usage:

terraform {
 backend "s3" {
   bucket = "mybucket"
   key    = "path/to/my/key"
   region = "us-east-1"
 }
}

The equivalent option for state storage in a bucket also exists in Google Cloud Storage as well as Azure Blob Storage.

Remote Operations:

The more advanced backend is a remote operations backend that not only stores the state, but also executes the OpenTofu runs, stores the run history, logs, variables, and more within a workspace. Remote operation backends become the central hub for all of your OpenTofu activity with the ability to create structure and integrate with the rest of your DevOps ecosystem. Scalr is an example of a remote operations backend that works for Terraform or OpenTofu. Terraform Cloud is the other remote operations backend in the space but only supports Terraform at this time.

Pointing OpenTofu at a remote backend takes three values: the Scalr URL for your account, the environment name, and the workspace where the run should execute.

Example Usage:

terraform {
  backend "remote" {
    hostname = "<account-name>.scalr.io"
    organization = "<scalr-environment-name>"
 
    workspaces {
      name = "<workspace-name>"
    }
  }
}

Upon running a tofu init a Scalr workspace will be created for the operations and state to be stored in.

Because the runs actually execute in the backend, a remote operations backend like Scalr can do quite a bit more than store state:

Integrations:

• Plug into Github, Gitlab, Azure DevOps, or BitBucket to create a module registry or enable a GitOps workflow for the OpenTofu code.
• Natively integrate with collaboration tools like Slack or MS Teams to be notified of OpenTofu run events and take action.
• Enable Open Policy Agent to ensure your OpenTofu runs are compliant with your organization's standards.
• Stream OpenTofu run events and metrics to Datadog or any product that supports the OpenMetrics project to analyze overall operations.
• Being that remote operations backends usually come with a UI and structure, you will be able to integrate with a SAML 2.0 solution, like Okta, to secure who has access to the OpenTofu workspaces.

Visibility:

• Use built-in reporting to understand module, provider, and OpenTofu version usage.
• OpenTofu run dashboards show the current runs in the queue as well as historical run information.

Security:

• A remote operations backend, like Scalr, comes with a full organizational model that allows for isolated environments to separate workspaces by users, teams, cloud credentials, or more.
• Through an RBAC model you can set who can create runs, who can approve applies, who will manage the module registry, or who will override OPA policies and more.

A standard backend is usually enough to get a team started with infrastructure as code. A remote operations backend is what teams reach for once they need the policy controls, access management, and run history that come with it.

Find out more about configuring a remote operations backend in the official docs here.

Summary:

A remote backend gives you shared state storage, locking so two runs don't collide, and room to grow as your infrastructure does. Which backend you pick depends on how much you want it to do. A standard backend just holds the state. A remote operations backend runs the plans and applies for you and adds the controls a larger team needs. Either way, moving state off local machines is one of the first things worth doing once more than one person is involved.

Try it out in Scalr for free today!