Most security findings are fixed with a patch or minor release of the affected dependency. Some
need a major version upgrade instead: when a dependency's major release line stops being
maintained, its CVEs stay open forever, and every project that pulls it in inherits them. That is
where Atmos was: the template engine it embeds, Gomplate, had moved on from the release line Atmos
used, and that line depended on the AWS SDK for Go v1, which has reached end of support and carries
CVEs no v1 release will ever fix. Atmos never executed the affected code, but no patch or minor
release could clear the findings. The CVEs forced our hand: the template engine now runs on
Gomplate v5, two major versions ahead, and the end-of-life SDK is gone from the Atmos build
entirely.
A component that inherits metadata.component from a base should behave like one that sets it directly. Until now, parts of Atmos still treated it as a component named after the instance, which caused failed lookups and missed affected components. Fixing that also changes the backend key Atmos generates for these components, so existing projects may need one step when they upgrade.
Starting with the 2026-10-20 edition, Atmos evaluates YAML functions only when they are written as explicit YAML tags. Quoting an entire function expression keeps it as literal text.
Previously, Atmos stored deferred function calls as plain strings to evaluate them after merging and template rendering, which erased the distinction between a real YAML tag and quoted text. That was a bug.
A misspelled lifecycle event can silently prevent a security check or output sync
from running. Atmos now validates hook event names
and reports unsupported names before execution, with an edition pin available
for projects that need the previous behavior during migration.
The templates.settings.delimiters setting changes the delimiters that Atmos
templates use, but it only ever reached stack manifests. Workflow, custom command, and lifecycle hook steps kept
parsing {{ }} no matter what you configured. A project that moved to [[ ]] to keep Go-template-looking text such
as a docker inspect --format '{{.State.Status}}' argument out of the template engine still had to mark each of
those step fields !literal, or fail with a template error.
Shared AI skills need a record of where they came from and which revision a project uses.
Declarative skill sources put that selection in
Atmos configuration and lock each contributing repository for repeatable installation.
A container component's build.context and dockerfile looked like ordinary relative paths, but
they weren't resolved against anything in particular — they resolved against whatever directory
your shell happened to be in the moment you ran atmos container build. Run it from the repo root
and it worked. Run it from a subdirectory, a CI job with a different working directory, or a
script that changes directories first, and the build silently picked up the wrong Dockerfile or
found nothing at all. Setting components.container.base_path didn't help — that option was
accepted but quietly ignored.
You add platforms: [linux/amd64] to a container build step, run it, and nothing happens
differently. No error, no warning — the field is just gone, like it was never written. You spend
ten minutes checking your YAML indentation before realizing the field name was never real to
begin with.
You set mcp.enabled: true, ran atmos mcp start, and got: failed to initialize AI components: tools are disabled. MCP was on. Why did anything else need to be "enabled" for a command whose
entire job is exposing tools?
Reading !terraform.state and !terraform.output can fail to resolve for a dozen
different reasons — the backend hasn't been applied yet, your credentials aren't
configured, you don't have access to the bucket, or the state you're reading just isn't
the latest. Any one of those, on any one component, used to abort the entire
list/describe command — every other stack you did want to see disappeared behind one
unrelated failure.
The list and describe commands now degrade gracefully by default: an unresolved value
is shown as (computed) instead of aborting the command, with a one-line summary telling
you how many values were affected.
Atmos now supports credential realm isolation, preventing collisions when engineers
work with multiple customer repositories using identical identity names.
Atmos helmfile commands now use the identity system for AWS authentication and provide more flexible EKS cluster name configuration.
Starting with Atmos v1.202.0, empty or omitted base_path values in atmos.yaml now trigger git root discovery instead of defaulting to the current directory. Users with multiple Atmos projects in a single repository, or where the Atmos project root differs from the git root, must explicitly set base_path: ".".
atmos auth logout now preserves keychain credentials by default for faster re-authentication. Only session data is cleared. Use --keychain to permanently delete credentials.
Atmos now follows CLI tool conventions on macOS, using ~/.config, ~/.cache, and ~/.local/share instead of ~/Library/Application Support. This ensures seamless integration with Geodesic and consistency with other DevOps tools.
We've identified and corrected a regression in Atmos where the pager was incorrectly enabled by default, contrary to the intended behavior documented in a previous release.
