148 posts tagged with "Feature"

Atmos lifecycle hooks can now run an ordered list of steps with kind: steps. Use it when one lifecycle event needs sequencing but the orchestration should stay local to the component being operated on.

The new atmos list dependencies command renders the dependency relationships between your components as a tree — showing, for every component, both what it depends on and what depends on it. It reads dependencies.components (preferred) and the legacy settings.depends_on, so the output stays consistent with atmos describe dependents.

Atmos workflows can now start long-running container services in the background, wait for them to become healthy, and tear them down automatically. Bring up an emulator, database, or registry with background: true, gate the next step on its container health check, and stop it with a cancel step — no shell scripts, no background jobs, no orphaned containers.

Terraform's native testing framework (*.tftest.hcl) is great — until you hit a run block with command = apply. Those blocks create real infrastructure, so running them means a cloud account, credentials, and spend. Atmos now lets you point terraform test at a local emulator, so the same apply-backed tests run for free and hermetically on your laptop or in CI.

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 hooks can now run any workflow step type. A new kind: step hook bridges the component lifecycle (before/after terraform plan, apply, deploy, init) to the same step registry that powers workflows and custom commands — so a container, toast, log, markdown, or http step you already use elsewhere runs identically as a hook.

A big challenge for infrastructure developers is how hard it is to iterate locally. Every terraform apply needs a real cloud account, costs real money, and touches a live environment. And in many enterprises developers don't have permission to the cloud at all, so they can't iterate locally even when they want to. Atmos emulators help with this: long-running, containerized stand-ins for AWS, GCP, Azure, Kubernetes, Vault, and an OCI registry that you provision as ordinary Atmos components — so you can run the full Atmos workflow (auth, secrets, vendoring, toolchain, and terraform apply) on your laptop, with no cloud account and no credentials.

Atmos native CI now supports the full plan-then-deploy workflow with planfiles: atmos terraform plan --ci uploads the planfile to durable storage, and atmos terraform deploy --ci automatically downloads it, generates a fresh plan, reconciles it against the reviewed plan, and applies the fresh plan — only if they match, failing on drift by default.

Workflows and custom commands now support a native http step type that performs an HTTP request — any verb, query-string parameters, headers, and a request body (raw or form/JSON) — with per-attempt timeouts and retries that compose with the existing retry: policy. No more shelling out to curl. (Prefer type: webhook? It's an accepted alias.)

Atmos workflows can now run independent work concurrently with first-class parallel and matrix control steps. Add dependency-aware fan-out, readable grouped or live-prefixed output, and explicit failure behavior directly to your workflow YAML.

Workflows now have a say step type that speaks a message out loud using text-to-speech — an audible cue for when a long-running workflow finishes or needs your attention, even after you've switched to another window. When no speech engine is available (or you're in CI), it degrades gracefully and prints the message instead, so the same workflow works everywhere.

Component metadata now supports an optional description field, so you can document what a component is for right next to its configuration. Atmos preserves description as component metadata — it does not change how the component is processed, planned, or applied.

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 now treats Kubernetes as a first-class component type. Define Kubernetes objects — inline manifests, files, directories, or Kustomize overlays — in your stack configuration, then render, diff, apply, and delete them through the Kubernetes Go SDK with server-side apply. No kubectl or kustomize binary required. And because Atmos owns rendering, 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.

Custom command and workflow shell steps now support docker-style tty and interactive fields — plus a new exec step type that replaces the Atmos process entirely — so commands like aws ssm start-session, ssh, psql, and vim can take over the terminal properly, with Ctrl-C going to the session instead of killing Atmos.

Atmos now treats Git as a foundational platform capability — on par with Toolchain, Auth, and Hooks — built to enable GitOps workflows where you need to commit artifacts to a source of truth: deployment repos consumed by Argo CD or Flux, provider lock files, rendered manifests. Define managed repositories once in atmos.yaml, then clone, inspect, diff, commit, and push them through a new atmos git command group, or publish generated artifacts automatically on lifecycle events with the new git hook kind.

Atmos now supports using dotenv files directly with the !include YAML function.

Atmos now supports the !append YAML function, which adds items to an inherited list during stack merging instead of replacing it — giving you per-field control over list merging without changing any global setting.

Atmos now plugs into your CI provider's native cache so your infrastructure pipelines run faster — automatically. Flip one setting and Atmos caches the toolchain it installs, the OpenTofu and Terraform providers your stacks download, the modules and vendored components they pull, remote stack imports, and everything else it would otherwise re-fetch from the internet on every run. Cold CI jobs go warm: the same pipeline stops waiting on the same downloads, and stops going red when an upstream registry has a bad minute.

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 now supports the !unset YAML function, which removes a key entirely from a stack configuration during inheritance and merging. It's the clean way to drop a value that a parent stack or import defined, without resorting to workarounds.

Atmos now has first-class secrets management: you declare the secrets each component depends on, provision their values per environment, and reference them at runtime with a single YAML function.

Atmos now supports before-terraform-init and after-terraform-init lifecycle hooks, and --skip-hooks is finally honored for before- hooks across plan, apply, and deploy.

--use-version now accepts a ref: prefix, so you can run the latest build of any branch or tag — like ref:main — without looking up a commit SHA.

Atmos adds a new template function, atmos.Resolve, that evaluates any Atmos YAML function — like !git.repository, !exec, !store, or !terraform.output — at template-render time. This lets you compose a YAML function's result with other strings and template variables in a single value.

Atmos now exposes Git repository metadata through dedicated YAML functions: !git.repository, !git.owner, !git.name, !git.host, and !git.url. These join the existing !git.root, !git.sha, !git.branch, and !git.ref functions.

Atmos Terraform bulk commands now run through a dependency graph, with optional bounded concurrency for plans and deterministic ordering for multi-component runs.

Atmos now renders Go templates in stack import paths using settings, vars, and env defined by earlier imports in the same manifest. You can pin a remote import's Git ?ref= — or pick a local catalog — from one variable defined once.

Atmos now includes 25+ interactive step types for both workflows and custom commands. Build interactive CLI wizards, collect user input, display rich output, and control execution flow—all directly in your atmos.yaml without external scripts.

Atmos now supports authenticated pulls from public.ecr.aws via the new aws/ecr-public integration kind, eliminating Docker rate limits on public ECR images.

Fetching private Terraform modules, Atmos source: components, and vendored artifacts in CI has always meant handing a long-lived, over-privileged GitHub credential to your pipeline — a PAT, a machine user, or a deploy key, sitting in a CI secret. Atmos Pro STS replaces that with just-in-time, least-privilege, short-lived GitHub tokens that are minted at the start of a run and revoked at the end — with zero .tf changes.

Atmos now includes core Git YAML functions for resolving repository metadata directly in stack and config processing: !git.root, !git.sha, !git.branch, and !git.ref.

Every page on atmos.tools is now available as raw Markdown. Append .md to any docs URL and you'll get a clean, MDX-component-aware Markdown file ready to paste into an LLM, a ticket, or another doc.

The atmos aws security analyze command is the native Atmos command for turning AWS security findings into infrastructure-aware remediation guidance. It reads findings from AWS Security Hub and Amazon Inspector, including Security Hub product findings from services such as AWS Config, GuardDuty, Macie, and IAM Access Analyzer, then uses Atmos component tags and mapping heuristics to connect affected resources back to the stacks and components that manage them.

Those mappings make findings more actionable: instead of stopping at an AWS resource ARN, Atmos can show the owning stack, component path, severity, source service, and remediation context. With new SARIF 2.1.0 and OCSF 1.4.0 output, those findings can now flow into code scanning, SIEM, governance, risk, and compliance workflows without a translation layer.

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.

atmos auth login now performs one browser interaction per AWS SSO portal, no matter how many aws/iam-identity-center providers in your atmos.yaml point at it. Cached tokens also refresh silently for the full ~8-hour portal session window — no more re-prompt every hour.

Provider downloads fail. Registries return 502s. State backends time out. None of that is your code's fault, but when it happens during atmos terraform plan in CI, the only recovery has always been a manual re-run. With this release you can configure per-component retry so transient failures recover automatically — without retrying real Terraform errors.

Claude Code, OpenAI Codex CLI, and Google Gemini CLI all speak MCP, but each wants its own config format, its own credentials flow, and its own idea of where binaries live. This post shows how to centralize all of it — server configuration, AWS credentials, and toolchain version — in one atmos.yaml that every AI coding assistant uses unchanged.

Atmos Auth is the only place AWS credentials live; each MCP server is automatically wrapped with the right identity for the question it'll answer (billing → payer account, CloudTrail → audit, IAM → root, workload queries → dev/rpg/staging). One atmos auth login covers them all — no API keys in CLI configs, no AWS_PROFILE swapping between prompts. The server set spans the Atmos MCP server for project stacks, the AWS MCP server suite for live cloud queries, and the Atmos Pro MCP server for drift, deployment, and audit history. The Atmos toolchain pins binaries so every assistant runs the same binary. See the example: examples/mcp-for-ai-coding-assistants/.

Atmos toolchain installs now verify downloaded packages before extraction when registry metadata provides checksums, signatures, or attestations.

Every atmos list subcommand that processes stack manifests now accepts --skip <yaml-function> and the matching ATMOS_SKIP env var, mirroring the surface already exposed by atmos describe affected, atmos describe component, and atmos describe stacks. Use it to bypass a single YAML function while leaving the rest of YAML function processing — including !template — fully enabled.

atmos describe affected --upload now works under GITHUB_EVENT_NAME=merge_group, so Atmos Pro can correctly conclude check runs on the synthetic commits GitHub creates when a PR enters a merge queue. To control what runs on those synthetic commits, declare a new settings.pro.merge_group.checks_requested.workflows block in your stack config and point it at the workflow you want the queue to dispatch (in most cases, the same plan workflow you already use for pull_request.synchronize).

Atmos now supports dependencies.files and dependencies.folders as first-class sibling keys for declaring path-based dependencies. Use them to mark a component as affected when shared files, generated assets, schemas, Lambda source, or other external paths change.

When an --identity can't be resolved in the currently loaded Atmos config, Atmos now checks whether the identity is defined in another profile — and either prompts you to switch or hints at the exact command to re-run. The same release also adds profiles.default so you can pin a default profile in atmos.yaml.

atmos list instances now supports --format=matrix, producing GitHub Actions-compatible JSON for driving parallel CI/CD jobs — the same format already available in atmos describe affected.

You can now preserve / in component names when Atmos auto-generates backend key prefixes — keeping your state bucket organized to match your component directory structure.

Atmos now supports server-side commits via the Atmos Pro GitHub App. The new atmos pro commit command sends your changes to Atmos Pro, which creates the commit using its GitHub App installation — ensuring commits trigger CI workflows.

Setting up Atmos Pro in a repository used to mean manually creating GitHub Actions workflows, authentication profiles, and stack configuration. The new atmos pro install command scaffolds everything in seconds.

Atmos can now pull security findings from AWS Security Hub, map them to the exact Atmos components and stacks that manage the affected resources, and generate structured remediation reports — all from a single command.

Atmos AI now supports CLI providers — invoke your locally installed Claude Code, OpenAI Codex, or Gemini CLI as AI backends. No API keys needed. Just use your existing subscription.

Atmos can now connect to external MCP servers and use their tools directly in AI conversations. Configure any MCP server in atmos.yaml, and its tools appear alongside native Atmos tools in atmos ai chat, atmos ai ask, and atmos ai exec — no custom integration code needed.

Atmos now supports ambient AWS credentials from IRSA, EC2 instance profiles, and ECS task roles via two new identity kinds: ambient (generic passthrough) and aws/ambient (AWS SDK default credential chain).

Atmos now automatically chunks large payloads when uploading affected stacks and instances to Atmos Pro, eliminating HTTP 413 errors for large infrastructure repositories.

Atmos now supports browser-based OAuth2 authentication as an automatic fallback for aws/user identities. When no static credentials or keychain entries are available, Atmos opens your browser for interactive sign-in using the same AWS console flow you already know.

The atmos describe affected command now auto-detects the base commit in CI environments, eliminating the need for verbose flag wiring in your workflows.

Atmos now has a dedicated space for community-contributed recipes called Gists — creative patterns showing how to combine Atmos features in ways that go beyond standard documentation.

For teams using Atmos Pro, the Atmos CLI now pushes instance status directly to the Atmos Pro dashboard the moment a plan or apply completes. The dashboard reflects the real state of every component within seconds — no polling, no waiting for webhooks, no stale data.

When you see complex bash scripts and conditional logic in GitHub Actions workflows, that's a signal: the underlying tool wasn't designed for CI. Atmos now has built-in CI integration that makes the same command work identically locally and in CI—no wrapper scripts, no extra actions, no hidden complexity.

Atmos now supports a new dependencies.components format for declaring explicit component dependencies with support for cross-type dependencies, file/folder watching, and stack templates.

Atmos now supports native EKS kubeconfig authentication through the integrations system. When you authenticate with an identity, Atmos automatically generates kubeconfig entries for linked EKS clusters, giving you seamless kubectl access without requiring the AWS CLI.

Atmos identities now support required: true, enabling automatic authentication of multiple identities before Terraform runs — without prompting.

Add --ai to any Atmos command and get instant AI-powered analysis of the output. Successful plans get summarized, errors get explained with step-by-step fixes — zero workflow changes required.

Atmos now supports a global templates.settings.ignore_missing_template_values option in atmos.yaml, eliminating the need to set ignore_missing_template_values: true on every individual catalog import.

We're excited to introduce Atmos AI, an intelligent assistant built directly into Atmos CLI that understands your infrastructure-as-code like no other AI assistant can.

Unlike general-purpose AI coding assistants, Atmos AI has deep, native understanding of Atmos stacks, components, inheritance patterns, and infrastructure workflows. It's not just an AI that knows about code—it's an AI that truly understands your infrastructure.

With support for 7 AI providers (including local/offline Ollama), persistent sessions with full conversation memory, tool execution with granular permissions and persistent permission cache, specialized skills for specific tasks, and seamless IDE integration via MCP—Atmos AI brings the productivity patterns of industry-leading AI systems to infrastructure management.

We're excited to introduce Atmos LSP, bringing IDE-quality features directly to your infrastructure configuration workflow—no context switching, no manual validation, no documentation hunting.

Atmos LSP provides comprehensive Language Server Protocol integration that transforms how you write and validate Atmos configurations. Get instant feedback on errors, autocomplete for Atmos keywords, hover documentation without leaving your editor, and seamless integration with external language servers for YAML and Terraform validation.

With support for 13+ editors (VS Code, Neovim, Zed, Cursor, Emacs, and more), multiple transport protocols, and deep AI integration—writing infrastructure configuration now feels like writing code in a modern IDE.

Vendor targets now accept optional version overrides, enabling multiple versions of the same component from a single source entry.

Atmos now supports a ttl field on component source configuration to control how long cached JIT-vendored sources are reused before automatically re-pulling from the remote. This is especially useful when working with floating refs like branch names during active development.

Atmos now ships 21 agent skills that give AI coding assistants deep knowledge of Atmos conventions, stack configuration, Terraform orchestration, authentication, validation, and more. Skills build on two open standards -- AGENTS.md and Agent Skills -- and work across Claude Code, OpenAI Codex, Gemini CLI, Cursor, Windsurf, GitHub Copilot, and other AI tools.

Access the AWS Organization ID directly in stack configuration with the new !aws.organization_id YAML function.

Atmos stores now support identity-based authentication. You can configure stores to authenticate using the same named identities from atmos auth instead of relying on default credential chains.

Test features from any Atmos pull request or commit SHA without compiling from source or manually downloading artifacts.

Atmos now automatically detects components and stacks that have been deleted in your current branch compared to the target branch. This enables CI/CD pipelines to trigger terraform destroy workflows for removed infrastructure.

Atmos now supports first-class Google Cloud authentication alongside AWS and Azure, with provider-scoped file isolation and a unified auth experience.

Atmos now supports credential realm isolation, preventing collisions when engineers work with multiple customer repositories using identical identity names.

Workflows now support environment variables at both workflow and step levels with hierarchical merging.

Atmos now supports Ansible as a first-class component type, enabling unified orchestration of infrastructure provisioning (Terraform) and configuration management (Ansible) from the same stack manifests.

Atmos now supports importing stack configurations from remote URLs. Reference shared configurations from GitHub, S3, GCS, or any HTTP endpoint directly in your stack files.

Atmos now supports intelligent version-aware JIT (Just-In-Time) source provisioning with automatic re-provisioning on version changes and TTL-based cleanup for stale workdirs.

Locals now support YAML functions like !env, !exec, !store, !terraform.state, and !terraform.output.

Atmos now includes a source list command to display components with source configuration. Both --stack and [component] arguments are optional, allowing flexible filtering across your infrastructure.

The atmos auth env command now supports --format=github for direct output to $GITHUB_ENV, eliminating shell pipelines in CI workflows.

Atmos now supports a dedicated github output format for atmos terraform output, making it easier than ever to pass Terraform outputs between GitHub Actions steps.

Atmos now supports directory-based Packer templates by default. Instead of requiring a single HCL template file, you can organize your Packer configurations across multiple files following HashiCorp's recommended patterns. Atmos automatically passes the component directory to Packer, which loads all *.pkr.hcl files.

Provably safe secrets masking with custom patterns, comprehensive output coverage, and configurable replacement strings.

File generation now features interactive component and stack selection, plus cross-provisioner support for helmfile and packer. Run atmos terraform generate files without arguments and get an intuitive selector.

New query syntax for atmos list components and support for installing multiple tools at once with atmos toolchain install.

Finding information in documentation shouldn't require knowing the exact terminology or page structure. With Ask AI, you can now ask natural language questions about Atmos and get intelligent, contextual answers—powered by Algolia DocSearch v4 and ChatGPT.

Atmos now provides granular control over experimental features with the new settings.experimental configuration option—giving teams the flexibility to explore new capabilities safely while maintaining stability in production environments.

Atmos now enforces a single canonical identity per stack and supports zero-config stack naming using filenames. These changes make Atmos easier for newcomers while providing explicit control for advanced users.

Atmos now includes native toolchain management that seamlessly integrates with the Aqua registry ecosystem — giving you access to hundreds of pre-configured CLI tools without the overhead of external tool managers.

We're sharing the Atmos Product Roadmap—a transparent view of where we've been, where we're headed, and what's coming next. Infrastructure teams evaluating Atmos often ask "What's the long-term vision?" The roadmap answers that question openly.

Atmos custom commands can now define their own component types beyond terraform, helmfile, and packer. Use Atmos's stack configuration system with any tool: Ansible, Kubernetes manifests, shell scripts, CDK, and more.

Custom commands now support structured task syntax with per-step configuration including timeouts, retry logic, working directories, and authentication identities.

Atmos now supports Azure OIDC/Workload Identity Federation for secure, secretless authentication in CI/CD pipelines.

Atmos now supports automatic retry with exponential backoff for vendoring and source operations. This makes component downloads more resilient to transient network failures, connection resets, and GitHub API rate limits.

The atmos terraform output command now supports a --format flag, making it easy to export Terraform outputs in various formats for use in CI/CD workflows, scripts, and configuration files.

Atmos now supports automatic version switching, making it easy to pin projects to specific Atmos versions and ensure consistency across teams.

Atmos now supports declarative file generation for Terraform components via the new generate section in stack configuration.

We're introducing file-scoped locals to Atmos stack configurations. Inspired by Terraform and Terragrunt, locals let you define temporary variables within a single file, reducing repetition and making your configurations more readable and maintainable.

Atmos now supports the !literal YAML function, which preserves values exactly as written without any template processing. This solves a common pain point when passing template syntax to downstream tools like Terraform, Helm, or ArgoCD.

The --all flag now executes Terraform components in dependency order. Run atmos terraform apply --all -s ue2-dev and components are automatically processed based on their depends_on relationships.

Atmos now automatically caches Terraform providers across all components, dramatically reducing terraform init times and network bandwidth. This feature is enabled by default with zero configuration required.

You can now pin Terraform and provider versions directly in your stack configuration. Atmos generates terraform_override.tf.json files with required_version and required_providers blocks, giving you centralized control over infrastructure versioning.

Atmos now supports just-in-time (JIT) vendoring of components directly from stack configuration using the top-level source field. This works for Terraform, Helmfile, and Packer components. Declare component sources inline without requiring separate component.yaml files—components are automatically downloaded on first use.

We're introducing ECR authentication integration - automatic Docker login for AWS Elastic Container Registry as part of your Atmos authentication workflow. Configure once, authenticate everywhere.

Terraform commands now feature interactive prompts for component and stack selection. Run atmos terraform plan without arguments and get an intuitive selector instead of an error message.

Quickly identify which components and stacks are affected by your changes with the new atmos list affected command.

If you've ever had two component instances pointing to the same base component, you've likely encountered the frustration: file conflicts, unexpected overwrites, and mysterious errors when running Terraform operations. Today, we're introducing Component Workdir Isolation—a foundational feature that eliminates these conflicts and unlocks powerful new capabilities for Atmos.

Custom commands and workflow steps can now specify a working_directory to control where they execute.

Atmos now supports the aws/assume-root identity kind, enabling secure, centralized management of root access across your AWS Organization using the STS AssumeRoot API.

Atmos now includes four AWS YAML functions that retrieve identity and region information directly in stack configurations: !aws.account_id, !aws.caller_identity_arn, !aws.caller_identity_user_id, and !aws.region.

While Atmos supports any devcontainer configuration, Geodesic is a proven DevOps toolbox that's been battle-tested for almost 10 years. If you're looking for a production-ready development container with all the tools you need for infrastructure work, Geodesic is your answer.

Running Atmos and managing cloud infrastructure inevitably means depending on dozens of tools—Terraform, kubectl, Helmfile, AWS CLI, and many more. But here's the problem every platform team faces: "It works on my machine."

Different versions. Missing dependencies. Subtle configuration differences. Onboarding a new team member becomes a day-long exercise in installing and configuring tools. Something that worked perfectly on your laptop fails in CI. You spend more time managing your toolchain than actually using it.

Today, we're solving this problem once and for all with native Development Container support in Atmos.

You can now specify an explicit name field in stack manifests to override the logical stack name. This is especially useful when migrating from other tools like Terragrunt, or when your infrastructure doesn't follow a strict naming convention.

Atmos now supports a global env section in atmos.yaml that applies environment variables to all subprocesses spawned by Atmos, including Terraform, Helmfile, Packer, workflows, and custom commands.

Atmos now supports version constraint validation, allowing you to specify required Atmos version ranges in your atmos.yaml configuration. When your configuration requires specific features or behaviors, you can ensure all team members and CI/CD pipelines use compatible Atmos versions.

We've improved how Atmos handles YAML functions during merges across configuration layers. Atmos now postpones merging YAML functions until after the regular merge is done. This avoids the type conflicts that used to happen when a stack layer replaced a plain value—like a string, map, or list—with a YAML function such as a template or an output reference.

Atmos now supports using filesystem paths instead of component names for all component commands. Use . for the current directory, relative paths like ./vpc or ../eks, or absolute paths. This might feel more natural for users accustomed to running commands on folders rather than remembering specific component names.

Metadata now inherits from base components, just like vars and settings.

New metadata.name field provides stable Terraform state paths when using versioned component folders.

We're excited to introduce automatic backend provisioning in Atmos, a feature that solves the Terraform bootstrap problem. No more manual S3 bucket creation, no more chicken-and-egg workarounds—Atmos provisions your state backend automatically with secure defaults, making it fully compatible with Terraform-managed infrastructure.

Atmos lets you model your cloud architecture, so why shouldn't you be able to easily explore that? This is especially a pain point for people new to a team who just want to see what exists without having to understand your complete cloud architecture. Atmos List makes that possible.

We've enhanced all column-supporting list commands (instances, components, stacks, workflows, vendor) to support customizable output columns via atmos.yaml configuration.

The !env YAML function now supports reading environment variables from env sections defined in your stack manifests and Atmos configuration. This makes it easy to set defaults for environment variables and reference values from your infrastructure configuration.

Need to generate random port numbers, worker IDs, or other numeric values in your Atmos configurations? The new !random YAML function makes it easy.

Stop fighting with different Atmos configurations for development, CI/CD, and production. Profiles let you switch contexts with a single flag while keeping your core configuration consistent.

Atmos now searches parent directories for atmos.yaml and discovers .atmos.d/ at the git repository root, making it easier to run commands from anywhere in your project.

Atmos now automatically provisions AWS SSO permission sets as identities when you authenticate. Log in once, and all your available roles are instantly ready to use—no manual configuration required.

Atmos now automatically discovers your repository root and runs from there, just like Git. No more cd-ing back to the root directory.

We've completely rebuilt Atmos error handling from the ground up to provide helpful hints, rich context, and enterprise-grade error tracking. When something goes wrong, you now get actionable guidance instead of cryptic messages, and enterprises can track and analyze errors across their entire infrastructure stack.

Atmos now includes 350+ terminal themes to customize your CLI experience. Choose from popular themes like Dracula, Solarized, or GitHub Dark, or browse the complete collection to find one that matches your style.

We're thrilled to announce native Azure authentication support in Atmos! You can now authenticate to Azure using atmos auth login with device code flow, OIDC, and service principals - working identically to az login with full Terraform provider compatibility.

You can now disable Atmos identity authentication by setting --identity=false, allowing you to use cloud provider SDK credential resolution instead.

The atmos describe family of commands now supports the --identity flag, enabling runtime authentication when processing YAML template functions that access remote resources. This ensures that !terraform.state and !terraform.output functions work seamlessly without relying on ambient credentials.

If you develop Terraform providers, you can now test them locally with Atmos-managed components using Terraform's development overrides feature. This enables rapid iteration without publishing development versions to a registry.

We're excited to announce two major improvements to Atmos authentication: per-step authentication for workflows and authentication support for custom commands. These features enable you to seamlessly use cloud credentials in your automation while maintaining security through file-based credential management.

Atmos now features intelligent terminal output that adapts to any environment automatically. Developers can write code assuming a full-featured terminal, and Atmos handles the rest - capability detection, color adaptation, and secret masking happen transparently. No more capability checking, manual color detection, or masking code. Just write clean, simple output code and it works everywhere.

Atmos now supports Azure Blob Storage backends in the !terraform.state YAML function. Read Terraform outputs directly from Azure-backed state files without initializing Terraform—bringing the same blazing-fast performance to Azure that S3 users already enjoy.

Atmos now includes atmos auth console, a convenience command for opening cloud provider web consoles. Similar to aws-vault login, this command uses your authenticated Atmos identities to generate temporary console sign-in URLs and open them in your browser.

We're excited to announce a new global flag that makes working with Atmos across multiple repositories and directories significantly easier: --chdir (or -C for short).

Atmos Auth supports flexible keyring backends, giving you control over how authentication credentials are stored. Use your system keyring for native OS integration, file-based keyrings to share credentials across OS boundaries (like between your Mac and a Docker container), or memory keyrings for testing.

We're excited to announce a new authentication command: atmos auth logout. This command provides secure, comprehensive cleanup of locally cached credentials, making it easy to switch between identities, end work sessions, and maintain proper security hygiene.

We're introducing two new commands for exploring Atmos releases: atmos version list and atmos version show. Browse release history with date filtering, inspect artifacts, and keep your infrastructure tooling up-to-date—all from your terminal with beautiful formatted output.

We're excited to introduce atmos auth shell, a new command that makes working with multiple cloud identities more secure.

This command launches isolated shell sessions scoped to specific cloud identities. Think of it like aws-vault exec, but for all your cloud identities managed by Atmos—AWS, Azure, GCP, GitHub, SAML, and more.

When you exit the shell, you return to your parent shell where those credentials were never present. It's a simple pattern that helps prevent credential leakage and reduces the risk of running commands against the wrong environment.

We're excited to announce a powerful new command for managing authentication in Atmos: atmos auth list. This command provides comprehensive visibility into your authentication configuration, making it easier than ever to understand and manage complex authentication chains across multiple cloud providers and identities.

We've shipped a feature that developers working with complex infrastructure configurations have been asking for: provenance tracking. With the new --provenance flag in atmos describe component, you can now see exactly where every configuration value originated—down to the file, line number, and column.

We're introducing atmos auth - native cloud authentication built directly into Atmos. After years of solving the same authentication problems repeatedly across different tools and teams, we've built a solution that works whether you adopt the entire Atmos framework or just need better credential management.

Atmos now includes a unified import adapter registry that provides a modular, extensible architecture for configuration imports.