cloudposse/atmos v1.212.1-rc.1

on GitHub

Add automatic chunking for large stack/instance upload payloads to Atmos Pro. When payloads exceed the configurable threshold (default 4MB), the CLI splits the array into chunks and sends them sequentially with batch metadata (batch_id, batch_index, batch_total).

Why

Large infrastructure repos generate affected stack and instance payloads that exceed Vercel's ~4.5MB serverless body size limit, producing HTTP 413 Request Entity Too Large errors. The existing StripAffectedForUpload() reduces payloads by 70-75% but is insufficient for repos with hundreds of stacks.

Changes

• New pkg/pro/chunked_upload.go — generic chunking logic (sendChunked, splitSlice, metadataOverhead)
• Updated UploadAffectedStacks() and UploadInstances() to use chunked upload
• Added batch_id, batch_index, batch_total fields to upload DTOs
• Switched from indented to compact JSON for upload payloads (~30% smaller)
• Added max_payload_bytes config to settings.pro in atmos.yaml
• Backward compatible: small payloads send without batch fields, old servers ignore unknown fields

Ref

Companion server-side PR: cloudposse-corp/apps (feat/chunked-stack-uploads → staging)

Summary by CodeRabbit

• New Features

  • Large stack and instance uploads now auto-split into multiple requests when exceeding a configurable threshold (default 4MB).
  • Added configurable upload limit via atmos.yaml (settings.pro.max_payload_bytes).
  • Chunked uploads include batch metadata (batch_id, batch_index, batch_total) for reliable reassembly; small payloads remain single-request and backward compatible.
  • Upload payloads use compact JSON serialization to reduce size.

• Documentation

  • New blog post and roadmap entry describing chunked upload behavior and configuration.

• Tests

  • Added unit and integration tests validating chunking, batching, and error handling.

• Introduced Gists — a new content type for community-contributed recipes that demonstrate creative combinations of Atmos features (Custom Commands, Auth, Toolchain, etc.)
• Added a GistDisclaimer React component (purple/violet pill) that displays on all gist pages: "Gists are examples that demonstrate a concept, but are not actively maintained and may not work in your environment or current versions of Atmos without adaptations."
• Extended the file-browser plugin with a disclaimer option, enabling a second plugin instance at /gists alongside the existing /examples
• Added "Gists" to the top navbar between Examples and Community
• Created the first gist: MCP with AWS — a masterclass in combining Custom Commands + Auth + Toolchain to run 21 AWS MCP servers with automatic credential management (sourced from cloudposse/infra-live PR #1662)
• Added a blog post announcing the Gists feature
• Added a gist-creator Claude agent for standardizing future gist creation

why

• Community members share creative Atmos patterns that don't fit the maintained examples model — they need a home that sets the right expectations
• The MCP with AWS recipe demonstrates the composability of Atmos features (the key insight: atmos auth exec wraps MCP server processes with authenticated AWS credentials)
• Having a standardized gist structure and agent makes it easy to add more recipes over time

references

• Source material for first gist: https://github.com/cloudposse/infra-live/pull/1662

Summary by CodeRabbit

• New Features

  • Introduced Gists — a community-contributed recipe space for Atmos.
  • Added an AWS MCP gist with install/start/test commands and many preconfigured AWS services and startup presets.
  • Added toolchain alias and minimal Atmos config to enable gists.
  • Exposed Gists in the site file browser at /gists with a configurable disclaimer and navbar link.
  • Added Mermaid diagram support and a reusable Gist disclaimer UI component and styles.

• Documentation

  • Published blog post introducing Gists and contribution guidelines.
  • Added gist README templates, registration guidance, required README structure, and a verification checklist.

• Adds two new auth identity kinds: ambient (cloud-agnostic passthrough) and aws/ambient (AWS SDK default credential chain)
• ambient is a pure do-nothing passthrough that preserves the environment unchanged
• aws/ambient resolves credentials via the default AWS SDK chain (env vars → shared config → IRSA → IMDS → ECS task role) and supports chaining with aws/assume-role
• Unlike other AWS identities, aws/ambient does not clear credential env vars or disable IMDS

why

• Atmos currently explicitly disables IMDS (AWS_EC2_METADATA_DISABLED=true) and clears IRSA env vars in PrepareEnvironment(), blocking use of infrastructure-provided credentials
• Running Atmos in EKS pods (IRSA), EC2 instances (instance profiles), ECS tasks, or CI runners with pre-configured roles required workarounds
• This makes ambient/infrastructure-provided credentials a first-class auth path, including support for chaining aws/ambient → aws/assume-role for cross-account access

references

• PRD: docs/prd/ambient-identity.md
• Blog: website/blog/2026-03-25-ambient-credential-support.mdx
• Example config: examples/config-profiles/profiles/eks/auth.yaml
• Docs: Updated website/docs/stacks/auth.mdx with ambient identity examples
• Roadmap: Updated website/src/data/roadmap.js with shipped milestone

Summary by CodeRabbit

• New Features

  • Ambient credential support: ambient (cloud-agnostic passthrough preserves environment) and aws/ambient (resolves AWS credentials via the SDK default provider chain; can be used standalone or chained for cross-account assume-role).

• Documentation

  • Added PRD, expanded docs, examples, blog post, and roadmap entry with EKS IRSA, EC2 instance profile, ECS task role, and chaining examples.

• Tests

  • Added comprehensive unit and integration tests covering ambient behaviors, region handling, credential flows, and chain construction.

• Prevent IRSA/pod-injected AWS env vars from overriding Atmos-managed credentials in subprocess execution
• Pass os.Environ() through PrepareShellEnvironment to sanitize it (delete problematic vars), then pass the sanitized env to subprocess via WithBaseEnv — avoiding re-reading os.Environ() which would reintroduce IRSA vars
• Add SanitizedBaseEnv field to ConfigAndStacksInfo to carry sanitized environment through the hooks→terraform/helmfile/packer pipeline
• Add WithBaseEnv variadic option to ExecuteShellCommand for backward-compatible sanitized env injection
• Fix auth exec and auth shell to use sanitized env directly instead of re-reading os.Environ()

why

On EKS pods with IRSA (IAM Roles for Service Accounts), the pod identity webhook injects AWS_WEB_IDENTITY_TOKEN_FILE, AWS_ROLE_ARN, and AWS_ROLE_SESSION_NAME into the pod environment. When using Atmos auth on ARC (Actions Runner Controller), these IRSA vars leaked into terraform subprocesses because three code paths re-read os.Environ() after auth sanitization:

1. Hooks path (terraform/helmfile/packer): authenticateAndWriteEnv only passed ComponentEnvSection (stack YAML vars) to PrepareShellEnvironment — IRSA vars weren't in the input so delete() was a no-op. Then ExecuteShellCommand re-read os.Environ() as the base.
2. auth exec: executeCommandWithEnv re-read os.Environ() to build subprocess env.
3. auth shell: ExecAuthShellCommand → MergeSystemEnvSimpleWithGlobal re-read os.Environ().

AWS SDK credential chain gives web identity tokens higher precedence than shared credential files, so the pod's runner role was used instead of the Atmos-managed tfplan role, causing AccessDenied errors.

Approach

Instead of setting cleared vars to empty string (which pollutes the subprocess env), we pass a clean, sanitized environment:

1. authenticateAndWriteEnv now passes os.Environ() + ComponentEnvSection to PrepareShellEnvironment, which deletes problematic keys
2. The sanitized result is stored as SanitizedBaseEnv on ConfigAndStacksInfo
3. ExecuteShellCommand accepts WithBaseEnv(info.SanitizedBaseEnv) to use the sanitized env instead of re-reading os.Environ()
4. auth exec and auth shell pass sanitized env directly to subprocess, bypassing the re-read

references

Fixes credential precedence conflict where IRSA vars override Atmos-managed credentials on EKS pods running ARC (DEV-4216)

Summary by CodeRabbit

• Bug Fixes

  • Prevented AWS IRSA env vars from leaking into subprocesses by sanitizing auth-related variables (overridden with empty values) so spawned commands use Atmos credentials.
  • Ensured credential-chain caching no longer skips the final role, forcing proper re-authentication when needed.

• Refactor

  • Preserve and propagate a sanitized environment end-to-end for shell/exec paths so child processes receive the corrected env list.

• Tests

  • Updated and added tests to validate env sanitization and subprocess propagation.

• Documentation

  • Added guidance describing the credential-chain caching fix and expected behavior.