6 posts tagged with "Experimental"

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 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 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 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 — 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.