2026-08-13
Dedicated Atlantis instances per customer, plus experimental drift detection
#atlantis #tofu #terragrunt #security #automation
Atlantis, the bot that plans and applies your infrastructure changes in pull requests, now runs as a dedicated instance per customer instead of one shared service. Your instance holds only the credentials for your own AWS accounts and only listens to your own repository. This change is part of a proactive hardening across all our systems; no signs of actual exploitation have been identified. On top of this new setup we’re piloting automated drift detection with a couple of customers.
What changed
Until now, a single shared Atlantis served all customers. We’ve replaced it with one instance per customer, isolated on every level:
- Credentials: your instance runs with an IAM role that can only assume the automation role in your own AWS accounts.
- Repository access: the instance only accepts webhook events from your repository, authenticated with its own unique webhook secret.
- Runtime: each instance runs in its own namespace, with network policies restricting what can reach it.
All customers have already been migrated and your PR workflow is unchanged. The old shared instance has been fully retired.
Risk this resolves
Running a plan executes code from the repository: providers, modules, and any logic your Terragrunt stacks pull in. On a shared service, that code ran next to the credentials of every customer. Now the blast radius is limited to one customer: even an instance compromised through a malicious pull request can never reach another customer’s accounts. Isolation also lets us upgrade and tune Atlantis per customer, and one customer’s heavy plans no longer queue behind another’s.
Experimental: scheduled drift detection
The dedicated instances also unlock a capability we’re piloting: scheduled drift detection. A scheduled job asks your Atlantis instance to plan all your stacks against the main branch and posts a summary report as a GitHub issue in your repository. This surfaces changes made outside of our shared IaC workflow (console edits, expired resources, upstream changes) while they’re still fresh.
The report only lists which stacks are clean and which have drifted, without full plan output. Remediation stays a human decision: an engineer (you or us) follows up with a regular pull request on the drifted stacks.
Drift detection is currently enabled for a couple of customers while we evaluate rolling it out to everyone. If you’d like to try it on your setup, get in touch.