Scalr Organizational Hierarchy - Best Practices

The #1 question we get asked is "What are the best practices for using Scalr accounts, environments, and workspaces?"

This picture shows the logical organizational model in Scalr:

Working from the bottom up the recommended use of each "scope" is as follows:

Workspace

• A workspace is used to deploy and manage logical sub-divisions of your infrastructure, such as networking, database, K8 clusters, application instances etc.
• Workspace state can be shared to enable the use of shared infrastructure.
• This is where a Terraform run is performed and a state file (and its history) are stored.
• Variables (Terraform and shell) are assigned values to be passed into a run including provider credentials, possibly set at higher scopes.

For background on the underlying concept, see understanding Terraform and OpenTofu workspaces.

Environment

• A logical collection of workspaces that are typically used by the same team(s), belong to the same application/function and may have common provider credentials, governance policies, and module registry.
• In an environment you can define VCS provider connections and register modules that will be used across the workspaces.

Account

• Manage team and user access to environments with RBAC.
• Define and configure governance policies for all environments.
• Register modules that are shared by all environments.
• Optionally define provider credentials for each environment (published via shell variables).

For patterns that keep access manageable as teams grow, see RBAC at scale. And if you're setting up governance policies for the first time, our guide to enforcing policy as code in Terraform covers the fundamentals.