Skip to main content

Introducing Emulators: Run Real Cloud Infrastructure Locally

· 3 min read
Erik Osterman
Erik Osterman
Founder @ Cloud Posse

Atmos now has first-class emulators — long-running, containerized stand-ins for AWS, GCP, Azure, Kubernetes, and an OCI registry that you provision and manage as ordinary Atmos components. Bring one up and run the full Atmos workflow — auth, secrets, vendoring, toolchain, and terraform apply — against cloud APIs on your laptop, with no cloud account and no credentials.

What's New​

An emulator is a new Atmos component kind. You declare it in a stack and drive it with the new atmos emulator command:

atmos emulator up aws -s local              # start a local AWS emulator
atmos terraform apply s3-bucket -s local    # apply real Terraform against it — no AWS account
atmos emulator down aws -s local            # stop it (state is kept by default)

Atmos wires the emulator into the rest of the system automatically:

  • No credentials. Atmos binds a local identity to the emulator and points both in-process AWS calls and the Terraform provider at the emulator endpoint — so the same stacks that target real AWS run unmodified against the emulator.
  • Multiple backends. Built-in drivers cover AWS/GCP/Azure (via Floci or LocalStack), Kubernetes (k3s), an OCI registry, and Vault/OpenBao.
  • Persistent by default. State survives down/up; atmos emulator reset wipes it, and --ephemeral opts out per run.

Why This Matters​

Emulators give you the full Atmos workflow — the same auth, secrets, vendoring, toolchain, and terraform apply you run in CI — on a laptop with nothing to log into. That means:

  • Fast, hermetic iteration. Apply, destroy, and re-apply against a local cloud in seconds, without touching a real account or spending money.
  • Onboarding without a cloud account. Contributors can run real tutorials and reproduce issues with zero access to your infrastructure.
  • The same stacks everywhere. Because the emulator is bound through Atmos identity and provider generation, your component code doesn't change between local and real cloud — laptop and CI run the identical configuration.

Try It: the Advanced Quick Start​

The advanced quick start now deploys a real event-driven AWS backend — a KMS key, an encrypted S3 bucket, a DynamoDB table, an SNS topic, an SQS queue, and an SSM Parameter Store config — entirely on your laptop, start to finish, with no AWS account and no credentials.

Persistence and Reset​

Emulators persist their state by default. Atmos bind-mounts a per-instance host directory under the XDG cache ($XDG_CACHE_HOME/atmos/emulator/<instance>) onto each emulator's data directory, so resources, images, clusters, and secrets all survive a restart:

atmos emulator up registry -s local      # start the registry
# ... push images ...
atmos emulator down registry -s local    # stop it — state is kept
atmos emulator up registry -s local      # back up — your images are still there

Use reset for a clean slate, or --ephemeral for a throwaway instance that never persists:

atmos emulator reset registry -s local --force
atmos emulator up registry -s local --ephemeral

How to Use It​

  • atmos emulator up <component> -s <stack> to start an emulator, then run your normal atmos terraform … commands against it.
  • atmos emulator reset <component> -s <stack> to wipe persisted state.
  • --ephemeral (or ephemeral: true on the component) for a throwaway instance.

See the emulator component reference and the atmos emulator command docs for details.