20 posts tagged with "Experimental"

Reusing existing Rego checks should not require a separate plan wrapper. Atmos policies now support OPA and JSON Schema alongside CEL and Starlark, for saved Terraform plans and YAML/JSON files, without an external OPA process.

Organizations with their own identity provider or credential broker need to connect that login flow to their infrastructure commands. Native Atmos plugins let teams implement the provider in Go, distribute a compiled release using any OCI registry, and use it through the same authentication commands as built-in providers.

A successful infrastructure command does not prove that a plan respected your safety rules or that the required scanner ran. Experimental Atmos policies let you reject saved Terraform plans and require lifecycle hooks using CEL expressions, with native GitHub Actions context available locally inside the job.

You ask the AI how many stacks you have. After a pause with nothing on screen, it answers that it needs your approval to run a command, and asks whether you would approve it. There is no prompt to say yes to, no sign that anything was happening while you waited, and no way to reply. The answer ends, and so does the conversation.

That is what asking a question from the terminal has felt like when the AI runs through Claude Code. Atmos now keeps the conversation open: it shows you what the AI wants to do, lets you approve it, lets the AI ask you to choose, and lets you follow up without starting over.

A controller rollout times out. The deploy fails with "release did not become ready within 5m0s" and nothing else. So you switch to the cluster, run kubectl get pods, then describe, then logs on whichever pod looks wrong - and in CI you often can't do any of that. Worse, if the release is set to roll back on failure, the rollback has already deleted the crashing pods by the time you look, taking the evidence with it.

Native Helm releases in Atmos now capture that evidence at the moment of failure and fold it straight into the error: which pod is failing, what the container is reporting, and - at debug level - the crash log and recent events.

Stack policies often differ by environment, so static policy files can require separate copies. Cross-account output references also need a consistent way to identify the account containing the producer stack. Atmos now supports inline policies and output lookups that follow the producer's deployment identity.

An urgent image rollback, a temporary feature flag, or a one-off chart setting should not require editing a stack manifest just to make one deployment. Yet a preview is only useful when it renders the exact values that the later deployment will use. When temporary values live in a shell wrapper or are applied only at deploy time, teams cannot reliably see the change before it reaches a cluster.

Shipping a Helm release is rarely a single helm upgrade --install. A first install onto a cold cluster needs a generous timeout; a routine upgrade should fail fast. A broken upgrade should roll back and clean up the resources it left behind; a broken first install should uninstall itself so it doesn't wedge the next attempt. Some releases must wait for their Jobs to finish, others only for a readiness gate, and a few shouldn't wait at all. Getting this right usually means memorizing a pile of Helm flags and threading them into shell wrappers per command — and trusting that every environment runs the same incantation.

Atmos's toolchain has had a lockfile for a while. The lockfile records the exact resolved artifact and checksum for each platform. A package manager's lockfile pins a dependency tree the same way. But the lockfile was opt-in. The setting was not documented anywhere a user could find it. Almost nobody turned it on. Almost nobody's installs were actually reproducible. The installs only looked reproducible, because the version string matched.

CloudFormation deployments need more than a template: they need parameters for each environment, a changeset review, and a way to inspect the result. Rain users also need a maintained deployment tool now that Rain is archived. Atmos provides these workflows through native CloudFormation components.

A build step often creates a value that a different step needs later. Examples are an image tag, a build number, or a deployment marker. In the past, you had only bad ways to pass this value along. You could write it into Terraform state, where it does not belong. You could run a cloud CLI command by hand. You could also build a custom file-based handoff between steps. Atmos already had a fast way to read any value from a configured store. But Atmos had no supported way to write a value into a store. The only exception was one narrow hook. That hook works only with Terraform output. For every other value, you had to leave Atmos to write it.

Compliance reviews often start with a deceptively simple question: what exactly is in this infrastructure release? Answering it by hand means reconciling vendored sources, provider locks, module downloads, and registry artifacts—without accidentally mistaking missing evidence for an empty dependency set. Atmos now makes that evidence visible in one SBOM while keeping coverage boundaries explicit. It also integrates with native CI to upload the SBOM as a GitHub Actions workflow artifact when enabled.

You upgrade a CLI tool and something changes that you never asked for. Output that used to page now scrolls past. An integration that used to run automatically now doesn't. Nothing in your configuration changed — a default did, somewhere in the release notes you didn't read, and now you're bisecting versions to figure out which upgrade moved the furniture. Every tool with evolving defaults forces this trade-off: either the project never improves its out-of-the-box behavior, or every upgrade is a small gamble.

Atmos editions resolve that trade-off the way Rust did: defaults evolve for new projects, and existing projects opt into change on their own schedule. Pin your project to a date, and upgrading Atmos never silently changes a default again.

Atmos toolchain installs can now run independent packages in parallel. Batch installs use four workers by default, while preserving the compact terminal UI: every active package keeps its own spinner, download size, verification state, and final result line.

Atmos now treats Helm as a first-class component type. Define a Helm release — local chart, remote repository chart, or OCI chart — in your stack configuration, then template, diff, apply, and delete it through the Helm Go SDK. No helm or helmfile binary required. And because Atmos owns rendering, values, lifecycle events, and credentials, an apply can publish the rendered manifests to a Git deployment repository instead of a cluster — the producer side of a GitOps workflow.

For existing Helmfile users, we also added atmos helmfile template, which renders a Helmfile component to manifests and can deliver them to the same provision targets — closing the long-standing request in #2069.

Atmos workflows and custom commands can now run containers natively. A new type: container step builds images, pushes them to registries, and runs containerized tools — Docker or Podman — through the same reusable step library that powers the rest of your automation.

Atmos now has a first-class container component kind. Where a type: container workflow step is a procedural docker run --rm, a components.container entry is declarative, stack-scoped infrastructure: one component is one service, with an image artifact Atmos builds/pushes/pulls and an optional long-running named container you operate with atmos container up/ps/logs/exec/restart/stop/rm/down. A new compositions section groups the components that make up a system.

Atmos can now manage the Terraform/OpenTofu runtime configuration (RC) for you. Declare it once under components.terraform.rc, and Atmos writes a temporary CLI config file and points the subprocess at it via TF_CLI_CONFIG_FILE and TOFU_CLI_CONFIG_FILE — no hand-managed dotfiles, no manual env exports.

Atmos can now transparently cache Terraform and OpenTofu providers and modules behind a single feature flag. Turn it on and repeated runs — local or CI — stop re-downloading the same artifacts, keep working when upstream registries are slow or down, and capture the exact versions a deployment used so builds stay reproducible. No changes to your Terraform code, provider declarations, or module sources.

Atmos hooks now have a kind system — the same before.terraform.plan / after.terraform.plan lifecycle you already know, but the dispatch is pluggable and built-in kinds ship for common tools. Two lines in a stack manifest gets you cost analysis from infracost, or SARIF scanning from checkov, trivy, or kics, with tools auto-installed via the Atmos toolchain.

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

That's the whole config. No scanner binary on PATH, no custom command wrapper, no GitHub Actions glue — atmos terraform plan vpc -s prod auto-installs checkov via the toolchain, runs it against the component, parses the SARIF, renders the findings as a markdown table in your terminal, and (when Atmos Pro is connected) ships the same body to the run page.