78 posts tagged with "DX"

Bumping a vendored component to a newer version has always meant guessing. atmos vendor pull fetches whatever version is pinned — it doesn't tell you a newer one exists, and it definitely doesn't show you what changed. Finding out meant a manual git clone, a git diff between two tags, and then hand-editing the version field in vendor.yaml without breaking a comment or a YAML anchor.

You built a slick interactive workflow — choose an account, input a release tag, then deploy. It is perfect on your laptop. Then CI runs it and everything stops with interactive terminal required for step. The prompts that make the workflow friendly locally are exactly what make it unrunnable in a pipeline, so you end up maintaining a second, prompt-free copy just for CI.

Interactive steps now fall back to their default value when there is no TTY, so the same workflow runs unattended in CI — no duplicate variant required.

Atmos can now record terminal sessions as asciicast files and render them into shareable formats for documentation, demos, and CI artifacts.

atmos cast render demo.cast --output=demo.gif
atmos cast render demo.cast --output=demo.html
atmos cast render demo.cast --output=demo.out --format=html

The render command turns a recording into a rendered artifact — here it's converted straight to a GIF:

Replaying a recording in the terminal with play reproduces it exactly as it was captured:

And any command can capture its own session as it runs with --cast, no separate recording step required:

Atmos help showed too much at once. A simple command like atmos terraform plan --help explained the command, its examples, its own flags, compatibility flags, and every inherited global flag, which made the options you actually needed harder to find.

Topic-specific help fixes that by making default help focused, while keeping usage examples, command flags, and the full reference one flag away.

Atmos now builds itself through a first-class Atmos command:

atmos build --target linux

We replaced the old Make-based build and CI entrypoints with Atmos custom commands to improve the developer experience and dogfood our own workflow engine. Build and test workflows now expose the flags developers actually care about, such as the target platform, while Atmos owns the shell details, cross-compilation wiring, output paths, and CI glue behind the command.

Atmos help output now separates built-in commands from custom commands, and error output now makes explanations easier to scan without adding extra headings.

Atmos custom commands now support path-based names. Instead of writing a deeply nested command tree just to describe a command path, you can put the full command path in name.

The result is easier to read, easier to review, and keeps the same recursive merge behavior that existing custom commands rely on.

Start with the recording.

That is the point of this update: the docs now have short terminal casts for the parts of Atmos that are easier to understand by watching them run.

Human logs are useful while you are watching a command run, but they are not enough when you need to diagnose subprocess execution, CI failures, or agent runs after the fact.

Auth profiles and team defaults are often managed centrally, but workload or app repositories still need to use them. Until now, that usually meant copying profile YAML into each repository and keeping those copies in sync by hand.

Workflows often depend on tools, files, and directories being present before they run. Without a first-class check, those prerequisites tend to hide inside brittle shell snippets and ad hoc command checks.

Terminal demos and recordings are hard to follow when a command dumps hundreds of lines instantly. The output may be correct, but viewers cannot read it and recording tools capture a wall of text instead of a sequence.

Custom command steps can now read their own command-line flags through {{ .Flags.<name> }}, and the table step templates its data, columns, and title per-step. Together they let you build flag-driven runbooks — rich, dynamic output assembled declaratively in atmos.yaml, no shell scripting required.

The official Atmos agent skills are now embedded directly in the Atmos binary. atmos ai skill install <name> works fully offline — no network call, no Git clone — and atmos ai skill list shows a single merged view of every skill available to you alongside what's already installed.

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 can now read and edit your YAML — atmos.yaml, stack manifests, and vendor.yaml — through first-class commands that preserve comments, anchors, YAML functions, and Go templates. No more sed or yq one-liners that strip your comments and reformat the file.

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.

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

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 now clones each remote (Git) stack-import source once per run instead of re-cloning it for every import that points at the same repository — and an optional ttl lets a warm cache (like the GitHub Actions cache) skip the clone entirely on subsequent runs.

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

A common question from the community is: how do I use Atmos with Packer to build AMIs, and automate the whole build → approve → share process? We've published a new gist that shows exactly that — a reference recipe combining several Atmos features into one production-shaped workflow.

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.

GitHub Actions has a built-in "Re-run with debug logging" button: when a workflow fails, you click it and the next run launches with runner and step debug logging turned on. Atmos now auto-detects that signal — when you re-run with debug logging, Atmos switches its own log level to Debug for the run. No need to remember to also set ATMOS_LOGS_LEVEL=Debug in your workflow YAML.

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.

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

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.

Every atmos list subcommand that processes stack manifests now accepts --process-templates and --process-functions (with matching ATMOS_PROCESS_TEMPLATES / ATMOS_PROCESS_FUNCTIONS env vars), matching the flag surface of atmos describe affected and atmos describe stacks. Defaults are true across the board.

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.

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

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.

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.

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

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.

Atmos toolchain now has native GitHub Actions support with the new github format for atmos toolchain env.

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.

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.

Atmos now automatically provisions backends during terraform init, eliminating the need for a separate backend create command. When provision.backend.enabled: true is set, backends are created just-in-time during your first Terraform operation.

The source provisioner now provides better visual feedback with spinners during auto-provisioning, interactive confirmation prompts for delete operations, and interactive stack selection when --stack is omitted.

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

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 auth login now automatically falls back to provider authentication when no identities are configured, enabling seamless first-time login with auto_provision_identities.

Atmos now automatically detects when your AWS IAM User credentials have been rotated or revoked and prompts you for new credentials inline. No more persistent authentication failures after credential rotation. Plus, improved guidance when credentials expire.

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

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.

Atmos now provides clear, actionable error messages when your Terraform components contain HCL syntax errors, instead of the misleading "component not found" message.

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

Custom commands now support boolean flags with configurable default values. You can define type: bool flags that default to true or false, making it easier to handle special behavior triggers.

We've reorganized the Atmos documentation to better serve both newcomers and experienced users. Here's what changed and why.

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.

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.

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 now includes interactive prompts for missing required flags and positional arguments, making commands more discoverable and user-friendly. This feature is being gradually rolled out across commands.

The atmos workflow command now automatically discovers workflow files, eliminating the need to specify --file for uniquely named workflows. This developer experience improvement makes running workflows faster and more intuitive.

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.

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

Tab completion for the --stack flag is now context-aware, filtering suggestions based on the component you specify.

We've made several quality-of-life improvements to Atmos authentication commands, making identity management smoother and more intuitive.

Atmos auth, documentation, and workflow management commands now work independently of stack configurations, making it easier to use Atmos in CI/CD pipelines and alongside "native" Terraform workflows.

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.

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

We've significantly improved the AWS SSO authentication experience with styled verification code dialogs, animated status indicators, and proper Ctrl+C handling.

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.