Overview

As you scale your Terraform or OpenTofu usage the amount of users and teams that will deploy the code will likely grow. The platform or administrative team might take on more of a role around managing the tools and pipeline and turn over everyday deployment operations to development teams. In this case, you will want separation between those teams to ensure they are only working on deployments that they should.

Scalr gives the ability to build in this separation through environments. Environments are groupings of workspaces, teams, modules, provider configurations, variables, and policies. Users and teams can only access environments they have been given explicit permissions to and what they can do within an environment is controlled by access policies.

While environments are isolated groupings of the objects mentioned above, all objects can be shared from the account scope with one more environment.

Scalr environments can and should be managed through the Scalr provider.

Creating an Environment

Environments are created at the account scope by account admins:

Upon giving the environment a name, click save and you'll be dropped into the list of environments. To add objects to an environment, which will then be inherited by the users and workspaces in the environment, click on the environment name:

Once on the environment management page, you'll have the option to add the following objects:

• VCS providers - Must be enabled if you want to use VCS-based workspaces for PR automation or populate the module registry with private modules. All VCS based workspaces in the environment will inherit the VCS provider(s) set for the environment.
• Provider Configurations - Must be used if you want to pass credentials for providers to the workspace and runs within a workspace. Many provider configurations can be added per environment and if they are set as the default, the configuration will automatically be assigned to all workspaces created in the environment. Provider configurations can be assigned to multiple environments.
• OPA policies - If enforced, all runs within the environment will need to pass the OPA policies assigned to the environment. OPA policies can be assigned to one or more environments. It is common to have different policies per environment based on the nature of the workloads in the environment.
• Access policies - Access policies are required to give teams access to the environment. It's common, but not required, for teams to have full admin permissions for an environment as environments are typically segmented by team, app, or project.
• Variables - Any shell or Terraform/OpenTofu variables assigned to the environment will automatically be inherited by workspaces within the environment. Workspace users will not be able to update variables inherited from the account or environment.

Once all objects are set for the environment, log into the environment and create a sample workspace to confirm the inheritance of the objects by clicking "jump to environment":

Using the Scalr Provider

As mentioned earlier, it is a best practice to use the Scalr Terraform/OpenTofu to manage Scalr environments at scale:

resource "scalr_environment" "this" {
  name                            = "test-env"
  account_id                      = "acc-xxxxxxxxxx"
  cost_estimation_enabled         = true
  policy_groups                   = ["pgrp-xxxxxxxxxx", "pgrp-yyyyyyyyyy"]
  default_provider_configurations = ["pcfg-xxxxxxxxxx", "pcfg-yyyyyyyyyy"]
}

Find the full documentation on this here.