Atmos Pro Logo

Atmos Pro

ProductPricingDocsBlogChangelog
Create Workspace
← Back to Changelog
Feature

Commit Generated Files From CI

Erik Osterman

Erik Osterman

CEO & Founder of Cloud Posse

|May 29, 2026

Older

Post-Apply Drift Verification

Erik Osterman

Erik Osterman

CEO & Founder of Cloud Posse

Erik is the founder of Cloud Posse and creator of Atmos. With over a decade of experience helping teams adopt Terraform at scale, he is passionate about open-source infrastructure tooling and developer experience.

Book a Meeting
Atmos Pro Logo

Atmos Pro

The fastest way to deploy your apps on AWS with Terraform and GitHub Actions.

GitHubTwitterLinkedInYouTubeSlack

For Developers

  • Quick Start
  • Example Workflows
  • Atmos Documentation

Community

  • Register for Office Hours
  • Join the Slack Community
  • Try our Newsletter

Company

  • About Cloud Posse
  • Security
  • Pricing
  • Blog
  • Media Kit

Legal

  • SaaS Agreement
  • Terms of Use
  • Privacy Policy
  • Disclaimer
  • Cookie Policy

© 2026 Cloud Posse, LLC. All rights reserved.

Checking status...
When a CI job formats Terraform, regenerates providers, or rewrites backends, it needs to commit those changes back to the branch — but commits made with GITHUB_TOKEN never trigger another CI run. That's a deliberate GitHub limitation. And if your branch protection requires status checks to pass — which any secure repository should — that missing run leaves the pull request unmergeable. Worse, most workarounds share the same flaw: they hinge on a static credential — a personal access token, or your own GitHub App whose private key and installation tokens you store and rotate as CI secrets. That's a long-lived secret sitting in your CI, waiting to leak.
atmos pro commit does it natively, with no extra app to build. Your workflow stages its changes and runs the command, and the Atmos Pro App you already installed creates the commit server-side. Because the App authors the commit, GitHub signs it as a verified commit and your downstream CI runs on it — plan and apply pick up the generated changes automatically.
Best of all, there are no statically coded secrets or PATs to leak — the workflow authenticates with its short-lived GitHub OIDC token and never receives a write token. It only uploads the file contents; Atmos Pro validates them and creates the commit, so a malicious pull request can't exfiltrate write access or touch .github/. The command also detects when it's running on a commit it just made (atmos-pro[bot]) and exits, so you don't get loops.
Here's what a simple workflow looks like — format the code, then commit the result:
.github/workflows/atmos-pro-autocommit.yaml
name: 👽 Atmos Pro Autocommit
 
on:
  pull_request:
 
permissions:
  id-token: write
  contents: read
 
jobs:
  autocommit:
    if: github.actor != 'atmos-pro[bot]'
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/cloudposse/atmos:${{ vars.ATMOS_VERSION }}
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.ref }}
 
      - name: Format
        run: terraform fmt -recursive
 
      - name: Commit
        env:
          ATMOS_PRO_WORKSPACE_ID: ${{ vars.ATMOS_PRO_WORKSPACE_ID }}
        run: atmos pro commit --all -m "[autocommit] terraform fmt"
See Commit From CI for staging options, flags, and limits.