Customer Update: June 2026

June was the month the pieces came together.

Atmos Pro subscriptions are now live, and the Atmos 1.222 release-candidate line is the clearest signal yet of where the platform is going. Atmos is no longer just the CLI you run before Terraform. It is becoming the lifecycle layer around infrastructure changes: secrets, hooks, GitOps publishing, Native CI, local emulation, containers, and release validation all described in one system.

That matters because most teams do not struggle with Terraform syntax. They struggle with everything around it: how to run checks consistently, how to keep secrets out of logs and files, how to prove the reviewed plan is what deployed, how to publish GitOps artifacts, how to reproduce a workflow locally, and how to make all of that visible in CI without another pile of GitHub Actions and supply-chain risk.

Reference Architecture

Quiet Month for Components, Big Month for Validation

There were no major June reference architecture or module updates that need customer action. Enjoy the quiet. Your platform team gets to take a breather from upgrades this month while Atmos does the heavy lifting underneath.

The more important story is what landed underneath the reference architecture workflow. Hooks, emulators, container components, secrets, GitOps publishing, and planfile verification give us the machinery to validate more architecture paths locally and in CI. That is what makes the developer experience feel much closer to the real thing: better quick starts, better tutorials, realistic demo environments, and reproducible workflows that build confidence before anything reaches production.

If your team is watching the reference architecture roadmap, the thing to track is the Atmos 1.222 release candidate, because that is where the validation story gets much stronger.

Atmos

Secrets Without Secret Sprawl

Secrets management is probably the most requested Atmos capability we have ever had to build. It also took the most groundwork to get right.

The hard part was not adding a command that reads a secret from a backend. The hard part was making Atmos safe enough to handle secrets at all. We first had to take ownership of the IO layer inside Atmos, make masking native to the plumbing, and ensure sensitive values could not leak through normal output paths. Then we had to design a data model that fit the way Atmos already works: components, stacks, inheritance, stores, and YAML functions.

That work is now landing in the Atmos 1.222 release candidate.

Declare secrets under a component, resolve them with !secret, and manage values with the new atmos secret command group (including atmos secret init to initialize the secrets for a complete environment):

components:
  terraform:
    api:
      secrets:
        vars:
          DATADOG_API_KEY:
            store: app-secrets
            required: true
      vars:
        datadog_api_key: !secret DATADOG_API_KEY

Stores can now be marked as secret stores, so Atmos knows when a backend is carrying sensitive values and should participate in the secrets workflow. For most customers, the obvious starting point is the AWS backends you are probably already using:

• AWS Secrets Manager for application and platform secrets already managed in AWS.
• AWS SSM Parameter Store for SecureString-backed environment and infrastructure values.

The more interesting part is that Atmos can also read from the places teams use outside AWS:

• 1Password for teams that want Atmos to read from the same operational vault developers already use.
• SOPS for encrypted, opaque secret files committed to the repo, including KMS-backed workflows.

The operational win is that secrets are declared in git while the values stay in the backend you choose. On read-only commands, secrets render as masked placeholders without contacting the backend, so configuration review stays safe and portable. When Terraform needs the value, Atmos injects it at runtime and keeps secret-bearing values out of generated varfiles so they do not linger on disk.

SOPS is especially useful for platform teams that want a git-native workflow without standing up another service. The encrypted file can live in the repo as an opaque blob, while AWS KMS, GCP KMS, Azure Key Vault, GPG, or age keys control who can decrypt it. You get a record of when secrets change alongside the code without exposing the values.

See Introducing Secrets Management in Atmos for the full walkthrough.

Hooks Make Lifecycle Controls First-Class

If you are using the Cloud Posse reference architecture, you already have a strong opinionated workflow for planning, applying, and promoting infrastructure changes. The next problem customers run into is evidence and enforcement around that workflow: prove scanners ran, satisfy SOC 2 or ISO control requirements for vulnerability and IaC scanning, catch policy violations before apply, record cost checks, notify the right channel when production changes, and publish generated artifacts after the lifecycle event completes.

Atmos hooks move those controls into the component lifecycle itself.

Hooks can run before and after terraform init, plan, apply, and deploy. The May hooks release introduced built-in hook kinds for the common cases: command, infracost, checkov, trivy, and kics. That means a component can declare its own scanner, policy, and cost checks directly in the stack manifest, with tools installed through the Atmos toolchain and results rendered consistently in the terminal and Atmos Pro.

components:
  terraform:
    vpc:
      dependencies:
        tools:
          checkov: "3.2.529"
      hooks:
        security:
          events: [after.terraform.plan]
          kind: checkov

The June expansion is bigger: hooks can now run any workflow step type through kind: step. That removes the ceiling. A lifecycle hook can call HTTP endpoints, trigger a deployment notification, run containers, write markdown, emit logs, show desktop notifications, speak a completion message with say, or reuse any other registered step type with the same syntax you already use in workflows.

hooks:
  notify-slack:
    kind: step
    type: http
    events: [after.terraform.apply]
    on_failure: warn
    retry:
      max_attempts: 3
    with:
      url: https://hooks.slack.com/services/XXX
      method: POST
      body: '{"text": "Deployed {{ .atmos_component }} to {{ .stack }}"}'

This is one of the most important Atmos changes we have shipped because it makes lifecycle controls part of the platform contract. The component declares what should happen around its lifecycle; Atmos handles tool installation, execution context, retries, failure behavior, output rendering, and CI integration.

See the Atmos changelog posts for custom hooks and running any step type as a lifecycle hook.

Security Findings Where Reviewers and Auditors Need Them

If your compliance program requires vulnerability scanning, IaC scanning, or policy enforcement, the evidence needs to land somewhere useful. A scanner buried in CI logs is hard to review and harder to produce later. A better place for that evidence is GitHub Code Scanning, the same GitHub Advanced Security surface teams already use for CodeQL and third-party SARIF findings.

Atmos scanner hooks now surface findings where GitHub-native review and evidence workflows already happen:

• Job summaries show the scanner report without digging through raw logs.
• Line-level PR annotations pin findings to the exact file and line in the diff.
• GitHub Code Scanning uploads store SARIF findings as code scanning alerts for teams using GitHub Code Security / Advanced Security.
• Atmos Pro run pages receive the same hook output, so the run record has the security context attached.

Checkov, Trivy, and KICS participate automatically. Custom SARIF-emitting tools work too by declaring format: sarif on a command hook.

The practical impact is simple: the security check lives with the component, runs with the plan, and reports in GitHub. Normally, uploading third-party SARIF from Actions means adding the github/codeql-action/upload-sarif step yourself; Atmos does that reporting natively, so you get the Code Scanning evidence trail without adding another action or custom parser to every workflow. Lightweight annotations work without GitHub Advanced Security; Code Scanning upload is there when you want GitHub to retain the alert history.

Read more in the changelog posts for scanner findings in CI job summaries and scanner annotations and Code Scanning.

Plan-Then-Deploy You Can Trust

The gap between "the plan we reviewed" and "what actually deployed" is where infrastructure surprises happen. A saved Terraform plan can go stale, but applying a fresh plan without comparing it to the reviewed one defeats the point of review.

Native CI now supports planfile storage and semantic drift verification. In CI, atmos terraform plan --ci can upload a planfile to durable storage, including GitHub Actions artifacts. Later, atmos terraform deploy --ci downloads the stored plan, creates a fresh plan against current state, compares them structurally, and applies only if they match.

That gives you the practical version of plan-then-deploy:

• Review the plan during the PR.
• Re-plan at deploy time against current state.
• Compare the fresh plan to the reviewed plan.
• Fail by default if they differ.

This is stricter than "just run apply after merge" and more practical than blindly replaying a stale saved plan. It is also configured in Atmos rather than enforced by log scraping.

See Plan-then-Deploy in CI.

Local-to-CI Reproducibility

The most interesting part of the 1.222 release-candidate line is the local execution story. Teams should be able to run the same workflow locally, in CI, and against real environments without rewriting the automation for each surface.

Several June features push in that direction:

• Container steps let workflows build, push, and run containers natively through Docker or Podman. (changelog)
• Background container services let a workflow start an emulator, database, or local registry, wait for its health check, run the real steps, and tear it down automatically. (changelog)
• Emulators let you run real Atmos workflows against local stand-ins for AWS, GCP, Azure, Kubernetes via K3s, local registries, and Vault/OpenBao without cloud credentials. (changelog)
• Container components and compositions let you define local services as stack-scoped components, then group them into a composition that represents a system. (changelog)
• Parallel and matrix workflow steps bring dependency-aware fan-out into Atmos workflows without dropping into shell background jobs. (changelog)

That is the path to better quick starts and better confidence. Instead of a tutorial that explains what would happen in a real cloud account, we can validate more of the workflow locally with emulated services and realistic components.

Everything Else: 1.222 Changelog Posts

There is too much in the upcoming release to explain every item in detail here. If you want the full surface area, these are the changelog posts worth scanning:

• Introducing Secrets Management in Atmos
• Atmos Git: A Foundational Capability for GitOps Pipelines
• Plan-then-Deploy in CI: Planfile Storage and Automatic Drift Verification
• Custom Hooks: Zero-Config Security & Cost Scanners
• Run Any Step Type as a Lifecycle Hook
• Security Scanner Findings Now Surface in the CI Job Summary
• Scanner Findings as Inline PR Annotations and Code Scanning Alerts
• Native Container Steps in Atmos Workflows
• Background Container Services in Atmos Workflows
• Introducing Emulators: Run Real Cloud Infrastructure Locally
• Container Components and Compositions
• Parallel and Matrix Steps for Atmos Workflows
• HTTP Step Type: Call HTTP Endpoints from Workflows and Custom Commands
• Atmos Can Finally Speak for Itself
• Interactive and TTY Steps for Custom Commands
• GitHub Actions Build Cache
• Terraform Registry Cache
• Terraform RC Management
• Dotenv Include Support
• Component Metadata Description

Atmos Pro

Subscriptions Are Live

Atmos Pro subscriptions are now live. We have three buying motions, depending on how your team buys software:

• Team — self-service for teams ready to adopt Atmos Pro without a procurement cycle.
• Business — annual plan for platform teams that need governance, compliance support, and a standard buying path.
• Enterprise — custom agreements for organizations with procurement, security review, scale, custom terms, on-prem deployment requirements, or multiple workspaces.

The product model is intentionally simple: Atmos Pro is priced around people who can change infrastructure, while viewers are free. That means auditors, stakeholders, managers, and read-only teammates can see deployment history, drift, approvals, and reports without turning every observer into a paid seat.

For teams with a formal procurement process, Business and Enterprise can be handled through invoice or AWS Marketplace Private Offer. That keeps Atmos Pro compatible with existing purchasing workflows, AWS commitments, and vendor onboarding requirements.

If you want to talk through which buying motion fits your team, reply to this email or schedule time with us.

Community

Office Hours continues weekly. If you have questions about hooks, secrets, Native CI, emulators, or how Atmos Pro subscriptions map to your team, it is the fastest way to get answers. Register here if you do not already have it on your calendar, or catch up via the podcast.

Questions about any of these changes? Reply to this email or schedule time with us.