Remote Backend Options

Introduction

Before executing a run, you will want to select the type of backend your environments will use. By default, all environments will use Scalr as a backend, but you have the option to override that to use a backend such a S3 or any other backend supported by Terraform or OpenTofu. Regardless of the backend chosen, the Terraform run will execute in Scalr and then store the state in the backend of choice. Using the Scalr backend will give full feature functionality, while non-Scalr backends will be limited due to Scalr not having full control of the backend

Scalr offers three different options:

• Scalr Remote Backend w/ Scalr State Storage (default setting)
• Scalr Remote Backend w/ Customer Managed State Storage
• Non-Scalr Backend w/ Customer State Storage

Using the Scalr remote backend will give you the full feature functionality of Scalr. Still, some customers might have strict data residency requirements that require the state to be stored in their own bucket and/or the usage of a different backend. Regardless, all runs can still be executed through the Scalr pipeline.

Here is a breakdown of some feature functionality based on the model you choose:

The Terraform CLI can be used with Scalr and not other backend types because the Scalr remote backend block sets up the environment and workspace authentication in Scalr. Other remote backends, such as S3, do not allow you to define authentication details for Scalr which then removes the ability to execute runs from the CLI in Scalr. VCS-based workspaces will work as the VCS webhook is what will trigger a run in Scalr.

Scalr Remote Backend w/ Scalr State Storage

This is the default setting when signing up for Scalr, and users will get the full feature functionality of Scalr. Runs can be executed based on any of the three workspace types:

Even though the state is stored in Scalr, the state file can be pulled from the Scalr backend as needed through the CLI, UI, or API. See examples here. No extra configuration is needed for this model as this is how Scalr works when an account is created.

If using Scalr as the remote backend, the following applies:

• Guaranteed state locking.
• There is no need for extra infrastructure, such as a S3 bucket.
• All workspace types can be used.

This is the best option for those who don't want to manage extra infrastructure and do not have extra security or compliance requirements regarding data residency.

Scalr Remote Backend w/ Customer Managed Storage

This is the same model as above, but the state file can be stored in a customer bucket in AWS or GCP. The state is encrypted using Scalr encryption mechanisms and can be further encrypted using cloud-native encryption. All workspace types can be used.

This must be enabled before any runs are executed in Scalr. To enable this model, please follow these instructions that will be applied to the entire account.

This is the best option for those who want to use all of the Scalr workspace types, but have extra security or compliance requirements regarding data residency.

Non-Scalr Backend w/ Customer State Storage

Users can choose any Terraform or OpenTofu backend in this model, such as AWS S3, GCP buckets, and others. The runs will execute in Scalr and be stored in the customer's backend of choice with the encryption mechanisms set in the backend and/or on the bucket through the cloud service.

If a non-Scalr backend is used, the following applies:

• Disabling the Scalr backend can be done per Scalr environment.
• Only GitOps-style, No Code, and API workflows can be used as there would be no way to authenticate to the Scalr through the Terraform or OpenTofu CLI.
• Scalr cannot guarantee state locking as a third party can update the backend outside of Scalr.

This is the best option for those who have end users who want to continue to use their existing backend and have extra security or compliance requirements regarding data residency. This is also a great option when migrating to Scalr as it can plug directly into your current GitOps workflow while maintaining the state in the existing location. Some customers use this as an option to slowly migrate over to Scalr and eventually fully migrate to the Scalr remote backend.

Disabling the Scalr Backend

If you choose to disable the Scalr backend and use a different backend instead, this can be done on an environment-per-environment basis and only to new environments:

Once the Scalr backend is disabled for an environment, it cannot be re-enabled for that environment.

Using Non-Scalr Backends

Once the Scalr backend is disabled, Terraform runs can execute with the standard remote backend blocks that are normally used without Scalr. The backend blocks must be in the working directory of the repo that the workspace is linked to. Provider credentials can be passed in with native Terraform or OpenTofu mechanisms or Scalr provider configurations can be used.

Advantages to use the Scalr provider configurations:

• Provider configurations are a central place to store credentials for all providers and can be shared/assigned to environments and workspaces.
• The provider configuration can be used to authenticate for the provider as well as the backend where the state is stored.

Using Scalr Provider Configurations to Authenticate Backends

The Scalr provider configuration feature can be used, but not required, to authenticate to the remote backends defined in the code. There are a few requirements:

1. The provider configuration must have the ability to access the backend. For example, if S3 is the backend, the provider configuration set in Scalr must have access to the bucket with the permissions listed here.
2. The provider configuration must have "Export provider configurations as shell variables into the run pipeline" enabled. This will export the credentials as shell variables that can be used to authenticate to the backend instead of having to do so separately.
3. The provider configuration must be shared with the environment that the deployments are happening in.