Product Update: Scalr Federated Environments

Introducing Scalr Federated Environments

A federated environment in Scalr is a designated environment that you explicitly grant access to from another environment. By default, environments are isolated from one another to maintain security and separation of concerns. Federation creates a secure, one-way bridge, allowing workspaces in a designated downstream environment to access resources and trigger actions in an upstream environment. This capability is the foundation for building automated, cross-environment workflows.

By creating this federated relationship, you unlock automation capabilities that are normally restricted to a single environment. Specifically, federation is the key to enabling two core Scalr features across your organizational structure: run triggers and state sharing. This allows you to build automated pipelines where a successful run in one environment can kick off a job in a completely different one. It also enables workspaces to securely access the outputs from infrastructure in other environments, such as a VPC ID or database endpoint, without manual intervention.

If federated environments are not used, there is no way to trigger runs or share state between workspaces in different environments. This solves the Terraform workspace dependencies in a highly secure way.

Run Triggers: Workspace Dependencies

A run trigger in Scalr creates a dependency between workspaces, where a successful run in an upstream workspace automatically initiates a run in a downstream workspace. This is ideal for scenarios where a change in one component of your infrastructure should prompt an update in another.

For example, a successful update to a shared networking infrastructure in a "network" environment can automatically trigger a run in an application's workspace in a "development" environment, ensuring the application is always using the latest network configuration.

State Sharing: Accessing Outputs Across Environments

Workspaces often need to reference outputs from other workspaces. A common example is an application needing the ID of a VPC created in a separate networking workspace. Scalr facilitates this through state sharing, allowing a workspace to read the state outputs of another.

By default, for security, state sharing is turned off for all workspaces unless explicitly enabled. However, federated environments allow you to securely grant access to state across different environments.

Once state sharing is enabled, the remote state code scippet can be used to pull outputs from the source workspace:

Combining Run Triggers and State Sharing for Seamless Automation

The true power of federated environments is realized when you combine run triggers and state sharing. This allows you to create fully automated, cross-environment workflows. A change in a foundational infrastructure workspace can trigger a run in a dependent workspace in another environment, which can then access the necessary outputs from the initial run.

This eliminates the need for manual intervention and ensures that dependent infrastructure is always up-to-date.

Example: Networking and Application Environments

Consider a scenario with two environments:

• Networking Environment: Contains a workspace that manages the core network infrastructure, including a VPC.
• Application Environment: Contains a workspace for deploying an application that needs to be placed within the VPC.

Here’s how to use federated environments, run triggers, and state sharing to automate this workflow:

1. Federate the Environments: In the settings of the Networking Environment, you would grant federated access to the Application Environment.
2. Configure State Sharing: In the Networking Environment's workspace, you would explicitly allow the Application Environment's workspace to access its state outputs. This will expose the VPC ID.
3. Set Up a Run Trigger: In the Application Environment's workspace, you would configure a run trigger that points to the Networking Environment's workspace as the upstream.

Now, when a change is successfully applied to the network infrastructure, the following automated workflow occurs:

• The successful run in the Networking Environment automatically triggers a new run in the Application Environment workspace.
• During this new run, the application's Terraform configuration uses a terraform_remote_state data source to fetch the VPC ID from the Networking Environment's state file.
• The application is then deployed or updated within the correct VPC.

This powerful combination of features in Scalr enables organizations to build robust, automated, and secure multi-environment infrastructure workflows.

See the official docs on workspace dependencies and federated environments here and try it out in Scalr today!