NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #387 by repository stars
Last release today
06 Oct 2026
Ships on a steady schedule
a new release about every 8 days
Some releases are documented
notes for 27 of the last 60 stable releases
Nothing withdrawn
no release was ever pulled
9 years old
1519 releases · first in 2017
Flags --require-approval, --require-mergeable and --allow-repo-config are deprecated in favour of creating a server-side repo config file that applies…
This release implements Server-Side Repo Config which allows users to write
atlantis.yaml-style config on the server rather than in individual repos.
The Server Side config also allow Atlantis operators to control what individual
repos can do in their atlantis.yaml files. Read docs for more details.
atlantis server flag --repo-config for specifying the
repo config file .--repo-config-json for specifying the repo config as a JSON string
instead of having to write a config file to disk.atlantis.yaml files to configure their projects,
however by default, those files can't create custom workflows or set Apply
Requirements.3 of atlantis.yaml fixes a small issue with how we were parsing
custom run steps. Previously we were doing additional parsing which caused some
users to have to add extra escaping to their commands. Now this is no longer
required. See the Backwards Compatibility section for more details.atlantis apply to apply all outstanding plans wouldn't work if
you had more than one project defined in the exact same directory and workspace. (Fixes #365)The server-side config changes are fully backwards compatible. The biggest
difference is that all repos can now create atlantis.yaml files, but without
being able to create custom workflows or set apply requirements. This will
allow users to configure their projects, workspaces and terraform versions
at a repo level without enabling those repos to run custom code or circumvent
apply requirements set server-side.
atlantis.yaml has a new version 3. If you continue to use version 2, you
will experience no changes. If you want to upgrade to version 3, then
if you're not using any custom run steps in your workflows you can upgrade
the version number without additional changes.
If you are using run steps, check our upgrade guide
to see if you need to make any changes before upgrading.
Flags --require-approval, --require-mergeable and --allow-repo-config are
deprecated in favour of creating a server-side repo config file that applies
the same configuration. If you run atlantis server with those flags, a
deprecation warning will be printed telling you what server-side config is
recommended instead.
If you have projects configured with the same directory and workspace (which means
you're probably using the -backend-config flag) and their names contain /'s,
then you'll have to re-run atlantis plan after upgrading if you had any unapplied plans.
An example of what config would mean you need to re-plan:
projects:
- name: name/with/slashes
dir: samedir
workflow: a
- name: another/with/slashes
dir: samedir
workflow: b
a:
plan:
steps:
- run: rm -rf .terraform
- init:
extra_args: [-backend-config=staging.backend.tfvars]
- plan
b:
plan:
steps:
- run: rm -rf .terraform
- init:
extra_args: [-backend-config=staging.backend.tfvars]
- plan
https://github.com/runatlantis/atlantis/compare/v0.6.0...v0.7.0
One column per quarter.
Nothing published for this version
Nothing published for this version
Upgrade base Docker image to use Alpine 3.9. Alpine 3.9 mitigates CVE-2018-19486.
This release introduces a new flag --default-tf-version=<version> that allows users
to set the version of Terraform that Atlantis defaults to. Atlantis will automatically
download that version on startup so users don't need to build their own custom
Docker images.
Atlantis will also now automatically download any Terraform version specified in
atlantis.yaml:
version: 2
projects:
- dir: .
terraform_version: v0.12.0-beta1 # Will be downloaded automatically.
--default-tf-version=<version> will cause Atlantis to automatically download
and use that version of Terraform by default. Atlantis will also automatically
download terraform versions specified in atlantis.yaml via the terraform_version
config key. (#538)None
Our Docker image runatlantis/atlantis has Terraform v0.11.13 now. If you
use the new flag --default-tf-version=<desired version> then you won't
be affected by this change (nor for subsequent version upgrades).
The Atlantis status checks have been renamed from what they looked like in v0.5.*.
Previously the names were: plan/atlantis and apply/atlantis. Now the
names are atlantis/plan and atlantis/apply.
This change will only affect you if you're requiring those status checks to pass via a setting in your Git host (ex. via GitHub protected branches). If so, you'll need to change your settings to require the new names to pass and un-require the old names.
If you were on a version lower than
v0.5.*then read the backwards compatibility notes for release0.5.0.
NOTE from the maintainer: I take backwards compatibility seriously and I apologize that the status checks are changing again so soon after the 0.5 release also changed them. I know that if you have many repos and require the checks to pass that it is a large task to change them all again.
In this case, I decided that the tradeoff was worth it because the 0.5 release has only been out for a couple of weeks so hopefully not everyone has upgraded to it. The new check names makes them a lot easier to read (at least on GitHub) because they appear next to each other now due to alphabetical sorting. In this case I felt like it was better to get this change done as soon as possible rather than having this annoying UX issue stay around forever.
https://github.com/runatlantis/atlantis/compare/v0.5.1...v0.6.0
This is a bugfix release to fix a bug where Atlantis was replying to comments that weren't directed to it.
This is a bugfix release to fix a bug where Atlantis was replying to comments that weren't directed to it.
Diff: https://github.com/runatlantis/atlantis/compare/v0.5.0...v0.5.1
Support Bitbucket Cloud's upcoming API deprecations.
This release has two big features: New Status Checks and Terraform Enterprise Integration.
New Status Checks:
The new status checks split the old status check into plan and apply phases.
Each check now tracks the status of each project modified in the pull request.
For example if two projects are modified, the plan check might read:
2/2 projects planned successfully.
And the apply check might read:
0/2 projects applied successfully.
Users can now use their Git host's settings to require these checks pass before a pull request is merged and be confident that all changes have been applied (for example).
Terraform Enterprise Integration:
Atlantis now integrates with the Terraform Enterprise (TFE)
via the remote backend.
Atlantis will run terraform commands as usual, however those commands will
actually be executed remotely in Terraform Enterprise.
Using Atlantis with Terraform Enterprise gives you access to TFE features like:
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.15...v0.5.0
plan and one for apply (see above).USER_NAME environment variable for custom steps to use. (#489)bitbucket.mycompany.com/pathprefix (Fixes #508)terraform init with -upgrade. (Fixes #443)atlantis plan -d 'dir with spaces'. (Fixes #423)atlantis testdrive for latest version of ngrok.New Status Checks - If you have settings in your Git host that require the Atlantis commit status check to be in a certain condition, you will need to modify that setting as follows:
Previously, Atlantis set a single check with the name Atlantis. Now there are
two checks with the names plan/atlantis and apply/atlantis. If you had
previously required the Atlantis check to pass, you should now require both
the plan/atlantis and apply/atlantis checks to pass.
The behaviour has also changed. Previously, the single Atlantis check
would represent the status of the last
run command. For example, if I ran atlantis plan and it failed, the check
would be in a Failed state. If I ran atlantis apply -p project1 and it succeeded,
then the check would be in a Success state, regardless of the status of other projects
in the pull request.
Now, each check represents the plan/apply status of all projects modified in
the pull request. For example, say I open up a pull request that modifies
two projects, one in directory proj1 and the other in proj2. If autoplanning
is enabled, and both plans succeed, then there will be a single status check:
plan/atlantis - 2/2 projects planned successfully (success)If I run atlantis apply -d proj1, then Atlantis will set a pending apply check:
plan/atlantis - 2/2 projects planned successfully (success)apply/atlantis - 1/2 projects applied successfully (pending)If I apply the final project with atlantis apply -d proj2, then my checks
will look like:
plan/atlantis - 2/2 projects planned successfully (success)apply/atlantis - 2/2 projects applied successfully (success)terraform init is now run with -upgrade=true. Previously, it used Terraform's
default setting which was false.
This means that terraform will always update to the latest version of plugins
and modules. For example, if you're using a module source of
source = "git::https://example.com/vpc.git?ref=master"
then terraform init will now always use the version on master whereas
previously, if you had already run atlantis plan before master was updated,
a new atlantis plan wouldn't pull the latest changes and would just use
the cached version.
This is unlikely to cause any issues because most users already expected Atlantis to use the most up-to-date version of modules/plugins within the set constraints.
This is a bugfix release containing an important fix to how Atlantis executes Terraform. A bug was introduced in v0.4.14 that causes Atlantis to hang
This is a bugfix release containing an important fix to how Atlantis executes Terraform. A bug was introduced in v0.4.14 that causes Atlantis to hang indefinitely when executing Terraform when there is a lot of output from Terraform.
In addition, there's a fix to automerge when you require rebasing or commit squashing in GitHub and a fix for the mergeability check if you're requiring the Atlantis status to pass in GitHub.
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.14...v0.4.15
None – this is a bugfix release.
mergeable now works on GitHub if you are also requiring the Atlantis status to pass before merging. (Fixes #453)None
WARNING: This release contains a bug that causes Terraform execution to stall on large infrastructures. Please use v0.4.15 instead.
WARNING: This release contains a bug that causes Terraform execution to stall on large infrastructures. Please use v0.4.15 instead.
This release contains two big new features: Automerge and Checkout Strategy.
Automerge is a much asked for feature that allows Atlantis to automatically
merge your pull requests if all plans have been applied successfully.
It can be enabled via the --automerge flag, or via an atlantis.yaml setting:
version: 2
automerge: true
projects:
- ...
Checkout Strategy allows you to choose if Atlantis checks out the exact branch
from the pull request or what the destination branch will look like once the pull
request is merged. You can choose your checkout strategy via the --checkout-strategy
flag which supports branch (the default) or merge.
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.13...v0.4.14
--checkout-strategy flag which supports checking out the code as it will
look once the pull request was merged. Previously we only supported checking out
the pull request branch which might be out of date with the destination branch
and so cause Terraform to delete resources that have already been applied.
See https://www.runatlantis.io/docs/checkout-strategy.html. (Fixes #35--tfe-token flag to support using Terraform Enterprise's Free Remote State Storage. (#419)None
The release downloads have been deleted because this release contains a critical bug
The release downloads have been deleted because this release contains a critical bug
This release is focused on quick-wins, bugfixes and one new feature that allows users to require pull requests be "mergeable", before allowing for atl
This release is focused on quick-wins, bugfixes and one new feature that allows
users to require pull requests be "mergeable", before allowing for atlantis apply.
The mergeable apply requirement is very useful for GitHub users where it allows them to require pull requests be approved by specific users or require certain status checks to pass. See https://www.runatlantis.io/docs/apply-requirements.html#mergeable for more information.
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.12...v0.4.13
Introduce a new (optional) mergeable apply requirement that requires pull requests to be mergeable prior to allowing apply to run. (Fixes #43)
If users have workspaces configured for a directory via an atlantis.yaml file, only allow
commands to be run on those workspaces. All commands attempted to be run on different workspaces will error out.
For example, if I have an atlantis.yaml file:
version: 2
projects:
- dir: mydir
workspace: default
- dir: mydir
workspace: staging
Then I can run atlantis apply -d mydir -w default and atlantis apply -d mydir -w staging
but I will receive an error if I run atlantis apply -d mydir -w somethingelse.
If users are setting the name key for their projects in atlantis.yaml, then
include the project name in the comment output so it's easier to identify which
plan/apply output is for which project. (Fixes #353))
Bump the Terraform version in the Docker image to 0.11.11.
Tweak logging to add timezone to the timestamp and make the output more readable. (#402)
Warn users if running atlantis apply -- -target=myresource because -target can
only be specified during atlantis plan. (Fixes #399)
terraform plan returns an error, print the error to the pull request. (#381)--gitlab-hostname without a scheme then Atlantis wouldn't parse the URL correctly. (#377)The version of Terraform installed in the runatlantis/atlantis Docker image
is now 0.11.11. Previously it was 0.11.10.
If you are a) using an atlantis.yaml file and b) defining Terraform workspaces
and c) running plan and apply against workspaces that were not defined in the
atlantis.yaml file, then this no longer works.
You will now need to define all the workspaces in the atlantis.yaml file.
For example, say you had the following config:
version: 2
projects:
- dir: mydir
workspace: production
And you used to run:
atlantis plan -d mydir -w anotherworkspace
atlantis apply -d mydir -w anotherworkspace
For this to work now, you need to add the anotherworkspace workspace to your
atlantis.yaml file:
version: 2
projects:
- dir: mydir
workspace: production
- dir: mydir
workspace: anotherworkspace
Small feature and bug fix release. If you're using GitLab <11.1 then your comment formatting is fixed!
Small feature and bug fix release. If you're using GitLab <11.1 then your comment formatting is fixed!
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.11...v0.4.12
atlantis server --atlantis-url https://mydomain.com/mypath and when
atlantis renders its UI, all the URLs will have the /mypath prefix so the UI
renders properly. (Fixes #213)runatlantis/atlantis on OpenShift. OpenShift runs images
with random uids so we needed to build in support for that. (Fixes #345)We made changes to the base image (runatlantis/atlantis-base) that
runatlantis/atlantis is built off of. These changes should not affect your
running of atlantis unless you're building your own custom images and were relying
on specific user permissions. Even then we don't anticipate any problems.
These are the changes in detail:
Previously, the permissions of /home/atlantis were:
$ ls -la /home/atlantis/
drwxr-sr-x 2 atlantis atlantis 4096 Sep 13 22:49 .
Now they are:
$ ls -la /home/atlantis/
drwxrwxr-x 2 atlantis root 4096 Nov 28 21:22 .
root group.w and x.This was needed because OpenShift runs Docker images as random uid's under
the root group and so now those random uid's can use /home/atlantis as their
data directory.
Previously, the atlantis user was only part of its own group:
$ gosu atlantis sh
$ whoami
atlantis
$ groups
atlantis
Now it's also part of the root group:
$ gosu atlantis sh
$ groups
atlantis root
Previously, the permissions for /etc/passwd were:
$ ls -la /etc/passwd
-rw-r--r-- 1 root root 1284 Sep 13 22:49 /etc/passwd
Now the permissions are:
$ ls -la /etc/passwd
-rw-rw-r-- 1 root root 1284 Nov 28 21:22 /etc/passwd
The w group permission was added so that in OpenShift, the random uid can write
their own login entry (https://github.com/runatlantis/atlantis/blob/main/docker-entrypoint.sh#L28)
which is required because terraform expects the running user to have an entry
in /etc/passwd.
Medium sized release that updates the Terraform version and makes terraform plan output smaller by removing the Refreshing... output.
Medium sized release that updates the Terraform version and makes terraform plan
output smaller by removing the Refreshing... output.
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.10...v0.4.11
terraform plan output is shorter now thanks to remove the Refreshing... output (#339)atlantis.yaml can now contain /'s. This is useful
if you want to name your projects similar to the directories they're in. (Fixes #253)--silence-whitelist-errors which prevents Atlantis from comment back on pull requests
from non-whitelisted repos. This is useful if you want to add the Atlantis webhook to a whole organization
and then control which repos are actioned on via the whitelist. (Fixes #312)terraform plan with -var atlantis_repo_owner=runatlantis -var atlantis_repo_name=atlantis -var atlantis_pull_num=10
(if the repo was runatlantis/atlantis) (#300)Atlantis now runs terraform plan with
-var atlantis_repo_owner=runatlantis \
-var atlantis_repo_name=atlantis \
-var atlantis_pull_num=10
(in this example the repo that Atlantis is running on is runatlantis/atlantis).
If you were using those variables in your terraform code:
variable "atlantis_repo_owner" {
default = "my_default"
}
Then Atlantis will be overriding those variables with its own values. To prevent this, you need to rename your variables.
If you aren't using those variables then this change won't affect you.
Small bugfix release to fix issues with new comment format.
Small bugfix release to fix issues with new comment format.
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.9...v0.4.10
None
plan not working on Bitbucket Server when repo owner contains spaces (#290)None
This release is mostly focused on changing how comments look. Terraform output is now automatically hidden if it's over 12 lines long: !https://user-i
This release is mostly focused on changing how comments look. Terraform output is now automatically hidden if it's over 12 lines long: Also the red and green highlighting for added and removed resources is fixed:
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.8...v0.4.9
terraform plan output is highlighted correctly-var atlantis_repo={repo name} -var atlantis_pull_num {pull num}.
This will allow users to trace Atlantis terraform executions in CloudTrail back to a specific
user and pull request if using assume role by creating a specific name for the session Terraform initiates.provider "aws" {
assume_role {
role_arn = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
session_name = "${var.atlantis_user}-${var.atlantis_repo}-${var.atlantis_pull_num}"
}
}
-input=false (#268).atlantis_repo and atlantis_pull_num. If
you were using variables with those names in your code you will need to rename them
in your code.Security release to upgrade the Docker image to the latest version of Alpine linux that fixes this bug: https://justi.cz/security/2018/09/13/alpine-ap…
Security release to upgrade the Docker image to the latest version of Alpine linux that fixes this bug: https://justi.cz/security/2018/09/13/alpine-apk-rce.html
Diff: https://github.com/runatlantis/atlantis/compare/v0.4.7...v0.4.8
None
None
Support GitLab repos nested under multiple levels and use the latest version of Terraform: 0.11.8!
Support GitLab repos nested under multiple levels and use the latest version of Terraform: 0.11.8!
gitlab.com/owner/group/subgroup/subsubgroup/repoTF_LOG set, Atlantis will start normally. Previously it
would error out due to attempting to parse the stderr output of the terraform version
command.None
If terraform init fails, include the failure logs in the comment posted back to the PR.
Just a small bugfix release.
None
terraform init fails, include the failure logs in the comment posted back to the PR.None
atlantis apply now applies all unapplied plans instead of just the plan in the root directory.
atlantis apply now applies all unapplied plans instead of just the plan in the root directory. (#169)atlantis plan now plans all modified projects instead of just the root directory.atlantis apply
atlantis apply now applies all unapplied plans. Previously it would only apply the plan in the root directory and default workspace.atlantis plan now plans all modified projects. Previously it would only run plan in the root directory and default workspace.Supports Bitbucket Server (#190).
Supports Bitbucket Cloud (bitbucket.org) (#30).
None
None
Don't comment on pull request if autoplan determines there are no projects to plan in. This was getting very noisy for users who use their repos for m
None
None
Add new /healthz endpoint for health checking in Kubernetes
/healthz endpoint for health checking in Kubernetes (#102)$PLANFILE environment variable to expected location of plan file when running custom steps (#168)
plan and substituting your own or piping through a custom script.*.tf* from *.tf in order
to trigger on .tfvars files.None
None
Autoplanning - Atlantis will automatically run plan on new pull requests and when new commits are pushed to the pull request.
plan on new pull requests and
when new commits are pushed to the pull request.atlantis.yaml format that supports:
atlantis.yaml config file format is not supported. You will need to migrate to the new config
format, see: https://www.runatlantis.io/docs/upgrading-atlantis-yaml.html--allow-repo-config.atlantis.yaml file
as follows:version: 2
projects:
- dir: mydir
autoplan:
enabled: false
atlantis apply no longer applies all un-applied plans but instead applies only the plan in the root directory and default workspace. This will be reverted in an upcoming releaseatlantis plan no longer plans in all modified projects but instead runs plan only in the root directory and default workspace. This will be reverted in an upcoming release.If the TF_LOG environment variable is set, should still be able to start. Previously atlantis server would exit immediately because it couldn't parse
None
TF_LOG environment variable is set, should still be able to start. Previously atlantis server would exit immediately because it couldn't parse the output of terraform version.None
Rename atlantis bootstrap to atlantis testdrive to make it clearer that it doesn't set up Atlantis for you. Fixes (#129).
atlantis bootstrap to atlantis testdrive to make it clearer that it
doesn't set up Atlantis for you. Fixes (#129).atlantis bootstrap where ngrok tunnel took a long time to start.
Atlantis will now wait until it sees the expected log entry before continuing.
Fixes (#92).atlantis bootstrap. (#130).atlantis bootstrap renamed to atlantis testdriveFix GitLab approvals not actually checking approval
Terraform 0.11.7 in Docker image
--repo-whitelist is now case insensitive. Fixes (#95).
--repo-whitelist is now case insensitive. Fixes (#95).atlantis server -h has newlines between flags so it's easier to read (#91).
Log a warning if unable to update commit status.
This release delivers some speed improvements through caching plugins and not running terraform workspace select unnecessarily. In my testing it saves
This release delivers some speed improvements through caching plugins and
not running terraform workspace select unnecessarily. In my testing it saves ~20s per run.
TF_PLUGIN_CACHE_DIR env var set. Fixes (#34).
terraform init faster. Terraform will still download new versions of plugins. See https://www.terraform.io/docs/configuration/providers.html#provider-plugin-cache for more details.TF_IN_AUTOMATION=true so the output won't contain suggestions to run commands that you can't run via Atlantis. (#82).terraform workspace select unless we actually need to switch workspaces. (#82).
atlantis plan -w /jdlkj. This was already not a valid workspace name according to Terraform. (#78).ngrok is already running when running atlantis bootstrap (#81).Atlantis version shown in footer of web UI. Fixes (#33).
This release focused on some security issues reported by @eriksw, thanks Erik! By default, Atlantis will be more secure now and you'll have to specify
This release focused on some security issues reported by @eriksw, thanks Erik! By default, Atlantis will be more secure now and you'll have to specify which repositories you want it to work on.
--allow-fork-prs added to atlantis server controls whether Atlantis will operate on pull requests from forks. Defaults to false.
This flag was added because on a public repository anyone could open up a pull request to your repo and use your Atlantis
install.--repo-whitelist added to atlantis server controls which repos Atlantis will operate on. This flag was added
so that if a webhook secret is compromised (or you're not using webhook secrets) Atlantis won't be used on repos you don't control.atlantis server without any webhook secrets set. This is dangerous because without a webhook secret, an attacker
could spoof requests to Atlantis.--allow-fork-prs now if you want to run Atlantis on pull requests from forked repos.--repo-whitelist in order to start atlantis server. See atlantis server --help for how that flag works.Run apply in correct directory when using -d flag. Fixes
-d flag. Fixes (#22)Fix security issue where Atlantis wasn't escaping the optional "extra args" that could be appended to comments
atlantis plan ; cat /etc/passwdatlantisrun/atlantis. Read why hereatlantis plan -d dir1/dir2atlantis plan -h--data-dir paths to absolute from relative. Fixes (#245)modules/ unless there's a main.tf present. Fixes (#12)-w flag to specify a workspace when commenting now
atlantis plan staging, now: atlantis plan -w stagingatlantis plan -target=resource, now: atlantis plan -- -target=resourceplan in the parent directory of modules/ unless there is a main.tf in that directory.GitLab custom URL for GitLab Enterprise installations now works
Use env instead of workspace for Terraform 0.9.*
None
env instead of workspace for Terraform 0.9.*None
Terraform 0.11 is now supported
None
WORKSPACE => DIR - this is the absolute path to the project directory on diskENVIRONMENT => WORKSPACE - this is the name of the Terraform workspace that we're running in (ex. default)~/.atlantis/atlantis.db file.
This is safe to do because you'll just need to re-run plan to get your plan back.Don't ignore changes in modules directories anymore.
## Features * GitLab is now supported! (#190) * Slack notifications. (#199) ## Bug Fixes None ## Backwards Incompatibilities / Notes: None ## Download
None
None
Environment variables are passed through to extra_arguments.
extra_arguments. (#150)None
all flags passed to atlantis plan or atlantis apply will now be passed through to terraform.
--aws-assume-role-arn and --aws-region flags removed. Instead, to name the assume role session with the GitHub username of the user running the Atlant
--aws-assume-role-arn and --aws-region flags removed. Instead, to name the
assume role session with the GitHub username of the user running the Atlantis command
use the atlantis_user terraform variable alongside Terraform's
built-in support for assume role
(see https://github.com/runatlantis/atlantis/blob/main/README.md#assume-role-session-names)docker run runatlantis/atlantis:v0.1.1 server --gh-user=GITHUB_USERNAME --gh-token=GITHUB_TOKEN
post_plan and post_apply commands (#102)Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →