Platform
Resources
Ship infrastructure changes at the same pace as your application code—safely, gradually, and with measurable impact.
Modern teams rarely flip a single switch when rolling out a new feature. Instead, they stage changes across environments, user cohorts, or regions to steadily increase exposure while watching metrics. This practice, called continuous promotion, lowers risk and shortens feedback loops.
Infrastructure as code (IaC) should enjoy the same guard‑rails, yet most IaC tools today assume a single‐shot deploy. This can cause risky race conditions where all infrastructure rushes to converge to the desired final state without built‑in emphasis on phased exposure or rollout safety.
What if you could promote infrastructure changes in phases (e.g., Asia Region → Europe Region → US West Region → US East Region) with safeguards between each hop, without extra setup?
Meet Statsig Release Pipelines
Release Pipelines are a new feature in Statsig built for managing IaC multi‑stage rollouts. It integrates natively with Statsig feature flags so that you can safely rollout infrastructure changes with your feature releases—no additional steps needed.
When are Release Pipelines used?
Rollouts that need to respect infrastructure boundaries (e.g., multi‑region / multi‑cluster)
Progressive delivery across environments with zero‑downtime (e.g., dev → staging → prod)
Deployments that must be paused for manual sign‑off or change‑management windows
Who are Release Pipelines for?
Release Pipelines are especially valuable for platform engineers, SREs, and DevOps teams responsible for complex, distributed systems where blind‑side effects are expensive and risky. It can also benefit organizations that want a single, streamlined feature management workflow that includes flags and infrastructure.
To learn more about Statsig Release Pipelines, read our announcement blog post and the documentation.
Statsig × Pulumi: How the pieces fit together
Pulumi is a popular IaC tool that help teams manage their infrastructure deployments at scale. In Release Pipelines, Statsig and Pulumi are complementary: Statsig decides when a change should progress, while Pulumi ensures what changes occur to match that intent.
In this section, we’ll walk through how these pieces fit together in a Release Pipeline.
A. Statsig orchestrates the staged rollout
In Statsig, a Release Pipeline enables features or configs only to the targets defined for the current stage. When the transition conditions are satisfied, it automatically advances to the next stage.
B. Pulumi executes infrastructure changes
Since Pulumi programs are real code, you can:
Initialize the Statsig server SDK at the start of your deployment.
Get deployment decision from feature flags or dynamic configs.
Deploy the target resources.
Each time the pipeline advances, rerunning pulumi up—Pulumi’s command that applies the necessary changes—picks up the new config values and applies the next slice of infrastructure. Statsig offers SDKs in every language Pulumi supports.
C. Statsig enables real-time control over release progression
Statsig Release Pipelines lets you control the progression of your release to make live changes on demand, with commands like:
Approve: Manually green‑light the next phase once metrics look good.
Pause: Hold the rollout at the current phase to gather more data or schedule windows.
Abort: Stop and roll back instantly if a regression appears.
Full Rollout: Skip remaining phases and push to 100% when you’re fully confident (or in a break‑glass scenario).
See it in action
To show how it works in an actual setup, let’s go through a quick demo. All of the demo code is accessible here: Statsig Pulumi Demo on GitHub.
Setup overview
ColorTeller is a tiny demo service we created that replies with the color specified in its application config. For this demo, we’ll deploy two identical instances—one in us-west1, one in us-central1—both initially configured to return blue.
A two-phase Statsig Release Pipeline then drives a gradual change: phase 1 targets us-west1, phase 2 targets us-central1. Updating the Dynamic Config (no redeploy required) flips each instance from blue to purple as its phase is approved, letting us verify the change region-by-region before it reaches 100 percent of traffic.
Walkthrough
Create a dynamic config. Add a single default value to the dynamic config. (You can skip targeting rules for the purposes of this demo).
Define the Release Pipeline. Next, configure a two-phase release pipeline. Each phase targets one region and requires manual approval before proceeding.
Deploy ColorTeller. In Pulumi, we’ll run a simple looped script that continuously executes
pulumi up, mimicking a production CI/CD system. In a real workflow, you could swap this for GitHub Actions, the Pulumi Kubernetes Operator, or any of the options listed in Pulumi’s continuous-delivery guide. With the default dynamic config, both instances will display blue.
Kick off a release. Commit the new config in Statsig to start a gradual rollout that changes the color to purple, one region at a time. Approve the first phase to begin with us-west1.
Watch the rollout. Once the application picks up the new config, us-west1 turns purple while us-central1 remains blue. This confirms that the pipeline is releasing safely, region by region.
Complete the rollout. Everything looks healthy in us-west1, so we can approve the second phase for us-central1.
Confirm the rollout. After propagation, both regions show purple and the change is fully launched!
Continuous promotion brings the safety of progressive delivery to your infrastructure layer. With Statsig Release Pipeline deciding when to change and Pulumi ensuring what changes, you can ship infra changes with the same confidence and speed you expect for application features.
Release Pipelines are currently in beta. Reach out to us on Slack if you're interested in trying it out or have any questions. You can also read more details in our documentation. Happy and safe releasing!
Looking for a smarter way to ship?
