DEV Community: Karl Schriek

Splitting a Terraform Monolith into Smaller States

Karl Schriek — Tue, 30 Jun 2026 15:39:06 +0000

If your Terraform plans are slow, your blast radius is too wide, or multiple teams are stepping on each other's changes, it's time to split your monolith. See The Problem with Large Terraform States for how to diagnose whether you've reached that point.

This guide walks through the process of breaking a monolithic Terraform state into smaller, focused states — and how Snap CD can manage the dependencies between them so you don't have to.

The approach

1. Identify natural boundaries

Look at your resources and group them by lifecycle and ownership. Common boundaries:

Networking — VPCs, subnets, route tables, NAT gateways. Changes rarely, underpins everything.
DNS — Zones, records. Usually owned by a platform team.
Compute — Kubernetes clusters, VM scale sets, container services. Changes more often, depends on networking.
Application infrastructure — Databases, caches, queues, storage accounts. Owned by application teams.
Monitoring — Dashboards, alerts, log sinks. Changes frequently, depends on everything but nothing depends on it.

A useful test: if two resources would never be changed in the same PR by the same person, they probably belong in different states.

2. Map the dependencies

Before you move anything, draw the dependency graph. Which groups produce values that other groups consume?

networking          dns
    │                 ▲
    ▼                 │
  compute ──────────►─┘
    │
    ▼
application
    │
    ▼
monitoring

The outputs that cross these boundaries are what you'll need to wire up after the split. Typical examples:

Networking → Compute: vpc_id, private_subnet_ids
Compute → DNS: load_balancer_ip
Compute → Application: cluster_endpoint, cluster_ca_certificate
Application → Monitoring: database_id, cache_name

3. Use `terraform state mv` to migrate resources

Terraform's state mv command lets you move resources from one state to another without destroying and recreating them.

# Initialize the destination state
cd modules/networking
terraform init

# Move resources from the monolith to the new state
terraform state mv \
  -state=../monolith/terraform.tfstate \
  -state-out=./terraform.tfstate \
  aws_vpc.main aws_vpc.main

terraform state mv \
  -state=../monolith/terraform.tfstate \
  -state-out=./terraform.tfstate \
  aws_subnet.private aws_subnet.private

Do this methodically, one logical group at a time. After each move:

Run terraform plan on the new state — it should show no changes.
Run terraform plan on the monolith — the moved resources should no longer appear.

4. Replace hard references with inputs

In the monolith, your compute module might directly reference aws_vpc.main.id. After the split, that VPC lives in a different state. You need to replace the hard reference with a variable:

# Before (monolith)
resource "aws_eks_cluster" "main" {
  vpc_config {
    subnet_ids = aws_subnet.private[*].id
  }
}

# After (separate compute module)
variable "private_subnet_ids" {
  type = list(string)
}

resource "aws_eks_cluster" "main" {
  vpc_config {
    subnet_ids = var.private_subnet_ids
  }
}

And in the networking module, expose the value as an output:

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

5. Wire up the cross-state dependencies

This is where it gets interesting. You've split the monolith, and now you need the outputs from one state to flow into another. There are a few ways to do this:

Option A: terraform_remote_state data sources

The built-in approach. Each consuming module reads the producer's state directly:

data "terraform_remote_state" "networking" {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "networking/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_eks_cluster" "main" {
  vpc_config {
    subnet_ids = data.terraform_remote_state.networking.outputs.private_subnet_ids
  }
}

This works but has significant drawbacks:

Every consumer needs to know the backend configuration of every producer.
There's no enforcement of the dependency order — you have to manually ensure networking is applied before compute.
Changes to networking outputs don't automatically trigger a re-plan of compute.

Option B: Wrapper scripts and CI glue

You write shell scripts or CI pipeline steps that run terraform output on one state and feed the values into terraform apply -var on the next. This is what most teams end up doing, and it's fragile — the dependency graph lives in CI config rather than in code.

Option C: Terragrunt

Terragrunt adds a dependency layer on top of Terraform:

# compute/terragrunt.hcl
dependency "networking" {
  config_path = "../networking"
}

inputs = {
  vpc_id             = dependency.networking.outputs.vpc_id
  private_subnet_ids = dependency.networking.outputs.private_subnet_ids
}

This is a genuine improvement — dependencies are declared in code, ordering is enforced, and terragrunt run-all apply handles the graph. But Terragrunt is a local CLI tool. It doesn't provide a persistent view of deployment status, approval gates, automatic re-deployment when upstream outputs change, or scoped permissions.

Option D: Snap CD

Snap CD was built for this problem. Each split becomes a Snap CD Module, and cross-state dependencies are declared as code. Snap CD enforces apply ordering, runs independent Modules in parallel, and automatically cascades changes when upstream outputs change. See Modular Deployments for a detailed walkthrough of how the Module and input system works.

Tips

Split incrementally. Move one logical group at a time. Don't try to split everything in one go.
Start with the layer that changes least. Networking is usually the best first candidate — it has many dependents but few dependencies.
Keep shared modules small. If a Terraform module (in the module {} sense) is used by multiple states, keep it focused. A module that provisions "everything for an app" is just a monolith in disguise.
Test with terraform plan after every move. A clean plan (no changes) on both the source and destination states confirms the migration was correct.

The Problem with Large Terraform States

Karl Schriek — Tue, 30 Jun 2026 15:35:47 +0000

At some point every growing Terraform project hits a wall. Plans that used to finish in seconds now take minutes. Applies feel risky because hundreds of resources share a single blast radius. Colleagues avoid running terraform plan because it hammers cloud APIs hard enough to trigger throttling. The state file itself becomes a liability — large, slow to lock, and one bad write away from corruption.

This guide covers the symptoms of an oversized state, the band-aids teams reach for, and the structural fix that actually works.

How Terraform state works under the hood

Every terraform plan does two things:

Refresh — for every resource in state, Terraform calls the provider's API to read the current real-world status. A state with 500 resources means 500+ API calls, often more when resources have nested data sources.
Diff — compare the refreshed state against the desired configuration and produce a change set.

The refresh phase is the bottleneck. It's sequential per provider (parallelism helps across providers, not within one), and every resource pays the cost whether you changed it or not. Adding ten resources to a 500-resource state doesn't make plans 2% slower — it makes the refresh 2% slower on every single plan, for every engineer, forever.

Symptoms of a state that's too large

Slow plans

The most visible symptom. Plan time scales with resource count because every resource is refreshed on every plan, regardless of whether its configuration changed. The exact speed depends on provider — AWS resources with complex nested structures (IAM policies, security group rules) are slower to refresh than simple ones, and Azure resources that require multiple API calls per refresh are worse still. These aren't edge cases — users regularly report 2,900-resource states taking 20–25 minutes to plan and 1,600-resource states taking 8+ minutes. Even starting Terraform with a large state can take minutes before a single API call is made. There's a long-standing proposal for terraform plan -light that would only refresh resources whose configuration changed, but it remains unimplemented. OpenTofu has a similar request to skip refreshing unchanged resources and a proposal for state compression to reduce the overhead of large state files.

API rate limiting

Cloud providers throttle API calls. When Terraform refreshes hundreds of resources, it can exhaust rate limits:

AWS: ThrottlingException or Rate exceeded errors, especially on IAM, EC2 describe calls, and CloudFormation.
Azure: 429 Too Many Requests, particularly on Resource Manager and Key Vault APIs.
GCP: rateLimitExceeded on Compute Engine and IAM.

Terraform retries on throttling, which makes plans even slower. In severe cases, retries exhaust their budget and the plan fails entirely.

Blast radius

Every resource in a state shares a blast radius. A typo in a DNS record can, in the same plan, sit alongside a database resize. One bad terraform apply can damage resources the operator didn't intend to touch.

This isn't theoretical. Common incidents:

A for_each key change causes Terraform to destroy and recreate resources it shouldn't.
A provider upgrade changes how a resource is read, causing phantom diffs on dozens of resources.
An engineer runs terraform apply on a plan that's stale — someone else merged a change to a different resource in the same state, and the apply picks up both.
A third-party API is down or throttling, so the refresh fails for a resource you weren't even changing — blocking the entire plan. With a smaller state, that resource would be in a different state file and wouldn't affect your work at all.

With smaller states, each of these incidents affects only the resources in that state. With a monolith, everything is in play.

Locking contention

Remote state backends use locking to prevent concurrent writes. The longer a plan or apply takes, the longer the lock is held. With a 10-minute plan, other engineers are blocked for 10 minutes. If an apply follows, that's another stretch of locked state.

Teams start working around locks — using -lock=false (dangerous), splitting work by time of day (inefficient), or simply waiting. Concurrent updates to large state files are also significantly slower because each write serialises the entire state. None of these are real solutions.

State file size and corruption risk

State files grow linearly with resource count. A 1,000-resource state file can be several megabytes of JSON. Every plan downloads the full state, and every apply uploads a new version. On slow connections or with large states, this adds latency.

More critically, large state files are harder to recover from corruption. If a write is interrupted (network failure during apply, process killed), the state can become inconsistent. With a small state, recovery is straightforward — reimport a handful of resources. With a monolith, you're reimporting hundreds. Large state files also compound the secrets problem — Terraform stores sensitive values in plaintext in state, so a bigger state means more secrets exposed in a single file. OpenTofu implemented state encryption, but Terraform's proposal has been open since 2016.

Band-aids that don't fix the problem

`terraform plan -target`

The -target flag tells Terraform to only refresh and plan specific resources:

terraform plan -target=aws_instance.web

This makes individual plans fast, but it's a trap:

You must know which resources to target. Miss a dependency and the plan is incomplete.
Targeted plans skip dependency checking. You can apply a change that breaks a resource you didn't target.
It's manual and error-prone. There's no guardrail preventing someone from running a full plan and waiting 15 minutes.
Terraform itself warns: "Resource targeting is intended for exceptional use and should not be part of normal workflow."

`terraform plan -refresh=false`

Skipping refresh makes plans fast because Terraform uses the last-known state instead of querying APIs:

terraform plan -refresh=false

The problem is obvious: if the real world has drifted from state, the plan is wrong. An engineer deleted a resource manually, someone changed a security group in the console, a colleague applied from a different branch — none of this shows up. You're planning against fiction.

Workspaces

Terraform workspaces let you maintain multiple state files from the same configuration. They're designed for deploying the same infrastructure to different environments (dev, staging, prod), not for splitting a large state into smaller pieces.

Workspaces don't reduce the number of resources per state. If your monolith has 500 resources, each workspace still has 500 resources. They solve a different problem.

`terraform state rm` and manual state surgery

When a single resource is causing problems, engineers sometimes remove it from state and reimport it:

terraform state rm aws_instance.problematic
terraform import aws_instance.problematic i-0123456789abcdef0

This is a valid recovery technique but not a scaling strategy. It's manual, risky (removing the wrong resource is destructive), and doesn't address the underlying size problem.

The real fix: smaller states

The only way to permanently fix a large state is to break it into smaller ones. Each state contains a logical group of resources — networking, compute, databases, monitoring — with its own lifecycle, credentials, and blast radius. If your state spans multiple cloud providers, splitting along provider boundaries is one of the most effective first moves. Each provider has its own API rate limits, its own authentication, and its own failure modes — an Azure outage shouldn't block a plan that only touches AWS resources. Separate states per provider also let you scope credentials more tightly and parallelise plans that would otherwise run sequentially through a single refresh cycle.

The hard part isn't the split itself — it's managing the dependencies between the resulting states. Networking outputs need to flow into compute. Compute outputs need to flow into application infrastructure. Changes to one state need to trigger re-plans in dependent states. Snap CD was built for exactly this workflow — it tracks cross-state dependencies declaratively and cascades changes automatically, so you get the benefits of smaller states without the coordination overhead. For a discussion of approaches to breaking a monolith into smaller states, see Splitting a Terraform Monolith. To learn more about how Snap CD approaches modular deployments, see Modular Deployments.

How to tell when it's time

There's no universal threshold, but if any of these are true, you should start planning a split:

terraform plan consistently takes more than a few minutes.
More than one team commits to the same Terraform root module.
You've had an incident where an apply affected resources the operator didn't intend to change.
Applies are failing due to issues with unrelated resources in the same state.
Your state spans multiple cloud providers, and an outage or rate limit on one provider blocks plans for resources on another.
Engineers routinely use -target or -refresh=false to work around slowness.

Start with the layer that changes least (usually networking) and work outward. The Splitting a Terraform Monolith guide has the step-by-step process.

Tips

Split by cloud provider early. If your state has resources across AWS, Azure, and GCP, separating them into per-provider states is one of the highest-value splits. Each provider has independent rate limits, authentication, and failure modes — keeping them together means a slow Azure API refresh delays your AWS plan for no reason.
Watch for provider-specific bottlenecks. Even within a single cloud, some resource types are slower than others. If most of your plan time is AWS IAM resources, splitting out IAM alone might cut plan time dramatically. This is also a prerequisite if you are serious about not mixing credentials on the workers that are responsible for the deployments.
Don't over-split. Five resources that always change together, owned by the same team, with the same credentials, should stay in one state. The goal is fast plans and small blast radius, not one resource per state.
Use -parallelism wisely. Terraform's -parallelism flag (default 10) controls concurrent provider operations. Increasing it can speed up plans but also increases the risk of hitting API rate limits. With smaller states, the default is usually fine.

Introducing Snap CD: Why I Built a New Terraform Orchestrator

Karl Schriek — Tue, 10 Feb 2026 11:45:35 +0000

Anyone who has operated Terraform/OpenTofu at scale knows the pattern:

You start with one state file. It works great. Then it grows. And grows. Maybe your company also grows so that now multiple teams are deploying infrastructure. terraform plan used to take seconds — now it takes many minutes. A single change triggers a refresh of hundreds of resources. One team's DNS change blocks another team's application deployment. You start sweating every terraform apply. All you want to do is add a tag to an Azure storage account, but the plan won't run through because that one fringe resource where credentials have gone stale is causing the refresh to fail! Or it does run through but now there are multiple resources you have no knowledge of, all of which will be modified by the apply.

The answer everyone arrives at is the same: break it up. Split your monolith into smaller, focused state files. Networking in one. DNS in another. Application infrastructure in a third. Give different teams the responsibility to manage different pieces.

But the moment you do that, you inherit a new problem: the dependencies between those pieces are no longer enforced, and no longer visible.

Your application module needs the vpc_id from your networking module. Your DNS module needs the load_balancer_arn from your application module. Suddenly you're stitching together terraform_remote_state data sources, writing wrapper scripts, building CI/CD pipelines with hard-coded dependency chains, and praying that someone doesn't deploy a networking change that deletes resources your application deployments depend on.

The dependency graph that Terraform/OpenTofu handles beautifully within a single state becomes your manual responsibility across states.

What I wanted

I wanted a system where I could:

Break infrastructure into small, focused modules, each with its own state file, its own lifecycle, its own blast radius. Outputs from any module automatically become available as inputs to other modules, creating a declarative dependency system across my entire infrastructure.
Have changes propagate automatically. When my "vpc" module produces a new private_subnet_id, downstream modules that consume it should re-plan and re-apply without manual intervention. It should also be a true GitOps orchestrator, meaning new commits or updated configuration should automatically trigger deployment.
Keep my cloud credentials out of the control plane. The orchestrator should coordinate work, not execute it. Execution should happen on runners I deploy in my own infrastructure. I decide where they run, what access they have, and which modules are allowed to use them. My state files I manage in whatever remote location I am most comfortable with.
Control access granularly. Infrastructure is organized into stacks (hard boundaries like "prod" and "dev"), then namespaces (logical groupings like "networking" or "storage"), then modules (individual deployments). I need role-based permissions assignable at every one of these levels, whether for service principals or users.
Stay non-invasive. No proprietary runtimes, no lock-in at the execution layer. Runners should execute standard commands like terraform plan and terraform apply in a normal shell. I should be able to SSH into a runner's working directory and run commands manually if I need to.
Manage everything as code. A Terraform Provider for the orchestrator itself, so that stacks, namespaces, modules, runners, secrets, role assignments etc. are all defined in HCL.
Let AI agents participate safely. AI coding agents are transforming how infrastructure is managed, but handing an agent unrestricted terraform apply access is a recipe for outages. The orchestrator should let me treat an AI agent as just another principal — with scoped permissions, runner restrictions, and approval gates.

None of the existing tools delivered on all of these and eventually I realized that if I wanted a system like this I would have to start building it myself.

How I solved it

This probably warrants a dedicated article by itself, but suffice it to say that for a software engineer with the interests I have (building cohesive solutions that consist of various interlocking systems) this was a wonderful project to work on. Few things I have done in my career have brought me as much satisfaction as this. It tapped into all the skills I had learnt over 20 years of software engineering and also demanded that I learn quite a few more!

It took me about six months to lay down the bare bones, then about another 12 months of iteration, testing (with pretty serious production infrastructure) and feature expansion. During this time I completely rewrote some of the core systems multiple times until I was happy with them.

With that being said, allow me to introduce Snap CD and explain how it addresses each of the requirements above:

1. Modular deployments

Snap CD organizes infrastructure into three levels:

A module is a single Terraform/OpenTofu deployment. It points to code in a Git repo, has its own state file, and defines inputs and outputs.
A namespace groups related modules. Think "networking", "storage", "applications". Typically only one team would be responsible for a single namespace.
A stack is a hard boundary, such "prod", "dev" or "staging". Namespaces are organized into stacks. Modules in different stacks don't influence each other.

Below is some very simple sample code using the Snap CD Terraform Provider to deploy a new namespace into an existing stack. Into the namespace we deploy two modules, "vpc" and "cluster", where the latter requires an output from the former as one of its inputs.

# Stack

data "snapcd_stack" "mystack" {
  name     = "my-stack"
}

# Namespace

resource "snapcd_namespace" "mynamespace" {
  name     = "my-namespace"
  stack_id = data.snapcd_stack.mystack.id
}

## Module 1 (VPC)

resource "snapcd_module" "vpc" {
  name                     = "vpc"
  namespace_id             = snapcd_namespace.mynamespace.id
  source_revision          = "main"
  source_url               = "https://github.com/snapcd-samples/mock-module-vpc.git"
  source_subdirectory      = ""
  runner_id                = data.snapcd_runner.my_runner.id
}

## Module 2 (Cluster)

resource "snapcd_module" "cluster" {
  name                     = "cluster"
  namespace_id             = snapcd_namespace.mynamespace.id
  source_revision          = "main"
  source_url               = "https://github.com/snapcd-samples/mock-module-kubernetes-cluster.git"
  source_subdirectory      = ""
  runner_id                = data.snapcd_runner.my_runner.id
}

resource "snapcd_module_input_from_output" "private_subnet_id" {
  input_kind       = "Param"
  module_id        = snapcd_module.cluster.id
  name             = "deploy_to_subnet_id" // The "cluster" module expects a variable called "deploy_to_subnet_id"
  output_module_id = snapcd_module.vpc.id
  output_name      = "private_subnet_id" // The "vpc" module produces an output called "private_subnet_id", which we map to "deploy_to_subnet_id"
}

NOTE that these are "mock" deployments, meant for illustration only. You can find their code here and here

The dependency graph is the core of Snap CD. Since the "cluster" module has a snapcd_module_input_from_output that references an output from the "vpc" module, Snap CD knows that a dependency exists. No scripts. No CI/CD glue. The dependency graph is derived from the configuration itself.

2. Event-driven CD

Modules can trigger automatically based on multiple events:

Source changes: A new commit lands on a branch, or a new semantic version tag appears. Snap CD detects this (typically via polling jobs pushed to a runner, but manual notification webhooks are also supported) and triggers a deployment job.
Upstream output changes: When a dependency's outputs change, downstream modules re-deploy.
Definition changes: When you modify a module's configuration (e.g. via the Terraform Provider, or manually via the Portal), it triggers a sync.

You can also require manual approval before applies go through, with configurable approval thresholds. This lets you build workflows where plans run automatically but apply waits for human sign-off.

Let's consider again the code for the "cluster" module above. That module points to the "main" branch of the repo at "https://github.com/snapcd-samples/mock-module-kubernetes-cluster.git". Whenever new commits are pushed to this branch, Snap CD will automatically trigger a deployment.

Similarly if the "vpc" module outputs a new value for private_subnet_id, then the "cluster" module deployment will trigger.

Lastly, a change to the definition as follows would automatically trigger a deployment.

resource "snapcd_module" "vpc" {
  name                     = "vpc"
  namespace_id             = snapcd_namespace.mynamespace.id
  source_revision          = "main"
  - source_url               = "https://github.com/snapcd-samples/mock-module-vpc.git"
  + source_url               = "https://github.com/snapcd-samples/mock-module-another-vpc.git"
  source_subdirectory      = ""
  runner_id                = data.snapcd_runner.my_runner.id
}

Here we are changing the source_url but any changes to the snapcd_module itself or to any child resources such as snapcd_module_input..., snapcd_extra_file, snapcd_backend_config and so forth would also automatically trigger a deployment!

3. Runner isolation

Snap CD's architecture cleanly separates orchestration from execution. The Server (snapcd.io) is the control plane — it handles configuration, dependency tracking, job management, and log/output storage. It never touches your cloud infrastructure directly. No AWS credentials, no Azure service principals, no GCP service accounts.

Runners are self-hosted agents that you deploy in a manner and location of your choosing. They connect to the Server over an authenticated WebSocket, pick up jobs, execute standard terraform plan and terraform apply etc., and report back with logs and outputs.

The Runner is a source-available component, maintained as part of the main Snap CD monorepo.

You configure your runners with whatever cloud credentials they need, and then you dictate which Snap CD modules are allowed to use them. For example, you may want to separate runners for "dev" and "prod", and/or for different cloud providers.

Below is an example of how you would register a runner and assign it for use by modules within the namespace we created above.

data "snapcd_service_principal" "my_service_principal" {
  // fetch a pre-existing Service Principal (this must be created manually via the snapcd.io portal)
  name = "MyServicePrincipal"
}

resource "snapcd_runner" "my_runner" {
  name                       = "myrunner"
  service_principal_id       = data.snapcd_service_principal.my_service_principal.id
  is_assigned_to_all_modules = false
}

resource "snapcd_runner_namespace_assignment" "myrunner_mynamespace" {
  runner_id    = snapcd_runner.my_runner.id
  namespace_id = snapcd_namespace.mynamespace.id
}

Runners can be assigned to a single module, to an entire namespace, an entire stack or (by setting the is_assigned_to_all_modules flag to true) to an entire organization.

4. Permission system

Role-based access control is assignable at every level of the hierarchy: organization, stack, namespace, module, as well as to runners.

Users, service principals, and groups can all be scoped precisely.

In the below example code, we set a User to Contributor on the namespace shown in the example code above


data "snapcd_user" "myuser" {
  user_name = "myuser@somedomain.com"
}

resource "snapcd_namespace_role_assignment" "myuser_contributor" {
  namespace_id            = snapcd_namespace.mynamespace.id
  principal_id            = data.snapcd_user.myuser.id
  principal_discriminator = "User" // Can be one of "User", "ServicePrincipal" or "Group"
  role_name               = "Contributor"
}

5. Non-invasive orchestration

Snap CD is not a Terraform/OpenTofu replacement. It doesn't parse HCL. It doesn't have its own resource model. Your modules are regular Terraform/OpenTofu modules. Your providers are regular Terraform/OpenTofu providers. If you stopped using Snap CD tomorrow, your infrastructure and state files would still be perfectly valid.

Snap CD also doesn't force proprietary tooling into your deployment process. Runners execute standard terraform plan and terraform apply in a normal shell. Snap CD provides the inputs — .env files, .tfvars files, scripts — and the runner executes them. If you needed to, you could navigate directly to a runner's working directory and run those commands manually.

6. Everything as code

Almost everything in Snap CD is managed via its own Terraform Provider. Stacks, namespaces, modules, runners, secrets, role assignments, etc. — all defined in HCL.

For a more complete tutorial see the quickstart guide or go directly to the sample deployment.

One of the interesting patterns that is made possible by the Terraform Provider is a module-within-module pattern. In other words, you could instruct Snap CD to deploy Snap CD modules, which then instruct Snap CD to deploy your actual resources!

7. AI on a leash

AI coding agents are transforming software development, and infrastructure is no exception. But letting an AI run terraform apply with broad credentials and no guardrails is a recipe for outages.

Snap CD lets you treat an AI agent as just another principal — with scoped permissions, runner restrictions, and approval gates. Give an agent Contributor on a test namespace but Reader on production. Let it trigger plans and diagnose drift, but require a human to approve before anything is applied.

The same RBAC, approval thresholds, and audit trail that govern human operators govern AI agents. Move faster with AI assistance, on a leash you control.

Getting started

The entire project is source available on GitHub, with a free community edition for self-hosting and advanced features available at reasonable prices. We provide deployment instructions for local use, with Docker Compose, or on Kubernetes.

A cloud-hosted edition is also available at snapcd.io.

If you've ever stared at a sprawling Terraform monolith and thought "there has to be a better way to split this up" — that's exactly the problem Snap CD was built to solve. If you would like to try it out, here is a quickstart guide.

DEV Community: Karl Schriek

Splitting a Terraform Monolith into Smaller States

The approach

1. Identify natural boundaries

2. Map the dependencies

3. Use `terraform state mv` to migrate resources

4. Replace hard references with inputs

5. Wire up the cross-state dependencies

Tips

See also

The Problem with Large Terraform States

How Terraform state works under the hood

Symptoms of a state that's too large

Slow plans

API rate limiting

Blast radius

Locking contention

State file size and corruption risk

Band-aids that don't fix the problem

`terraform plan -target`

`terraform plan -refresh=false`

Workspaces

`terraform state rm` and manual state surgery

The real fix: smaller states

How to tell when it's time

Tips

See also

Introducing Snap CD: Why I Built a New Terraform Orchestrator

What I wanted

How I solved it

1. Modular deployments

2. Event-driven CD

3. Runner isolation

4. Permission system

5. Non-invasive orchestration

6. Everything as code

7. AI on a leash

Getting started

DEV Community: Karl Schriek

Splitting a Terraform Monolith into Smaller States

The approach

1. Identify natural boundaries

2. Map the dependencies

3. Use terraform state mv to migrate resources

4. Replace hard references with inputs

5. Wire up the cross-state dependencies

Tips

See also

The Problem with Large Terraform States

How Terraform state works under the hood

Symptoms of a state that's too large

Slow plans

API rate limiting

Blast radius

Locking contention

State file size and corruption risk

Band-aids that don't fix the problem

terraform plan -target

terraform plan -refresh=false

Workspaces

terraform state rm and manual state surgery

The real fix: smaller states

How to tell when it's time

Tips

See also

Introducing Snap CD: Why I Built a New Terraform Orchestrator

What I wanted

How I solved it

1. Modular deployments

2. Event-driven CD

3. Runner isolation

4. Permission system

5. Non-invasive orchestration

6. Everything as code

7. AI on a leash

Getting started

3. Use `terraform state mv` to migrate resources

`terraform plan -target`

`terraform plan -refresh=false`

`terraform state rm` and manual state surgery