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.

What Are the Advantages of Using a Remote 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: A remote backend keeps the state file in one central spot everyone on the team can reach. That matters for collaboration because nobody has to pass state files around by hand, and everyone works against the latest infrastructure state.
• Concurrency and Locking: When several people run OpenTofu at once, the runs can step on each other if nothing stops them. Most backends lock the state so two people can't change it at the same time, which keeps things consistent. You really feel the value of this once a few people share the same infrastructure.
• Scalability: As your infrastructure gets bigger and spreads across more environments, you need something that can keep up. Remote backends like Scalr, Amazon S3, or Azure Storage give you a place to store and manage state that scales with large, fast-moving setups.

What Types of Remote State Backends Does OpenTofu Support?

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. A remote operations backend becomes the central hub for all of your OpenTofu activity, where you can add structure and wire it into 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.

Which Remote Backend Should You Choose?

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!