A repository can contain many component sources, mixins, and targets. Fetching these one at a time leaves the network idle between jobs and makes a large update hard to follow. Overlapping destinations also mean downloads cannot simply copy files whenever they finish.
Vendor pull prepares up to four packages at once and installs them in declaration order. Local sources wait for earlier writes before being read. Vendor update checks upstream versions concurrently and preserves the order and formatting of manifest edits.
The shared progress display shows active phases, download percentages when the total size is known, retries, and completed results. A ready package is waiting for its turn to install. The overall bar advances during downloads with known sizes and when packages become ready, with equal weight for preparation and installation. The completed count advances only after processing finishes. CI receives plain result lines, and structured update reports stay on stdout.
The vendor clean command displays relative paths and preserves every lock entry when removing vendored files. Recorded versions, checksums, and provenance remain available for the next pull. Fully cleaned packages reinstall without drift warnings; partial deletion and modified files still trigger checks.
atmos vendor pull --max-concurrency 8
atmos vendor update --check --max-concurrency 8
atmos vendor update --pull --max-concurrency 8
Set vendor.max_concurrency in atmos.yaml
or use ATMOS_VENDOR_MAX_CONCURRENCY. Explicit flags take precedence over the
environment and configuration. Set one worker for serial execution.
Projects with an edition pin before 2026-09-15 keep
one worker by default. All editions receive the progress display, and explicit
concurrency settings override the pin.
Try the commands on your component catalog and share feedback in Atmos GitHub Discussions.
]]>An experimental warning is useful when you first use a feature. Seeing it again for every component in a workflow adds noise, especially alongside repeated Atmos version, CI, and Pro status messages.
The new experimental mode warn-daily gives each feature its own 24-hour timer. A toolchain warning does not suppress the first warning for devcontainers or an experimental setting. Commands in the same experimental family share a timer, and CI commands and CI hooks share the CI feature's timer.
Atmos stores readable feature names and timestamps in its shared local cache. The timers apply across invocations and projects using that cache. Clearing the cache makes warnings eligible again; an unavailable cache never blocks the command. Concurrent suppression is best effort on Windows.
Startup banners appear at the top-level invocation and are suppressed in child Atmos calls. Markdown output also follows Atmos's explicit theme and color profile without automatic terminal-style probing.
The new default requires no configuration for unpinned projects. To choose it explicitly:
settings:
experimental: warn-daily
Projects pinned to a config edition before 2026-09-14 retain warn as the default. An explicit settings.experimental value or ATMOS_EXPERIMENTAL takes precedence over the edition default.
To show experimental warnings on each top-level invocation, set experimental: warn. Child command and setting notices are now suppressed in this mode too, independently of the edition pin. CI hooks retain their existing warn behavior. The error and disable modes remain enforced on every invocation, including nested calls, regardless of cached warnings.
See the experimental settings reference for all modes, or report unexpected output.
]]>terraform init is necessary the first time you touch a working directory, and again
after a real change — a new provider, an updated module, a different backend. Repeating that same
work before every single command, whether or not anything changed, adds real time to a workflow:
provider downloads, backend re-initialization, module resolution, all over again for a component
that's identical to how it was a few seconds ago.
That's exactly what Atmos did. Every Terraform subcommand — plan, apply, shell, destroy,
and even the read path behind !terraform.output and atmos.Component — started with a full
terraform init -reconfigure, unconditionally:
atmos terraform apply demo -s dev
# Initializing provider plugins...
# Initializing the backend...
# ...apply completes...
atmos terraform output demo -s dev
# Initializing provider plugins... <- nothing changed, but init runs again
# Initializing the backend...
Nothing about demo changed between those two commands, but the second one pays the full init
cost anyway. On a slow connection, or with a component that pulls in a lot of providers, that
turns a fast edit-plan-apply loop into a slow one. Issue #620
asked Atmos to be smarter about this — Terragrunt-style Auto-Init, where init only re-runs when it
actually needs to. Issue #1263 asked for
something related: a way to have Atmos run init -upgrade automatically when a provider
constraint changes, instead of requiring -upgrade to be typed by hand after every version bump.
Atmos now fingerprints the inputs that actually affect terraform init — the component's root
Terraform/OpenTofu files, the lock file, the CLI configuration, the resolved binary, and relevant
environment variables — and compares that fingerprint against the one recorded after the last
successful init. When nothing has changed, and the working directory still looks initialized,
Atmos skips init entirely. Applying a component and then reading one of its outputs no longer
performs two full inits.
-reconfigure and -upgrade get the same treatment instead of being added unconditionally:
-reconfigure only goes on when the backend configuration actually changed (or on the first
init, or after a working directory is re-provisioned), and -upgrade only goes on when Terraform
or OpenTofu itself reports that an upgrade is required — the behavior #1263
asked for.
None of this trusts the fingerprint blindly. If a skip turns out to have been wrong — a nested
module changed, or .terraform was altered by hand — Terraform or OpenTofu fails with a
diagnostic like "Backend initialization required" or "Required plugins are not installed"
before it ever touches state. Atmos recognizes that class of diagnostic, runs the init that should
have run, and retries the command once. The one gap this doesn't close is a change inside a
nested local module, which isn't part of the fingerprint — that's caught by the same retry path
rather than avoided up front, and it's a limitation Terragrunt's own Auto-Init shares.
Behavior change, automatically protected by editions: init no
longer runs unconditionally, and -reconfigure/-upgrade are no longer added to every init, by
default. If your project is pinned to an edition from before
2026-09-12, you see byte-for-byte the same behavior Atmos always had — no config changes needed.
Unpinned projects, and anything pinned on or after that date, get the new defaults automatically.
See Config Editions for how pinning works.
Three new settings under components.terraform.init, all defaulting to auto:
components:
terraform:
init:
mode: auto # auto | always | never
reconfigure: auto # auto | always | never
upgrade: auto # auto | always | never
mode controls whether init runs at all: auto skips it when nothing relevant changed, always
restores the previous behavior, never disables the ordinary implicit init — but terraform workspace select/new still forces a reconfigured init regardless, since it always needs one;
--skip-init is the flag that suppresses init unconditionally, including for workspace.
reconfigure and upgrade control the two flags the same way, independently.
mode and upgrade are edition-protected: pin edition: "2026-09-11" or earlier and both roll back to their pre-this-PR behavior (always and never
respectively) with no other config changes. reconfigure isn't — see the note on
init_run_reconfigure below.
Each setting also has a matching flag and environment variable for one-off overrides:
atmos terraform plan vpc -s dev --init-mode=always
atmos terraform apply vpc -s dev --init-reconfigure=always
atmos terraform plan vpc -s dev --init-upgrade=always
The existing init_run_reconfigure boolean keeps working: false maps to init.reconfigure: never, and the previous default true now maps to init.reconfigure: auto rather than
always. Unlike mode/upgrade, this one isn't edition-protected — pinning an earlier edition
doesn't restore it, because init.reconfigure has to stay unset internally for the legacy
init_run_reconfigure mapping to keep working at all. Set init.reconfigure: always explicitly
to keep the exact previous behavior.
See Terraform Configuration for the full setting reference, and Automatic Initialization for how the skip decision and recovery path work.
Have feedback on this feature? Open an issue or join the conversation in the Cloud Posse community Slack.
]]> Post-deployment checks need a clear result for every test, including independent checks that can still run after another fails. Shell wrappers and CI-specific reporting make that behavior harder to reuse locally and across deployments.
Atmos supports type: test in workflows, custom commands, and lifecycle hooks.
Tests continue by default, while a tree with green/red dots and a bottom progress
bar shows the results. Nested parallel and
matrix groups share the same report.
Attach a test step to an after.terraform.apply hook with kind: step and
on_failure: fail to make checks part of the deployment result. Use output: all
when debugging, or fail.mode: fail_fast when remaining checks should stop after
an error. CI receives a static tree with the same failure details.
See the test step reference for configuration and failure behavior.
The local example runs without stacks. Running bare atmos now displays
usage and available commands, including custom commands, without requiring stack
configuration.
Try the local example and share feedback in GitHub Discussions.
]]>Native Helm components already resolve chart values from inherited stack configuration, component
value files, and inline values. Before this update, there was no Helm-compatible command-line
override surface for those resolved values. Operators had to commit a temporary configuration
change, use a separate wrapper around Helm, or accept that a diff did not necessarily match the
subsequent deployment.
Native Helm now accepts repeatable Helm-compatible -f/--values, --set, --set-string,
--set-file, --set-json, and --set-literal flags on template/render, diff/plan, and
apply/deploy. The overrides apply only to the current invocation and take precedence over the
resolved component values; they never modify stack configuration.
The new atmos helm values command prints the final, masked value map as formatted YAML. It lets
you inspect the value set that a preview or deployment will consume, including temporary command
line overrides, without contacting Kubernetes.
Use the same override arguments for inspection, preview, and deployment:
atmos helm values monitoring -s plat-ue2-dev \
-f incident-values.yaml \
--set image.tag=2026.09.09
atmos helm diff monitoring -s plat-ue2-dev \
-f incident-values.yaml \
--set image.tag=2026.09.09
atmos helm apply monitoring -s plat-ue2-dev \
-f incident-values.yaml \
--set image.tag=2026.09.09
Atmos layers command-line value files and each supported --set variant over the component's
resolved values using Helm's normal parsing and precedence rules. That includes nested paths,
list indexes, typed values, string and literal handling, JSON input, and file-backed values.
See the native Helm command reference for
the complete override reference and the values command guide.
Have feedback? Open an issue or join the
Cloud Posse community Slack.
GITHUB_SERVER_URL and GITHUB_API_URL are the same two variables GitHub Actions already exports on both public github.com and a GitHub Enterprise Server runner, precisely so that scripts and CLIs don't need special-casing.
Atmos read those variables in a couple of places, but not consistently. The token allowlist that decides whether to attach a GitHub token to an outgoing request only recognized api.github.com, raw.githubusercontent.com, and uploads.github.com. Vendoring, remote imports, the CI provider, and the low-level GitHub API client each had their own github.com assumption baked in, hardcoded in a handful of different ways. On a GitHub Enterprise Server instance, that meant private-repo authentication, raw-content fetches, and CI metadata could silently fail or fall back to unauthenticated requests, depending on which code path happened to run.
Atmos now resolves GITHUB_SERVER_URL and GITHUB_API_URL from one place and honors that resolution everywhere it talks to your own repositories: the CI provider, imports and vendoring, release/tag/artifact lookups, the token host allowlist, and token injection for git operations. Point Atmos at your GitHub Enterprise Server instance and vendoring, remote imports, atmos git clone, and CI metadata all resolve against it, with no atmos.yaml changes required.
Toolchain installs are a deliberately separate concern. The public Aqua registry that backs atmos toolchain install lives on public github.com regardless of where your own repositories are hosted, so toolchain traffic does not follow GITHUB_SERVER_URL. Without that separation, pointing Atmos at your GitHub Enterprise Server instance would break every atmos toolchain install on a GitHub Enterprise Server runner, since your instance obviously doesn't mirror the Aqua registry. Toolchain traffic gets its own variables instead, which default to public github.com and only need to be touched if you run a corporate release proxy or mirror.
One shorthand stays github.com-only on purpose: writing github.com/org/repo (or bare org/repo) in an import, a vendor manifest, or an AI skill source can't be resolved against an arbitrary Enterprise Server host, because a bare hostname is indistinguishable from a relative path. On GitHub Enterprise Server, write the full URL instead — with one exception: AI skill sources also recognize the actual configured host without a scheme (github.example.com/org/repo), since a skill source is always meant to be a repository reference, never a local path. Imports and vendor manifests don't make that same assumption, so they need the explicit scheme there too (https://github.example.com/org/repo). atmos git clone has no shorthand form at all, on github.com or GitHub Enterprise Server alike — it always needs a full URI (HTTPS, SCP-style, or go-getter syntax).
Set the two standard variables to point Atmos at your instance:
export GITHUB_SERVER_URL=https://github.example.com
export GITHUB_API_URL=https://github.example.com/api/v3
If you run a corporate proxy or mirror in front of public GitHub releases for toolchain installs, point the toolchain at it separately:
export ATMOS_TOOLCHAIN_GITHUB_URL=https://releases.corp.example.com
export ATMOS_TOOLCHAIN_GITHUB_API_URL=https://releases.corp.example.com/api/v3
export ATMOS_TOOLCHAIN_AQUA_REGISTRY_URL=https://releases.corp.example.com/aqua-registry/main
Leave the toolchain variables unset and atmos toolchain install keeps installing tools from public github.com, exactly as before — even when GITHUB_SERVER_URL points at your own instance. See the environment variables reference for the complete list and defaults.
Running Atmos against GitHub Enterprise Server and hitting a spot that still assumes public github.com? Open an issue — the routing above covers the paths we could verify, but Enterprise Server deployments vary.
]]>!labels function now accepts a key to read a single
component label, with an optional fallback when that label is absent.
Individual labels are already accessible through Go templates, such as
{{ .metadata.labels.owner }}. The !labels function
previously returned only the full map and accepted no key or fallback argument.
Use !labels key [default] to retrieve a string
from the component’s resolved metadata labels.
An absent key uses the explicit default or produces an error if none was supplied.
Existing empty-string values are preserved. Bare !labels continues to return the full map.
components:
terraform:
vpc:
metadata:
labels:
cost-center: platform
vars:
cost_center: !labels cost-center
owner: !labels owner "Platform Team"
Here cost_center resolves to platform. If the resolved metadata has no owner label
after stack defaults and component inheritance, owner resolves to the explicit fallback,
Platform Team. An inherited owner label supplies its value instead.
Keys are literal, including dots, slashes, and hyphens. Quote fallback values containing spaces;
use "" when the fallback should be an empty string. Values reflect
stack defaults and component inheritance.
See the label lookup reference for full-map access and Go template equivalents.
Share your label lookup use cases in Atmos discussions.
]]>A component dependency previously meant that the target had to exist and be available. That is correct for core infrastructure, but too strict for optional integrations such as observability, auxiliary services, or environment-specific components. Teams had to duplicate manifests or maintain separate dependency lists just to handle those differences.
Component dependencies can now declare required: false:
dependencies:
components:
- name: observability
required: false
Required dependencies remain the default, preserving existing behavior. Optional dependencies are included normally when their target is present, enabled, and concrete. Missing, disabled, or abstract targets simply omit that edge. Invalid dependency configuration still fails instead of being hidden by optionality.
The required value can also be rendered from a template. Atmos applies the configured template delimiters before parsing the result as a boolean:
required: "[[ .vars.enable_monitoring ]]"
This allows one manifest to use environment-specific optionality without assuming the default {{ and }} delimiters.
Use required: false for a dependency that should participate in ordering when available but should not prevent the declaring component from running when unavailable:
components:
terraform:
application:
dependencies:
components:
- name: network
- name: monitoring
stack: "{{ .vars.environment }}-observability"
required: false
Omit required when the target must be present, enabled, and concrete. Optionality only suppresses missing, disabled, or abstract targets; malformed entries remain errors.
Try conditional dependencies in your stack manifests and share feedback through GitHub.
]]>The Version Tracker's template manager covers YAML by treating
a *.tmpl source as the source of truth and rendering it to a sibling output file — a good fit when
the whole file is generated, but overkill for a hand-maintained file that only has one or two managed
fields. The marker manager can annotate a line with a comment, but its rewrite is a plain token
substitution, not an assignment into structured YAML. Neither manager patches a single field in an
existing, hand-authored YAML document while leaving everything else — comments, anchors, key order —
untouched.
A new yaml file manager writes locked values directly into YAML files at configured field paths. It
reuses Atmos's own format-preserving YAML editor — the same engine behind atmos config set and
atmos stack set — so comments, anchors and aliases, and key order on untouched fields all survive
the edit.
version:
dependencies:
cli:
ecosystem: github/releases
datasource: github-releases
provider: github
package: cli/cli
desired: "~2"
files:
- manager: yaml
paths:
- charts/*/values.yaml
options:
set:
- path: version
from: cli
format: '{{ trimPrefix "v" .Version }}'
atmos version track apply rewrites the configured field from the lock, stripping the v prefix
GitHub tags carry via the optional format template; --check fails and lists any file that's out
of date, so CI can catch drift before it merges.
See the Version Files docs for the full path
syntax and the format field. Have feedback on this feature?
Open an issue or join the conversation in the
Cloud Posse community Slack.
v prefix — v1.228.0 — because that's the convention
both git tag and GitHub releases nudge toward. Package manifests, on the other hand, almost never
want that prefix: package.json, plugin manifests, and marketplace listings all expect bare
semver. Whenever a version comes from GitHub and needs to land in one of those files, something has
to strip the v first.
The Version Tracker's json file manager writes a locked
dependency's resolved value directly into a JSON field, byte-for-byte. For a dependency sourced
from github-releases or github-tags, that resolved value is the raw git tag — so a target field
that needed bare semver got v1.228.0 verbatim, with no way to reshape it before the write.
options.set entries in the json manager now accept an optional format: a small Go template
rendered against the resolved version, whose output replaces the verbatim value instead. Trimming a
v prefix is the common case, but any Sprig string function — trimSuffix, replace,
regexReplaceAll — is available too.
version:
files:
- manager: json
paths:
- package.json
options:
set:
- path: version
from: cli
format: '{{ trimPrefix "v" .Version }}'
Leaving format off keeps today's default: the resolved value is written verbatim, exactly as
before.
See the Version Files docs for the full
set syntax. Have feedback on this feature? Open an issue
or join the conversation in the Cloud Posse community Slack.
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.
Native Helm components in Atmos now let you declare that entire lifecycle as configuration — per operation — and inherit it the same way you inherit everything else in a stack.
Helm exposes the knobs — waiting, timeouts, atomic upgrades, cleanup-on-failure, history retention, waiting for Jobs, CRD handling, hook control — but only as flags on individual command invocations. That has two costs:
Native Helm components take a release policy with release-wide defaults and operation-specific overlays for install, upgrade, and delete. The whole tree deep-merges through your stack defaults, abstract/base components, and the concrete component — so a platform team can set org-wide defaults and individual components override only what they need. Explicit CLI flags still win at the highest precedence, so incident-time overrides remain a one-liner.
The policy covers the lifecycle end to end:
Invalid combinations fail early and clearly — asking for rollback on an install, or a field that doesn't apply to the selected operation, is rejected before anything runs rather than silently ignored.
Declare the lifecycle on the component. Release-wide settings sit at the top; install, upgrade, and delete refine them:
components:
helm:
my-app:
chart: "."
namespace: my-app
release:
timeout: 4m
wait:
strategy: watcher
history:
max: 10
install:
timeout: 10m # a cold-start install gets more room
on_failure: uninstall # don't leave a wedged half-install behind
upgrade:
on_failure: rollback # return to the last good revision
cleanup_on_failure: true
delete:
wait:
strategy: legacy
values:
replicaCount: 2
Atmos selects the operation for you and applies the matching overlay:
atmos helm apply my-app -s dev # install or upgrade, per the release's state
atmos helm apply my-app -s dev --dry-run # preview, no release persisted
atmos helm apply my-app -s dev --timeout 15m # incident-time override wins
Native Helm support is still experimental (Atmos prints a 🧪 notice when you use it), so the surface may evolve — but the release policy above is what you'll reach for to make deployments deterministic across environments.
For usage and configuration, see atmos helm apply.
The full contract lives in the native Helm release lifecycle PRD in the repo, and the atmos-helm skill documents day-to-day usage. If you run Helm through Atmos, try declaring a release policy on a component and tell us where the defaults or precedence surprised you — that feedback is what shapes the feature out of experimental.
The Component Updater (atmos vendor update --pull-request) already discovers component updates
and opens or refreshes a pull request for them, but it only spoke to GitHub. Projects hosted in
Azure DevOps Repos couldn't use the flag at all — every automated sync there still ended with
someone opening the PR by hand.
The ci.pull_request.provider field now accepts azuredevops alongside the existing github value. It
follows the same create-or-update contract: Atmos looks for an already-open pull request between
the same source and target branches first, updates that pull request's title and description in
place when one exists, and only opens a new one when none does — so re-running a vendor sync never
piles up duplicate PRs, regardless of which provider is configured.
Azure DevOps addresses a repository with three parts — organization, project, and repository — rather than GitHub's owner/repository pair, so those are explicit config fields instead of being derived from the Git remote:
vendor:
ci:
pull_request:
provider: azuredevops
organization: my-org
project: my-project
repository: my-repo
branch_prefix: atmos/component-updater
title: "chore(components): update {{ .scope.name }}"
labels: [component-update]
reviewers: [alice, bob]
Authenticate with a personal access token in AZURE_DEVOPS_EXT_PAT, granted Code (Read & Write)
on the target project, then run the update exactly as before:
atmos vendor update --pull-request
Labels and reviewers apply the same way they do on GitHub. Assignees don't — Azure DevOps pull
requests have no assignee concept, so setting ci.pull_request.assignees with
provider: azuredevops fails loudly instead of silently dropping the configuration; use
reviewers there instead.
Questions about the Azure DevOps provider, or requests for another forge, are welcome in the Atmos GitHub repository and the community Slack.
]]>default.
That namespace may not exist. Native Helm creates it for you automatically, so a release deploys in a single operation instead of requiring a separate command, component, or workflow to create the namespace first.
Sometimes, though, the deployment should not be creating namespaces at all.
A Helm chart does not always specify the namespace where its resources should be installed. Atmos solves this by installing the release into the namespace configured for the component:
components:
helm:
backend-api:
chart: "backend-api"
namespace: backend-api
This keeps the release out of the default namespace, and native Helm creates the namespace
automatically when it is missing, so the deployment is self-contained.
Automatic creation is not always wanted. When a platform team owns the namespace along with its
labels, quotas, and NetworkPolicies, the release should not create it. And when the deploy identity
is scoped to a single namespace and cannot create namespaces, the forced creation fails with a 403,
even when the namespace already exists.
Native Helm components now support create_namespace. It defaults to true, so the namespace is
created automatically as before. Set it to false to install into a pre-existing namespace instead:
components:
helm:
backend-api:
chart: "backend-api"
namespace: backend-api
create_namespace: false
values:
replicaCount: 1
The release then deploys into the namespace that already exists, with no cluster-level permission to create namespaces:
atmos helm apply backend-api -s plat-ue2-dev
Left at its default, Helm creates the namespace when it is missing. Set to false, Helm installs
into the namespace that is already there.
Keep create_namespace enabled (the default) when the Helm deployment should manage its own namespace
and the deploying identity has permission to create namespaces.
Set it to false when namespaces are managed separately, for example when a platform component is
responsible for namespace labels, quotas, NetworkPolicies, or other guardrails, or when the deploy
identity is scoped to a single namespace.
For usage and configuration, see atmos helm apply.
Atmos is open source and we'd love your feedback. Join the conversation in the Atmos community Slack or open an issue on GitHub.
]]>A version in .tool-versions pins what you asked for. It does not pin what Atmos actually
installed. Every atmos toolchain install command resolves that version against the live registry
again. The exact download URL, checksum, and platform artifact are not fixed anywhere. Only the
version number is fixed.
Toolchain installs now write a lockfile by default. You do not need to configure anything. Run
atmos toolchain install. Atmos records the exact resolved version, download URL, checksum, and
size for your platform. Installs skip a tool that already exists on disk, so an already-installed
tool will not get a lockfile entry until you run atmos toolchain lock (or reinstall it with
atmos toolchain install --reinstall). Once every tool has an entry, the next install resolves
against the lockfile instead of asking the registry again, on your machine, a teammate's, or in
CI. Reproducibility holds per platform: everyone on an operating system and architecture with a
matching lock entry gets the same artifact, byte for byte.
If a project's atmos.yaml pins an edition dated before this change, the project keeps the old
opt-in behavior. Nothing changes for a project that relied on the previous default. New and
unpinned projects get the lockfile from the start.
You do not need to opt in. Install as usual:
$ atmos toolchain install
Commit the resulting toolchain.lock.yaml file next to .tool-versions. If some of those tools
were already installed before you ran this, run atmos toolchain lock too -- atmos toolchain install won't touch a tool it finds already on disk, so it can leave that tool's entry missing.
Once every tool has an entry, every install resolves the exact pinned artifact for that platform.
This applies on your machine, a teammate's machine, and a CI runner. Atmos does not resolve the
version against the registry again.
The atmos toolchain command is still experimental. Its interface may change. The reproducibility
does not depend on that.
If you already use the toolchain, check whether toolchain.lock.yaml has an entry for every tool
in .tool-versions. Run atmos toolchain lock to fill in any atmos toolchain install skipped
because they were already installed, then commit the lockfile. If your installs still do not
reproduce the same way across machines with matching lock entries, open an
issue. That is exactly the gap this fix closes.
retry: block on either was silently inert. Now all four component types share the same retry engine.
The same class of error can just as easily hit helmfile sync pulling a chart, packer build downloading a plugin, or ansible-playbook reaching a remote inventory. None of those got the same protection until now.
That gap got harder to miss once stacks could set retry once for the whole stack. A stack-root retry: block reads as "every component here recovers from this." But that was only true for the Terraform components.
retry: now works the same way for every component type that shells out to a binary. Terraform, Helmfile, Packer, and Ansible all share the same retry engine. It captures the subprocess output, matches it against your conditions regex patterns, and retries with backoff only on a match.
components:
helmfile:
myapp:
retry:
max_attempts: 5
backoff_strategy: exponential
initial_delay: 2s
conditions:
- /Bad Gateway/
- /connection reset/
packer:
ami:
retry:
max_attempts: 3
conditions:
- /rate limit/
Nothing changes for existing Terraform retry configuration. This change only adds new coverage. A real failure still fails immediately. Examples include a bad Helmfile release, a Packer template error, or a broken playbook. Only output that matches your conditions triggers a retry.
Add retry: to any Helmfile, Packer, or Ansible component the same way you would for Terraform. See the component retry docs for the full field reference. A stack-root retry: block now protects every supported component in the stack.
Native Kubernetes and native Helm components don't shell out to a binary. They call Go SDKs directly. So they aren't covered by this change yet. That gap is tracked as a follow-up.
Open a discussion in the Atmos repo. Let us know if you hit a transient failure pattern in Helmfile, Packer, or Ansible that conditions doesn't catch cleanly.
scaffold.yaml and a handful of files.
Both atmos scaffold generate and atmos init could already pull templates from git, HTTPS, and
S3 sources, but nothing else. A team standardizing on OCI for internal distribution —
components, container images, Helm charts — had no way to publish a scaffold template the same
way. Templates were the one artifact type still forced onto a separate channel.
Both commands now accept an oci:// source directly, pulled through the same client Atmos
already uses for atmos vendor pull and just-in-time component provisioning. Authentication
follows the identical precedence: Docker credentials from docker login, then
ATMOS_GITHUB_TOKEN for ghcr.io, then anonymous — nothing new to configure if OCI sources are
already working elsewhere in the project.
Point either command at an OCI reference the same way you would a git URL:
atmos scaffold generate oci://ghcr.io/example/templates:v1.0.0 ./components/terraform/vpc
atmos init oci://ghcr.io/example/templates:v1.0.0 ./my-project
A version lives directly in the reference (:v1.0.0), the same way an OCI vendor source is
pinned — there's no separate --ref flag to learn for this case, since that flag only ever
applied to git sources. --update's three-way merge, --git/--no-git, and --base-ref all
work exactly as they already do for every other source type: the merge base always comes from
the generated project's own git history, never from re-fetching the template, so switching a
template to OCI changes nothing about how updates behave.
A scaffold.templates entry in atmos.yaml can point at an oci://... source too, right
alongside existing git-hosted entries.
Open an issue with feedback, or let us know what registry you're publishing scaffold templates to.
]]>retry: block onto each component, wire up a shared abstract base component just to hold it, or set up a mixin. Now you can define the policy once at the stack level, and every component in that stack inherits it automatically.
Component retry matches transient failures against conditions regex patterns and retries with backoff. That mechanism works well for one component. Restructuring unrelated components to share an abstract base just so they inherit a policy, or setting up a mixin file with overrides.retry and importing it everywhere, gets you there too — but none of those match the real goal: every component in this stack should recover the same way, without extra plumbing.
Stacks now accept a top-level retry: block. This works the same way as the existing top-level vars, metadata, and hooks blocks. Set it once at the root of a stack manifest. Every supported component in that stack then picks it up:
retry:
max_attempts: 5
backoff_strategy: exponential
initial_delay: 2s
max_delay: 30s
conditions:
- /Bad Gateway/
- /GOAWAY/
- /could not query provider registry/
components:
terraform:
vpc:
# ...
transit-gateway:
# ...
A concrete component's retry: overrides stack and abstract-base values for keys it sets. Missing keys inherit from lower-precedence layers. The full precedence order, lowest to highest, is: stack-level default → abstract base component → concrete component → overrides.retry.
Add retry: to the root of any stack manifest, alongside vars: and components:. You need no mixin file, no shared base component, and no per-component copies:
retry:
max_attempts: 3
conditions:
- /Bad Gateway/
- /connection reset/
components:
terraform:
vpc:
vars:
name: vpc
rds:
vars:
name: rds
Both vpc and rds retry on the same conditions without either one declaring retry: itself. If one component needs a different policy, set retry: directly on that component. Its values override lower-precedence layers unless overrides.retry sets the same keys. Missing keys continue through the precedence chain.
The mixin pattern from the component retry docs is still the right tool for a policy that applies to only part of a stack.
Open a discussion in the Atmos repo or post in the SweetOps Slack. Let us know if you hit a retry scenario that the current scoping (stack, base component, component, overrides) doesn't cover well.
]]>dev or prod just to avoid maintaining
a separate label mapping, and people have to mentally translate those into what they actually
mean. The only real fix is letting choices adapt to prior answers — and letting them look nicer
than the underlying values.
In a scaffold template, select and multiselect fields normally take their choices from
options:, a static list fixed at authoring time. That's fine when the choices really are fixed,
but two situations don't fit:
dev, staging,
production) via a multiselect; a later select field should default to offering just those chosen
environments — not the entire list the template supports.dev/staging/production) that generated files and conditions rely on.
Previously this meant either showing raw values on screen, or hand-maintaining a separate label
mapping elsewhere in the template.A static options: list can't handle either case — it's decided once and never revisited.
A field's options: can now be computed dynamically, using the same answers.-dot-path syntax
and Go-template conventions already available elsewhere in scaffold templates:
spec:
fields:
- name: envs
type: multiselect
options: [dev, staging, prod]
- name: default_env
type: select
options: answers.envs
If someone picks staging and prod, default_env will only offer those two — dev is
excluded. The source field doesn't need to be a multiselect; a plain text input works too,
combined with a template expression that converts it to a list:
spec:
fields:
- name: csv_owners
type: input
default: "platform-team,security-team"
- name: primary_owner
type: select
options: '{{ splitList "," answers.csv_owners }}'
Both forms resolve options: based on whatever was supplied for the earlier field, whether
answers come from an interactive prompt or are passed in non-interactively.
The same options: field also accepts a list of label/value pairs, so what's displayed and what's
stored can differ:
spec:
fields:
- name: envs
type: multiselect
options:
- label: Development
value: dev
- label: Staging
value: staging
- label: Production
value: prod
- name: default_env
type: select
options: answers.envs
Here, envs displays "Development," "Staging," and "Production" while storing
dev/staging/prod everywhere they're actually needed — generated files, when:
conditions, and other fields' options:. Since default_env pulls its choices dynamically from
envs, it inherits those same friendly labels for whatever was picked, rather than falling back
to raw stored values.
Point options: at answers.<field> (or a template expression) on any select/multiselect
field to source its choices from an earlier answer instead of a fixed list, and switch a plain
string list to label/value object entries wherever the stored value and the display text should
differ. See the atmos scaffold generate docs for the full
field reference.
Open an issue with feedback, or share templates that put dynamic options to use in your own projects.
]]>cloudposse/github-action-atmos-* actions. Those actions were the
recommendation for years. They're no longer where investment goes — Native CI replaced them
with a more capable, end-to-end-tested integration. Plenty of teams don't know it exists, let alone
that the actions they're on are effectively on life support.
Even teams already on Native CI run into a quieter version of the same problem: a setting that
doesn't take effect looks exactly like one that does. Maybe ci.enabled is set on one profile but
not another, or an Atmos Pro workspace never got configured in the first place — nothing errors
either way. The pipeline finishes green, and the first symptom is a status check or an upload
that isn't there, discovered days later.
Confirming any of it meant checking for side effects after the fact: did the expected status check show up, did the drift upload happen, is this pipeline still wired to a marketplace action. None of that was visible from the CI run itself, so a misconfigured pipeline was only ever discovered because something else broke first.
Atmos now prints a short status banner the moment it detects it's running inside a CI provider: the version, whether Native CI mode is on or off, and whether Atmos Pro is configured. If it's invoked from one of the older marketplace actions, it also warns directly in the run log and points at migrating to Native CI — which has more features, gets tested end-to-end as part of the Atmos core test suite, and is where all future investment is going. Teams still on the legacy actions should treat this as a prompt to move now, not eventually.
▶ Atmos version 1.228.0 linux/amd64
✓ Atmos CI is enabled; learn more at https://atmos.tools/ci
✗ Atmos Pro is disabled; learn more at https://atmos.tools/pro
⚠ Detected legacy action cloudposse/github-action-atmos-terraform-plan; migrate to Native CI for better performance — learn more at https://atmos.tools/ci
There's nothing to configure — the banner appears automatically at the start of every atmos
command you run inside a detected CI provider, and it's a complete no-op on a local machine. It
reads the same ci and settings.pro
configuration you already have, so what it reports always matches your actual setup.
Atmos is open source and we'd love your feedback. Join the conversation in the Cloud Posse community or open an issue on GitHub.
]]> We've added an optional streaming UI mode for Terraform commands (plan, apply, deploy, init, destroy) that displays real-time resource status with visual indicators, progress tracking, interactive confirmations, and condensed completion summaries.
During execution:
⠋ apply plat-ue2-dev/vpc Creating aws_security_group.default (5.2s) ████████░░░░ 2/5
✓ Created aws_vpc.main (2.1s)
✓ Created aws_subnet.public[0] (1.3s)
The inline progress bar shows the current activity, elapsed time, and completion status on a single line.
On completion:
✓ Apply plat-ue2-dev/vpc completed (15.2s)
On error:
✗ Apply plat-ue2-dev/vpc failed: 1 error (12.1s)
Error: aws_instance.web[0]: InvalidAMIID.NotFound
The streaming UI shows a visual dependency tree of resources being changed, with color-coded indicators:
plat-ue2-dev/myapp
● ├── aws_s3_object.file
│ content_type "text/html" → "text/plain"
│ source "hello.html" → "hello.txt"
● └── aws_instance.new
ami (none) → "ami-12345"
instance_type (none) → "t3.micro"
Resources are marked with colored dots (●): green for create, yellow for update, red for delete. Attribute changes show old → new values in a two-column layout.
For multi-line values (like file content), each line is shown with add/remove indicators:
● └── aws_s3_object.weather
content
- Current weather: Sunny, 72°F
- Humidity: 45%
+ Current weather: Cloudy, 65°F
+ Humidity: 80%
+ Wind: 15 mph NW
Before applying changes, the UI displays a confirmation prompt:
Do you want to apply these changes?
> Yes No
The confirmation is styled with the Atmos theme and includes proper margins for visual clarity.
Terraform's default output is overwhelming, especially for new users. A simple infrastructure change can produce hundreds of lines containing:
This creates several problems:
The streaming UI solves these by showing only what matters: which resources are changing, what attributes are affected, and their current status.
# Enable for a single command
atmos terraform plan vpc -s dev --ui
# Disable explicitly when enabled by config
atmos terraform apply vpc -s prod --ui=false
Add to your atmos.yaml:
components:
terraform:
ui:
enabled: true
Or set it directly from the CLI without hand-editing YAML:
atmos config set components.terraform.ui.enabled true
With this on, the UI turns on automatically whenever a real terminal is detected — no --ui flag needed — and still auto-disables in the same piped/CI cases described below. Use --ui=false per-command to override it off.
export ATMOS_TERRAFORM_UI=true
atmos terraform plan vpc -s dev
The streaming UI automatically falls back to standard output when:
CI=true environment variable is setThis means your existing scripts and CI pipelines continue to work without modification.
| Command | Streaming UI |
|---|---|
plan | ✓ |
apply | ✓ |
deploy | ✓ |
init | ✓ |
destroy | ✓ |
refresh | ✗ (no -json streaming support in Terraform's refresh) |
The implementation uses Terraform's machine-readable JSON output format (-json flag):
-json to terraform commands when UI mode is enabledhuh libraryplan -detailed-exitcode)This is a pure Go implementation using charmbracelet/bubbletea and huh, requiring no external binaries or CGO.
We'd love your feedback on the streaming UI. Try it out and let us know how it works for your workflow. Open an issue on GitHub or join us in Slack.
]]>