Slack's Use of Terraform

An interesting view into how Slack use Terraform, touching on how it manages state files (teams controlling their own state), Terraform versions, managing providers and modules. The most controversial point from my opinion is using Jenkins? But I guess we all have our own legacies to deal with.

Slack’s Terraform approach is a great peek behind the curtain of how a fast-moving company scales infrastructure-as-code—but it’s not all magic. They started out with a fairly standard setup (global state + one per AWS region), but as their cloud footprint grew, so did the complexity—eventually ballooning into over 1,400 state files. That’s impressive, but also raises some eyebrows: managing that many states can easily veer into “too much of a good thing” territory. Their tooling choices—like S3 for backend storage and DynamoDB for locking—are solid and well-proven, but not groundbreaking. It’s more evolutionary than revolutionary, which isn’t a bad thing, but might not excite smaller teams looking for bold ideas.

What is smart, though, is the way Slack pushed Terraform ownership out to individual teams while keeping a “Cloud Foundations” team in charge of guardrails, tooling, and shared modules. That’s a mature move, though it assumes those teams have the Terraform chops to manage their own pipelines—something that may not scale as cleanly in less tech-savvy orgs. Their Jenkins-based plan-and-apply process offers transparency, but feels a bit dated compared to more modern CI/CD stacks. Overall, Slack’s setup is strong and practical, but it’s not without tradeoffs—and it serves as a good reminder that growing infrastructure isn’t just about scaling code, but also about scaling the people and processes around it.

How we use Terraform at Slack.