Save and Share Your LocalStack State with CloudPods

You’ve got a working stack. You’ve got tests running in CI. Life is good. Until it isn’t.

Maybe your tests are slow. Maybe your coworker keeps wiping the local environment. Maybe your CI job spins up the same 8 AWS services every time just to test one Lambda. This is where Cloud Pods come in.

Cloud Pods are like save files for your cloud state. You can take a snapshot of your entire LocalStack environment — services, data, resources, everything — and restore it instantly anywhere.

In this post, we’ll show you how to:

• Save your LocalStack state into a pod
• Share or version that pod across your team
• Use it in CI to skip bootstrapping and go straight to testing

Let’s speed things up.

What Are Cloud Pods?

Cloud Pods are LocalStack’s way of letting you persist and restore your local cloud environment. Think of them like Docker images, but for infrastructure state. A pod can contain:

• Your deployed CDK or Terraform stack
• Test data in DynamoDB or S3
• Mock resources, event queues, or IAM configs
• Sharing a common setup across a team
• Onboard new teammates

You can:

• Save the current state of LocalStack as a pod
• Pull and restore a pod on any machine
• Share pods across your team or CI runners

When to Use Cloud Pods

Cloud Pods are a lifesaver when:

• Your stack takes forever to deploy
• You want consistent state across test runs
• You need sample data for demos or integration tests
• You’re trying to keep your CI jobs fast and reproducible

How to Save and Restore a Pod

You don’t need to install anything extra. Cloud Pod commands are built into the lstk CLI (lstk snapshot save, lstk snapshot load, and related subcommands).

🔐 Make sure the LOCALSTACK_AUTH_TOKEN environment variable is set. This gives you access to all Cloud Pod features, both locally and in CI.

Step 1: Make sure LocalStack is running

Start LocalStack however you normally do. Docker, lstk start, or via the GitHub Action with use-pro: true. If you’re running locally, you can set your token like this:

export LOCALSTACK_AUTH_TOKEN=<your-token-here>

Or just add it to your .env file or shell profile.

Step 2: Save your current state as a Cloud Pod

Once your stack is deployed and your test data is loaded, snapshot it:

lstk snapshot save pod:my-pod-name

Then confirm it with:

lstk snapshot list

Step 3: Load a Pod Later

On another machine, CI runner, or after a fresh start:

lstk snapshot load pod:my-pod-name

Step 4: (Optional) Merge State

Want finer control when loading? Use the --merge flag:

• --merge service-merge combines new resources without overwriting
• --merge overwrite wipes the running state before loading
• --merge account-region-merge (the default) lets the snapshot win on overlapping resources

This helps avoid surprises in case of conflicts.

Using Cloud Pods in CI or Locally

Want your CI to skip deploying the stack every time?

- name: Load Cloud Pod before testing
  run: |
    export LOCALSTACK_AUTH_TOKEN=${{ secrets.LOCALSTACK_AUTH_TOKEN }}
    lstk snapshot load pod:my-pod-name
    # now tests can run against a ready environment

For local dev, you can even auto-load a pod at startup:

lstk start --snapshot pod:my-pod-name

Stop Rebuilding What You Already Built

With Cloud Pods, you can treat your local cloud environment like code. Save it. Share it. Restore it. Run tests instantly. No more waiting on CDK deploys. No more “works on my machine” moments. No more rebuilding everything from scratch just because you restarted your Docker container.

You built the thing once. Now you get to reuse it.

🎥 Want to see it live? Check out the Cloud Pods demo in our companion video.

In the next post, we’ll push things further and introduce some chaos, literally. We’ll simulate outages and failures using LocalStack’s Chaos Engineering tools, so you can see how your app behaves when things go sideways.

Until then, snapshot your stack and skip the slow stuff 🐌.