Here's the March edition of the Cloud Posse Customer Newsletter. Six things that shipped or are shipping — and what they mean for your team.
Atmos now treats Ansible as a first-class component type alongside Terraform and Helmfile. If your team manages configuration alongside provisioning — installing packages, configuring services, enforcing OS-level policies — you can now do it through the same stack manifests that drive everything else.
Two new commands make it work: atmos ansible playbook executes playbooks with stack-based configuration, and atmos ansible version checks your Ansible installation. You get full stack processor support — inheritance, variables, environment settings, and authentication sections all work the same way they do with Terraform. Atmos generates variable files automatically and passes them through, and any native Ansible flags work via the -- separator.
Better yet, Atmos functions can pass values between Terraform and Ansible components — so your provisioning outputs feed directly into your configuration without glue scripts or manual handoffs. One tool, one set of stack manifests, and one workflow for both layers.
This feature was a community contribution — thank you to Michael Rosenfeld (Burns & McDonnell, 1898 & Co.) for building it and Gabriel Hall (CMU, ScottyLabs) for the initial groundwork. See the full details in the changelog.
Last month we introduced Atmos Auth with AWS support. Now it covers all three major clouds.
For GCP, two new providers ship out of the box: Application Default Credentials (ADC) for local development, and Workload Identity Federation for CI/CD. The Workload Identity Federation provider automatically detects your GitHub Actions environment, constructs the OIDC audience, and retrieves tokens — no manual token_source configuration needed. Credentials are stored in provider-specific directories, isolated from your local gcloud configuration.
Azure support follows the same pattern — native authentication that lives in atmos.yaml alongside your infrastructure, so your team gets consistent multi-cloud auth without managing separate credential tooling for each provider.
The workflow hasn't changed: atmos auth login, verify your identity, and deploy — regardless of which cloud you're targeting. Both of these were community contributions — thank you to Mikhail Shirkov (NXT:FWD) for GCP support and PePe Amengual (Slalom Build) for the Azure integration. See the GCP changelog for implementation details.
We're building a comprehensive migration guide to help customers upgrade from older reference architecture patterns to the latest versions. This covers the account-map deprecation from last month, the new security baseline components, and updated patterns for networking and DNS.
When it ships, you'll get step-by-step instructions for each migration path along with validation steps to confirm everything works before and after. We'll announce it in the next newsletter and send a dedicated email when it's available.
If you'd like help updating your infrastructure to the latest best practices so you don't get left behind, reach out — we can walk you through it now.
Managing GitHub repositories manually doesn't scale as the number of repositories increases. Different repos end up with different branch protection rules, inconsistent secrets configuration, and team permissions that drift over time.
The aws-github-repository component lets you manage all of this through infrastructure as code. Declare repositories in your stack YAML and get consistent configuration across your entire org: visibility settings, default branches, merge strategies, branch protection rules, deployment environments with approval gates, deploy keys, team and collaborator permissions, and secrets integrated directly with AWS Secrets Manager and SSM Parameter Store.
You can also import existing repositories without overwriting their current configuration — so adoption is incremental, not all-or-nothing.
If your team is spending time manually configuring repos or debugging inconsistent settings, this component eliminates that category of work entirely.
GitHub recently announced agentic workflows — a technical preview that lets coding agents run automated tasks inside GitHub Actions. Think continuous triage, automated documentation updates, code quality suggestions, and test coverage improvements, all triggered by repository events and executed in sandboxed environments.
Configuration is Markdown-based with YAML frontmatter for triggers and permissions. Pull requests are never merged automatically — human review stays mandatory. We're exploring how this capability fits with Atmos workflows and what it means for infrastructure automation.
What makes this interesting for infrastructure teams: combine GitHub Issue templates with agentic workflows and you can handle routine requests — onboarding new services, performing dependency updates, rotating credentials — through a self-service form that triggers an agent to do the actual work. The human reviews the PR, not the toil.
This is early, and we'd love your input. If there are repetitive tasks in your infrastructure workflow that you'd want an agent to handle, let us know. Reply to this email or drop a feature request in the relevant GitHub repo. Your feedback directly shapes what we build next.
A lot has changed in the last few months — Atmos Auth, the security baseline overhaul, account-map replacements, and more on the way. Keeping up is hard when your team is heads-down on product work, and falling behind makes each subsequent upgrade harder.
If you'd rather not dig through changelogs and migration guides yourself, we're happy to pair with your team and get your environment current. We do this regularly and know where the rough edges are.
Book time with us and we'll figure out what makes sense for your situation.
Questions about any of these changes? Reply to this email or schedule time with us.
