Server Configuration
This page explains how to configure the atlantis server command.
Configuration to atlantis server can be specified via command line flags, environment variables, a config file or a mix of the three.
Environment Variables
All flags can be specified as environment variables.
- Take the flag name, ex.
--gh-user - Ignore the first
--=>gh-user - Convert the
-'s to_'s =>gh_user - Uppercase all the letters =>
GH_USER - Prefix with
ATLANTIS_=>ATLANTIS_GH_USER
NOTE
To set a boolean flag use true or false as the value.
NOTE
The flag --atlantis-url is set by the environment variable ATLANTIS_ATLANTIS_URL NOT ATLANTIS_URL.
Config File
All flags can also be specified via a YAML config file.
To use a YAML config file, run atlantis server --config /path/to/config.yaml.
The keys of your config file should be the same as the flag names, ex.
gh-token: ...
log-level: ...WARNING
The config file you pass to --config is different from the --repo-config file. The --config config file is only used as an alternate way of setting atlantis server flags.
Precedence
Values are chosen in this order:
- Flags
- Environment Variables
- Config File
Flags
--allow-commands
atlantis server --allow-commands=version,plan,apply,unlock,approve_policies,cancel
# or
ATLANTIS_ALLOW_COMMANDS='version,plan,apply,unlock,approve_policies,cancel'List of allowed commands to be run on the Atlantis server, Defaults to version,plan,apply,unlock,approve_policies,cancel
Notes:
- Accepts a comma separated list, ex.
command1,command2. version,plan,apply,unlock,approve_policies,cancel,import,state,policy_checkandallare available.policy_checkis an internal command that runs automatically afterplanwhen policy checking is enabled. It must be explicitly allowlisted when using--gh-team-allowlist.allis a special keyword that allows all commands. If passallthen all other commands will be ignored.
--allow-draft-prs
atlantis server --allow-draft-prs
# or
ATLANTIS_ALLOW_DRAFT_PRS=trueRespond to pull requests from draft prs. Defaults to false.
--allow-fork-prs
atlantis server --allow-fork-prs
# or
ATLANTIS_ALLOW_FORK_PRS=trueRespond to pull requests from forks. Defaults to false.
SECURITY WARNING
Potentially dangerous to enable because if attackers can create a pull request to your repo then they can cause Atlantis to run arbitrary code. This can happen because Atlantis will automatically run terraform plan which can run arbitrary code if given a malicious Terraform configuration.
Independently of this flag, Atlantis only runs commands for a pull request whose head repository is on the same host as its base repository.
Behavior change
Previously, Atlantis did not compare the hosts of the head and base repositories. Now, if the head repository's clone URL host differs from the base repository's (case-insensitive), or has no host, Atlantis does not run the command and posts no comment. Look for the server log line head repo host "<head>" does not match base repo host "<base>", not running command. For GitHub, see also --gh-hostname.
--api-secret
atlantis server --api-secret="secret"
# or (recommended)
ATLANTIS_API_SECRET="secret"Required secret used to validate requests made to the /api/* endpoints.
When set, it is also required by the read-only GET /api/locks endpoint.
--atlantis-url
atlantis server --atlantis-url="https://my-domain.com:9090/basepath"
# or
ATLANTIS_ATLANTIS_URL=https://my-domain.com:9090/basepathSpecify the URL that Atlantis is accessible from. Used in the Atlantis UI and in links from pull request comments. Defaults to http://$(hostname):$port where $port is from the --port flag. Supports a basepath if you're hosting Atlantis under a path.
Notes:
- If a load balancer with a non http/https port (not the one defined in the
--portflag) is used, update the URL to include the port like in the example above. - This URL is used as the
detailslink next to each atlantis job to view the job's logs.
--autodiscover-mode
atlantis server --autodiscover-mode="<auto|enabled|disabled>"
# or
ATLANTIS_AUTODISCOVER_MODE="<auto|enabled|disabled>"Sets auto discover mode, default is auto. When set to auto, projects in a repo will be discovered by Atlantis when there are no projects configured in the repo config. If one or more projects are defined in the repo config then auto discovery will be completely disabled.
When set to enabled projects will be discovered unconditionally. If an auto discovered project is already defined in the projects section of the repo config, the project from the repo config will take precedence over the auto discovered project.
When set to disabled projects will never be discovered, even if there are no projects configured in the repo config.
--automerge
atlantis server --automerge
# or
ATLANTIS_AUTOMERGE=trueAutomatically merge pull requests after all plans have been successfully applied. Defaults to false. See Automerging for more details.
--automerge-method
atlantis server --automerge-method="squash"
# or
ATLANTIS_AUTOMERGE_METHOD="squash"Default merge method to use when automerging pull requests. Valid values are merge, rebase, and squash. When not set, the VCS provider's default merge method is used. This can be overridden per command with the --auto-merge-method comment flag. Currently only implemented for GitHub.
--autoplan-file-list
# NOTE: Use single quotes to avoid shell expansion of *.
atlantis server --autoplan-file-list='**/*.tf,project1/*.pkr.hcl'
# or
ATLANTIS_AUTOPLAN_FILE_LIST='**/*.tf,project1/*.pkr.hcl'List of file patterns that Atlantis will use to check if a directory contains modified files that should trigger project planning.
Notes:
- Accepts a comma separated list, ex.
pattern1,pattern2. - Patterns use the
.dockerignoresyntax - List of file patterns will be used by both automatic and manually run plans.
- When not set, defaults to all
.tf,.tf.json,.tfvars,.tfvars.json,.tofu,.tofu.json,terragrunt.hcland.terraform.lock.hclfiles (--autoplan-file-list='**/*.tf,**/*.tf.json,**/*.tfvars,**/*.tfvars.json,**/*.tofu,**/*.tofu.json,**/terragrunt.hcl,**/.terraform.lock.hcl'). - Setting
--autoplan-file-listwill override the defaults. You must add**/*.tfand other defaults if you want to include them. - The default is global (not distribution-aware). Both Terraform and OpenTofu installs will match
.tofuchanges. If you do not use OpenTofu, you can override the default to exclude.tofupatterns. - A custom Workflow that uses autoplan
when_modifiedwill ignore this value.
Examples:
- Autoplan when any
*.tfor*.tfvarsfile is modified.--autoplan-file-list='**/*.tf,**/*.tfvars'
- Autoplan when any
*.tffile is modified except inproject2/directory--autoplan-file-list='**/*.tf,!project2'
- Autoplan when any
*.tffiles or.ymlfiles in subfolder ofproject1is modified.--autoplan-file-list='**/*.tf,project1/**/*.yml'
NOTE
By default, changes to modules will not trigger autoplanning. See the flags below.
--autoplan-modules
atlantis server --autoplan-modules
# or
ATLANTIS_AUTOPLAN_MODULES=trueDefaults to false. When set to true, Atlantis will trace the local modules of included projects. Included project are projects with files included by --autoplan-file-list. After tracing, Atlantis will plan any project that includes a changed module. This is equivalent to setting --autoplan-modules-from-projects to the value of --autoplan-file-list. See below.
NOTE
Module dependency indexing uses Terraform config inspection and may not fully support .tofu / .tofu.json files. Module calls defined only in .tofu files or shared module directories containing only .tofu files may not be traced. Direct file-change autoplanning for .tofu projects works regardless. Use explicit autoplan.when_modified patterns as a workaround. See OpenTofu .tofu file support for details.
--autoplan-modules-from-projects
atlantis server --autoplan-modules-from-projects='**/init.tf'
# or
ATLANTIS_AUTOPLAN_MODULES_FROM_PROJECTS='**/init.tf'Enables auto-planing of projects when a module dependency in the same repository has changed. This is a list of file patterns like autoplan-file-list.
These patterns select projects to index based on the files matched. The index maps modules to the projects that depends on them, including projects that include the module via other modules. When a module file matching autoplan-file-list changes, all indexed projects will be planned.
Current default is "" (disabled).
Examples:
**/*.tf- will index all projects that have a.tffile in their directory, and plan them whenever an in-repo module dependency has changed.**/*.tf,!foo,!bar- will index all projects containing.tfexceptfooandbarand plan them whenever an in-repo module dependency has changed. This allows projects to opt-out of auto-planning when a module dependency changes.
NOTE
Modules that are not selected by autoplan-file-list will not be indexed and dependant projects will not be planned. This flag allows the projects to index to be selected, but the trigger for a plan must be a file in autoplan-file-list.
NOTE
This flag overrides --autoplan-modules. If you wish to disable auto-planning of modules, set this flag to an empty string, and set --autoplan-modules to false.
--azuredevops-hostname
atlantis server --azuredevops-hostname="dev.azure.com"
# or
ATLANTIS_AZUREDEVOPS_HOSTNAME="dev.azure.com"Azure DevOps hostname to support cloud and self-hosted instances. Defaults to dev.azure.com.
COMPATIBILITY WARNING
If you are affected by this change docs or this issue both Service Hooks (v1 & v2) will convert the AD Organization name to lowercase: Examples: https://dev.azure.com/MYCompany/ & https://mycompany.visualstudio.com/ will be converted to mycompanyhttps://dev.azure.com/MYCOMPANY/ & https://myCOMPANY.visualstudio.com/ will be converted to mycompany
This change will be applied from version v0.35.0
What to do if you have pending plans that were generated with a previous version? Running an atlantis unlock from v0.35.0 on your current PRs will ignore the files on the MYCompany folder. On the next atlantis plan will use the mycompany folder and generate everything in the new folder name
--azuredevops-token
atlantis server --azuredevops-token="RandomStringProducedByAzureDevOps"
# or (recommended)
ATLANTIS_AZUREDEVOPS_TOKEN="RandomStringProducedByAzureDevOps"Azure DevOps token of API user.
--azuredevops-user
atlantis server --azuredevops-user="username@example.com"
# or
ATLANTIS_AZUREDEVOPS_USER="username@example.com"Azure DevOps username of API user.
--azuredevops-webhook-password
atlantis server --azuredevops-webhook-password="password123"
# or (recommended)
ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD="password123"Azure DevOps basic authentication password for inbound webhooks (see docs).
SECURITY WARNING
If not specified, Atlantis won't be able to validate that the incoming webhook call came from your Azure DevOps org. This means that an attacker could spoof calls to Atlantis and cause it to perform malicious actions. Should be specified via the ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD environment variable.
--azuredevops-webhook-user
atlantis server --azuredevops-webhook-user="username@example.com"
# or
ATLANTIS_AZUREDEVOPS_WEBHOOK_USER="username@example.com"Azure DevOps basic authentication username for inbound webhooks.
--bitbucket-api-user
atlantis server --bitbucket-api-user="apiuser@example.com"
# or
ATLANTIS_BITBUCKET_API_USER="apiuser@example.com"Bitbucket username (usually an email) used for API authentication with Bitbucket Cloud. This is used for API calls only. If not specified, Atlantis will use the value of --bitbucket-user for API authentication to maintain backward compatibility.
Note:
- The backward compatibility is for supporting the existing Bitbucket APP Passwords that are still valid until June 2026 (see Atlassian's Bitbucket app password deprecation notice).
Config file key:
bitbucket-api-user: apiuser@example.comEnvironment variable: ATLANTIS_BITBUCKET_API_USER
Note: This flag is only relevant for Bitbucket Cloud (bitbucket.org) integrations.
--bitbucket-base-url
atlantis server --bitbucket-base-url="http://bitbucket.corp:7990/basepath"
# or
ATLANTIS_BITBUCKET_BASE_URL="http://bitbucket.corp:7990/basepath"Base URL of Bitbucket Server (aka Stash) installation. Must include http:// or https://. If using Bitbucket Cloud (bitbucket.org), do not set. Defaults to https://api.bitbucket.org.
--bitbucket-token
atlantis server --bitbucket-token="token"
# or (recommended)
ATLANTIS_BITBUCKET_TOKEN="token"Bitbucket app password of API user.
--bitbucket-user
atlantis server --bitbucket-user="myuser"
# or
ATLANTIS_BITBUCKET_USER="myuser"Bitbucket username used for git operations. For Bitbucket Cloud, if --bitbucket-api-user is not specified, this value will also be used for API authentication.
--bitbucket-webhook-secret
atlantis server --bitbucket-webhook-secret="secret"
# or (recommended)
ATLANTIS_BITBUCKET_WEBHOOK_SECRET="secret"Secret used to validate Bitbucket webhooks.
SECURITY WARNING
If not specified, Atlantis won't be able to validate that the incoming webhook call came from Bitbucket. This means that an attacker could spoof calls to Atlantis and cause it to perform malicious actions.
--blocked-extra-args
atlantis server --blocked-extra-args="-lock-timeout,-parallelism"
# or
ATLANTIS_BLOCKED_EXTRA_ARGS='-lock-timeout,-parallelism'Comma-separated list of additional Terraform CLI flags that are not allowed in comment extra args (the flags after --). These flags are always blocked, whether or not this flag is set: -chdir,-plugin-dir,-out,-generate-config-out,-state,-state-out,-backup.
Notes:
-chdirand-plugin-dirare blocked because they move Terraform's working directory or provider source to a location the commenter controls.-out,-generate-config-out,-state,-state-outand-backupare blocked because they make Terraform write a file, or read state, at a path the commenter chooses. Atlantis manages the plan and state file locations itself.- Setting this flag adds to the always-blocked list; it cannot unblock any of them.
- A comment that uses a blocked flag is rejected with
flag "<arg>" is not allowed in extra args. - To generate configuration for
importblocks, which needs-generate-config-out, define a server-side custom workflow whoseplanstep passes the flag inextra_args, for example- plan: {extra_args: ["-generate-config-out=generated.tf"]}, and select it for the project only while generating config. - A flag is matched by name, so listing
-lock-timeoutblocks-lock-timeout,--lock-timeout,-lock-timeout=VALUEand--lock-timeout=VALUE. You do not need to list both dash spellings. - Only comment extra args are checked. Flags set by the server operator, such as
extra_argsin a server-side workflow or in a repo-level workflow that the server allows, are passed to Terraform unchanged. - Accepts a comma separated list, ex.
-flag1,-flag2.
Behavior change
Previously, only -chdir and -plugin-dir were blocked by default, an entry matched only the dash spelling listed (-foo did not block --foo), and setting --blocked-extra-args replaced the defaults. Now -out, -generate-config-out, -state, -state-out and -backup are also always blocked, both dash spellings are matched, and --blocked-extra-args only adds flags. Comments such as atlantis plan -- -generate-config-out=generated.tf or atlantis state rm ADDRESS -- -backup=FILE now fail with flag "<arg>" is not allowed in extra args; move flags you still need into a server-side workflow's extra_args. An existing custom list keeps working and now also gets the built-in protections.
--checkout-depth
atlantis server --checkout-depth=0
# or
ATLANTIS_CHECKOUT_DEPTH=0The number of commits to fetch from the branch. Used if --checkout-strategy=merge since the --checkout-strategy=branch (default) checkout strategy always defaults to a shallow clone using a depth of 1. Defaults to 0. See Checkout Strategy for more details.
--checkout-strategy
atlantis server --checkout-strategy="<branch|merge>"
# or
ATLANTIS_CHECKOUT_STRATEGY="<branch|merge>"How to check out pull requests. Use either branch or merge. Defaults to branch. See Checkout Strategy for more details.
--config
atlantis server --config="my/config/file.yaml"
# or
ATLANTIS_CONFIG="my/config/file.yaml"YAML config file where flags can also be set. See Config File for more details.
--data-dir
atlantis server --data-dir="path/to/data/dir"
# or
ATLANTIS_DATA_DIR="path/to/data/dir"Directory where Atlantis will store its data. Will be created if it doesn't exist. Defaults to ~/.atlantis. Atlantis will store its database, checked out repos, Terraform plans by default, and downloaded Terraform binaries here. If Atlantis loses this directory, locks will be lost and unapplied plans will be lost.
Note that the atlantis user is restricted to ~/.atlantis. If you set the --data-dir flag to a path outside of Atlantis its home directory, ensure that you grant the atlantis user the correct permissions.
--default-tf-distribution
atlantis server --default-tf-distribution="terraform"
# or
ATLANTIS_DEFAULT_TF_DISTRIBUTION="terraform"Which TF distribution to use. Can be set to terraform or opentofu.
--default-tf-version
atlantis server --default-tf-version="v0.12.31"
# or
ATLANTIS_DEFAULT_TF_VERSION="v0.12.31"Terraform version to default to. Will download to <data-dir>/bin/terraform<version> if not in PATH. See Terraform Versions for more details.
Behavior change
Previously, the official Docker images put a bundled terraform on PATH, so the server started without this flag. Now the images ship no Terraform or OpenTofu binaries, and the server refuses to start with terraform not found in $PATH unless this flag is set. Set it (and --default-tf-distribution for OpenTofu) so Atlantis downloads that version, or mount or copy a binary onto PATH when downloads are blocked. See Image variants.
--disable-apply-all
atlantis server --disable-apply-all
# or
ATLANTIS_DISABLE_APPLY_ALL=trueDisable atlantis apply command so a specific project/workspace/directory has to be specified for applies.
--disable-automerge-label
atlantis server --disable-automerge-label="no-auto-merge"
# or
ATLANTIS_DISABLE_AUTOMERGE_LABEL="no-auto-merge"Disable atlantis automerge only on pull requests with the specified label. Defaults to an empty string, so no label disables automerge by default. This flag has no effect unless automerge is enabled with --automerge or repo-level automerge: true.
--disable-autoplan
atlantis server --disable-autoplan
# or
ATLANTIS_DISABLE_AUTOPLAN=trueDisable atlantis auto planning.
--disable-autoplan-label
atlantis server --disable-autoplan-label="no-autoplan"
# or
ATLANTIS_DISABLE_AUTOPLAN_LABEL="no-autoplan"Disable atlantis auto planning only on pull requests with the specified label.
If disable-autoplan property is true, this flag has no effect.
--disable-global-apply-lock
atlantis server --disable-global-apply-lock
# or
ATLANTIS_DISABLE_GLOBAL_APPLY_LOCK=trueIf true, removes button in the UI that allows users to globally disable apply commands.
--disable-markdown-folding
atlantis server --disable-markdown-folding
# or
ATLANTIS_DISABLE_MARKDOWN_FOLDING=trueDisable folding in markdown output using the <details> html tag.
--disable-repo-locking
atlantis server --disable-repo-locking
# or
ATLANTIS_DISABLE_REPO_LOCKING=trueStops atlantis from locking projects and or workspaces when running terraform.
--disable-unlock-label
atlantis server --disable-unlock-label do-not-unlock
# or
ATLANTIS_DISABLE_UNLOCK_LABEL="do-not-unlock"Stops atlantis from unlocking a pull request with this label. Defaults to "" (feature disabled).
--discard-approval-on-plan
atlantis server --discard-approval-on-plan
# or
ATLANTIS_DISCARD_APPROVAL_ON_PLAN=trueIf set, discard approval if a new plan has been executed. Currently only supported on GitHub and GitLab. For GitLab a bot, group or project token is required for this feature. Reference: reset-approvals-of-a-merge-request
--emoji-reaction
atlantis server --emoji-reaction eyes
# or
ATLANTIS_EMOJI_REACTION=eyesThe emoji reaction to use for marking processed comments. Currently supported on Gitea, GitHub and GitLab. If not specified, Atlantis will not use an emoji reaction. Defaults to "" (empty string).
--enable-diff-markdown-format
atlantis server --enable-diff-markdown-format
# or
ATLANTIS_ENABLE_DIFF_MARKDOWN_FORMAT=trueEnable Atlantis to format Terraform plan output into a markdown-diff friendly format for color-coding purposes.
Useful to enable for use with GitHub. Changed lines inside Terraform heredoc and multiline-string diffs are also formatted so diff-aware markdown renderers can color them.
--enable-drift-detection
atlantis server --enable-drift-detection
# or
ATLANTIS_ENABLE_DRIFT_DETECTION=trueEnable drift detection API endpoints. Drift detection does not run Terraform apply, but it does execute the normal plan lifecycle, including configured pre-workflow hooks, custom workflows, custom plan steps, and Terraform plan commands. When enabled, Atlantis will initialize in-memory storage for drift detection results and a remediation service, making drift detection, status, and plan-only remediation endpoints functional. If drift webhooks are configured (event: drift), successful detection runs send notifications to Slack or HTTP endpoints, including no-drift heartbeat results. Drift detection does not bypass team allowlists or PR-state plan_requirements such as approved or mergeable; those checks fail closed when they cannot be evaluated outside a pull request. Destructive drift remediation apply actions also require --enable-drift-remediation. Defaults to false.
--enable-drift-remediation
atlantis server --enable-drift-detection --enable-drift-remediation
# or
ATLANTIS_ENABLE_DRIFT_DETECTION=true
ATLANTIS_ENABLE_DRIFT_REMEDIATION=trueEnable destructive drift remediation apply actions on the /api/drift/remediate endpoint. This flag requires --enable-drift-detection; without it, action: "apply" requests are rejected while read-only drift detection remains available. This flag does not bypass repository apply_requirements; requirements that need pull request state fail closed for non-PR remediation requests. Defaults to false.
--enable-external-stores
atlantis server --enable-external-stores
# or
ATLANTIS_ENABLE_EXTERNAL_STORES=trueEnable external storage backends configured in the server-side repo config (external_stores block). When set, Atlantis reads the external_stores section from the repo config YAML to initialize backends such as S3 for plan file persistence.
--enable-policy-checks
atlantis server --enable-policy-checks
# or
ATLANTIS_ENABLE_POLICY_CHECKS=trueEnables atlantis to run server side policies on the result of a terraform plan. Policies are defined in server side repo config.
--enable-profiling-api
atlantis server --enable-profiling-api
# or
ATLANTIS_ENABLE_PROFILING_API=trueEnable net/http/pprof endpoints for continuous profiling of resources used by the server. See profiling Go programs for more information.
--enable-regexp-cmd
atlantis server --enable-regexp-cmd
# or
ATLANTIS_ENABLE_REGEXP_CMD=trueEnable Atlantis to use regular expressions to run plan/apply commands against defined project names when -p flag is passed with it.
This can be used to run all defined projects (with the name key) in atlantis.yaml using atlantis plan -p .*.
The flag will only allow the regexes listed in the allowed_regexp_prefixes key defined in the repo atlantis.yaml file. If the key is undefined, its value defaults to [] which will allow any regex.
This will not work with -d yet and to use -p the repo projects must be defined in the repo atlantis.yaml file.
When --restrict-file-list is enabled, regex project plans are limited to matching projects with files modified in the pull request. Without --restrict-file-list, regex project commands can still run against all matching projects.
SECURITY WARNING
It's not supposed to be used with --disable-apply-all. The command atlantis apply -p .* will bypass the restriction and run apply on every project.
--executable-name
atlantis server --executable-name="atlantis"
# or
ATLANTIS_EXECUTABLE_NAME="atlantis"Comment command trigger executable name. Defaults to atlantis.
This is useful when running multiple Atlantis servers against a single repository.
Note: the "did you mean" misspelling warning only applies to the default executable name (atlantis). If you set a custom --executable-name, Atlantis won't warn about comments that are Levenshtein-close to it — this avoids spurious warnings when multiple servers with similar names (e.g. atlantis-dev and atlantis-prod) receive the same comment.
--fail-on-pre-workflow-hook-error
atlantis server --fail-on-pre-workflow-hook-error
# or
ATLANTIS_FAIL_ON_PRE_WORKFLOW_HOOK_ERROR=trueFail and do not run the requested Atlantis command if any of the pre workflow hooks error.
--gh-allow-mergeable-bypass-apply
atlantis server --gh-allow-mergeable-bypass-apply
# or
ATLANTIS_GH_ALLOW_MERGEABLE_BYPASS_APPLY=trueFeature flag to enable ability to use mergeable mode with required apply status check.
--gh-app-id
atlantis server --gh-app-id="00000"
# or
ATLANTIS_GH_APP_ID="00000"GitHub app ID. If set, GitHub authentication will be performed as an installation.
TIP
A GitHub app can be created by starting Atlantis first, then pointing your browser at
$(hostname)/github-app/setupYou'll be redirected to GitHub to create a new app, and will then be redirected to
$(hostname)/github-app/exchange-code?code=some-codeAfter which Atlantis will display your new app's credentials: your app's ID, its generated --gh-webhook-secret and the contents of the file for --gh-app-key-file. Update your Atlantis config accordingly, and restart the server.
--gh-app-installation-id
atlantis server --gh-app-installation-id="123"
# or
ATLANTIS_GH_APP_INSTALLATION_ID="123"The installation ID of a specific instance of a GitHub application. Normally this value is derived by querying GitHub for the list of installations of the ID supplied via --gh-app-id and selecting the first one found and where multiple installations results in an error. Use this flag if you have multiple instances of Atlantis but you want to use a single already-installed GitHub app for all of them. You would normally do this if you are running a proxy as your single GitHub application that will proxy to an appropriate Atlantis instance based on the organization or user that triggered the webhook.
--gh-app-key
atlantis server --gh-app-key="-----BEGIN RSA PRIVATE KEY-----(...)"
# or
ATLANTIS_GH_APP_KEY="-----BEGIN RSA PRIVATE KEY-----(...)"The PEM encoded private key for the GitHub App.
SECURITY WARNING
The contents of the private key will be visible by anyone that can run ps or look at the shell history of the machine where Atlantis is running. Use --gh-app-key-file to mitigate that risk.
--gh-app-key-file
atlantis server --gh-app-key-file="path/to/app-key.pem"
# or
ATLANTIS_GH_APP_KEY_FILE="path/to/app-key.pem"Path to a GitHub App PEM encoded private key file. If set, GitHub authentication will be performed as an installation.
--gh-app-slug
atlantis server --gh-app-slug="myappslug"
# or
ATLANTIS_GH_APP_SLUG="myappslug"A slugged version of GitHub app name shown in pull requests comments, etc (not Atlantis App but something like atlantis-app). Atlantis uses the value of this parameter to identify the comments it has left on GitHub pull requests. This is used for functions such as --hide-prev-plan-comments. You need to obtain this value from your GitHub app, one way is to go to your App settings and open "Public page" from the left sidebar. Your --gh-app-slug value will be the last part of the URL, e.g https://github.com/apps/<slug>.
--gh-hostname
atlantis server --gh-hostname="my.github.enterprise.com"
# or
ATLANTIS_GH_HOSTNAME="my.github.enterprise.com"Hostname of your GitHub Enterprise installation. If using GitHub.com, don't set. Defaults to github.com.
For GitHub Enterprise Cloud, use the tenant hostname, for example tenant.ghe.com. Do not include a scheme or an api. prefix; Atlantis derives the REST and GraphQL API endpoints from the hostname.
Atlantis requires the clone URL of every GitHub repository it receives, in webhooks or from the GitHub API, to be on this host. The comparison ignores case and ports.
Behavior change
Previously, Atlantis checked only the path of a GitHub clone URL (/owner/repo.git) and accepted any host. Now the clone URL host of both the base and head repository must equal --gh-hostname, and a clone URL with no host is rejected. A mismatched pull request webhook is answered with HTTP 400 and the body contains expected clone url host "<gh-hostname>" but had "<host>"; nothing is planned. If you run GitHub Enterprise, set --gh-hostname to the host that appears in your repositories' clone URLs (the clone_url field in webhook payloads), and check webhook deliveries in GitHub for 400 responses after upgrading.
--gh-org
atlantis server --gh-org="myorgname"
# or
ATLANTIS_GH_ORG="myorgname"GitHub organization name. Set to enable creating a private GitHub app for this organization.
--gh-team-allowlist
atlantis server --gh-team-allowlist="myteam:plan, secteam:apply, devops-team:apply, devops-team:import"
# or
ATLANTIS_GH_TEAM_ALLOWLIST="myteam:plan, secteam:apply, devops-team:apply, devops-team:import"In versions v0.35.0 and later, the GitHub team name can only be a slug because it is immutable.
In versions between v0.21.0 and v0.34.0, the GitHub team name can be a name or a slug.
In versions v0.20.1 and below, the GitHub team name required the case sensitive team name.
Comma-separated list of GitHub teams and permission pairs.
By default, any team can plan and apply.
GitHub team hierarchy is honored. If an allowlisted team has child teams, members of those child teams inherit the parent team's allowed commands.
TIP
If you are using policy checking, you must also allowlist the policy_check command for it to work on manual atlantis plan commands:
atlantis server --gh-team-allowlist="*:plan,*:policy_check,myteam:apply"See Policy Checking documentation for more details.
--gh-token
atlantis server --gh-token="token"
# or (recommended)
ATLANTIS_GH_TOKEN="token"GitHub token of API user.
--gh-token-file
atlantis server --gh-token-file="/path/to/token"
# or
ATLANTIS_GH_TOKEN_FILE="/path/to/token"GitHub token of API user. The token is loaded from disk regularly to allow for rotation of the token without the need to restart the Atlantis server.
--gh-user
atlantis server --gh-user="myuser"
# or
ATLANTIS_GH_USER="myuser"GitHub username of API user. This user is also used by the flag --hide-user-plan-comments and will need to be updated if migrating to github EMU.
--gh-webhook-secret
atlantis server --gh-webhook-secret="secret"
# or (recommended)
ATLANTIS_GH_WEBHOOK_SECRET="secret"Secret used to validate GitHub webhooks (see GitHub: Validating webhook deliveries).
SECURITY WARNING
If not specified, Atlantis won't be able to validate that the incoming webhook call came from GitHub. This means that an attacker could spoof calls to Atlantis and cause it to perform malicious actions.
--gitea-base-url
atlantis server --gitea-base-url="http://your-gitea.corp:7990/basepath"
# or
ATLANTIS_GITEA_BASE_URL="http://your-gitea.corp:7990/basepath"Base URL of Gitea installation. Must include http:// or https://. Defaults to https://gitea.com if left empty/absent.
--gitea-page-size
atlantis server --gitea-page-size=30
# or (recommended)
ATLANTIS_GITEA_PAGE_SIZE=30Number of items on a single page in Gitea paged responses.
Configuration dependent
The default value conforms to the Gitea server's standard config setting: DEFAULT_PAGING_NUM The highest valid value depends on the Gitea server's config setting: MAX_RESPONSE_ITEMS
--gitea-token
atlantis server --gitea-token="token"
# or (recommended)
ATLANTIS_GITEA_TOKEN="token"Gitea app password of API user.
--gitea-user
atlantis server --gitea-user="myuser"
# or
ATLANTIS_GITEA_USER="myuser"Gitea username of API user.
--gitea-webhook-secret
atlantis server --gitea-webhook-secret="secret"
# or (recommended)
ATLANTIS_GITEA_WEBHOOK_SECRET="secret"Secret used to validate Gitea webhooks.
SECURITY WARNING
If not specified, Atlantis won't be able to validate that the incoming webhook call came from Gitea. This means that an attacker could spoof calls to Atlantis and cause it to perform malicious actions.
--gitlab-group-allowlist
atlantis server --gitlab-group-allowlist="myorg/mygroup:plan, myorg/secteam:apply, myorg/devops:apply, myorg/devops:import"
# or
ATLANTIS_GITLAB_GROUP_ALLOWLIST="myorg/mygroup:plan, myorg/secteam:apply, myorg/devops:apply, myorg/devops:import"Comma-separated list of GitLab groups and permission pairs.
By default, any group can plan and apply.
NOTE
Atlantis needs to be able to view the listed group members, inaccessible or non-existent groups are silently ignored.
--gitlab-hostname
atlantis server --gitlab-hostname="my.gitlab.enterprise.com"
# or
ATLANTIS_GITLAB_HOSTNAME="my.gitlab.enterprise.com"Hostname of your GitLab Enterprise installation. If using GitLab.com, don't set. Defaults to gitlab.com.
--gitlab-status-retry-enabled
atlantis server --gitlab-status-retry-enabled
# or
ATLANTIS_GITLAB_STATUS_RETRY_ENABLED=trueEnable enhanced retry logic for GitLab pipeline status updates with exponential backoff.
Defaults to false.
--gitlab-token
atlantis server --gitlab-token="token"
# or (recommended)
ATLANTIS_GITLAB_TOKEN="token"GitLab token of API user.
--gitlab-user
atlantis server --gitlab-user="myuser"
# or
ATLANTIS_GITLAB_USER="myuser"GitLab username of API user.
--gitlab-webhook-secret
atlantis server --gitlab-webhook-secret="secret"
# or (recommended)
ATLANTIS_GITLAB_WEBHOOK_SECRET="secret"Secret used to validate GitLab webhooks.
SECURITY WARNING
If not specified, Atlantis won't be able to validate that the incoming webhook call came from GitLab. This means that an attacker could spoof calls to Atlantis and cause it to perform malicious actions.
--help
atlantis server --helpView help.
--hide-prev-plan-comments
atlantis server --hide-prev-plan-comments
# or
ATLANTIS_HIDE_PREV_PLAN_COMMENTS=trueHide previous plan comments to declutter PRs. This is only supported in GitHub and GitLab and Bitbucket currently and is not enabled by default.
For Bitbucket, the comments are deleted rather than hidden as Bitbucket does not support hiding comments.
For GitHub, ensure the --gh-user is set appropriately or comments will not be hidden.
When using the GitHub App, you need to set --gh-app-slug to enable this feature.
--hide-unchanged-plan-comments
atlantis server --hide-unchanged-plan-comments
# or
ATLANTIS_HIDE_UNCHANGED_PLAN_COMMENTS=trueRemove no-changes plan comments from the pull request.
This is useful when you have many projects and want to keep the pull request clean from useless comments.
--ignore-vcs-status-names
atlantis server --ignore-vcs-status-names="status1,status2"
# or
ATLANTIS_IGNORE_VCS_STATUS_NAMES=status1,status2Comma separated list of VCS status names from other atlantis services. When gh-allow-mergeable-bypass-apply is true, will ignore status checks (e.g. status1/plan, status1/apply, status2/plan, status2/apply) from other Atlantis services when checking if the PR is mergeable. Currently only implemented for GitHub.
--include-git-untracked-files
atlantis server --include-git-untracked-files
# or
ATLANTIS_INCLUDE_GIT_UNTRACKED_FILES=trueInclude git untracked files in the Atlantis modified file list. Used for example with CDK Terrain pre-workflow hooks that dynamically generate Terraform files.
--language
atlantis server --language="en"
# or
ATLANTIS_LANGUAGE="en"Language used for Atlantis pull request comments. Defaults to en.
Supported values:
en(English)es(Spanish)
Atlantis normalizes locale-style values (for example es-MX resolves to es). If an unsupported language is configured and --language-config-file is not set, Atlantis returns a validation error at startup.
Built-in language strings are loaded from:
server/i18n/locales/en.yamlserver/i18n/locales/es.yaml
--language-config-file
atlantis server --language="de" --language-config-file="/etc/atlantis/language.yaml"
# or
ATLANTIS_LANGUAGE_CONFIG_FILE="/etc/atlantis/language.yaml"Optional path to a custom YAML language catalog. Values in this file override the selected built-in language, and partial overrides are supported.
When --language-config-file is set, unsupported --language values are allowed and Atlantis falls back to built-in English for unspecified strings.
Expected YAML schema:
pull_request_label: Pull Request (custom)
merge_request_label: Merge Request (custom)
command_titles:
plan: Plan (custom)
apply: Apply (custom)For complete markdown wording customization, keep using --markdown-template-overrides-dir.
--locking-db-type
atlantis server --locking-db-type="<boltdb|redis>"
# or
ATLANTIS_LOCKING_DB_TYPE="<boltdb|redis>"The locking database type to use for storing plan and apply locks. Defaults to boltdb.
Notes:
- If set to
boltdb, only one process may have access to the boltdb instance. - If set to
redis, use--redis-hostand--redis-portfor single-node mode, or--redis-cluster-addressesfor Redis Cluster mode. Use--redis-passwordand (optionally)--redis-usernameonly if your Redis deployment requires authentication.
--log-level
atlantis server --log-level="<debug|info|warn|error>"
# or
ATLANTIS_LOG_LEVEL="<debug|info|warn|error>"Log level. Defaults to info.
--markdown-template-overrides-dir
atlantis server --markdown-template-overrides-dir="path/to/templates/"
# or
ATLANTIS_MARKDOWN_TEMPLATE_OVERRIDES_DIR="path/to/templates/"This will be available in v0.21.0.
Directory where Atlantis will read in overrides for markdown templates used to render comments on pull requests. Markdown template overrides may be specified either in individual files, or all together in a single file. All template override files must have the .tmpl extension, otherwise they will not be parsed.
Markdown templates which may have overrides can be found markdown templates directory
Please be mindful that settings like --enable-diff-markdown-format depend on logic defined in the templates. It is possible to diverge from expected behavior, if care is not taken when overriding default templates.
Defaults to the atlantis home directory /home/atlantis/.markdown_templates/ in /$HOME/.markdown_templates.
--max-comments-per-command
atlantis server --max-comments-per-command=100
# or
ATLANTIS_MAX_COMMENTS_PER_COMMAND=100Limit the number of comments published after a command is executed, to prevent spamming your VCS and Atlantis to get throttled as a result. Defaults to 100. Set this option to 0 to disable log truncation. Note that the truncation will happen on the top of the command output, to preserve the most important parts of the output, often displayed at the end.
When command output exceeds the VCS comment size limit (or when this limit applies), Atlantis splits the output into multiple comments using intelligent comment splitting. Split points are chosen so that markdown structure is preserved: the splitter detects whether it is inside a code block (```), a <details> block, or inline code (`), and inserts appropriate closing and continuation markers so that each comment renders correctly. Continuation comments are labeled with the command name (e.g. "Continued plan output from previous comment") when available.
--parallel-apply
atlantis server --parallel-apply
# or
ATLANTIS_PARALLEL_APPLY=trueWhether to run apply operations in parallel. Defaults to false. Explicit declaration in repo config takes precedence.
--parallel-plan
atlantis server --parallel-plan
# or
ATLANTIS_PARALLEL_PLAN=trueWhether to run plan operations in parallel. Defaults to false. Explicit declaration in repo config takes precedence.
--parallel-pool-size
atlantis server --parallel-pool-size=100
# or
ATLANTIS_PARALLEL_POOL_SIZE=100Max size of the wait group that runs parallel plans and applies (if enabled). Defaults to 15
The limit is per command: it also caps the projects of one API plan or drift detection request that plan at once.
--pending-apply-status
atlantis server --pending-apply-status
# or (recommended)
ATLANTIS_PENDING_APPLY_STATUS=trueSet the commit status to pending when there are planned changes that haven't been applied. This prevents merge requests from being merged until all Terraform applies are completed if you have Pipelines must succeed enabled on your repository.
When enabled, after running atlantis plan, the MR status will show as pending if there are changes to apply. Once all projects are successfully applied (or show no changes), the status will update to success. Projects with no Terraform changes are counted as up to date rather than applied. If a pull request has both up-to-date projects and projects still waiting to apply, the Atlantis apply commit status remains pending until all changed projects are applied.
Defaults to false.
Only supported on GitLab
--port
atlantis server --port=4141
# or
ATLANTIS_PORT=4141Port to bind to. Defaults to 4141.
--quiet-policy-checks
atlantis server --quiet-policy-checks
# or
ATLANTIS_QUIET_POLICY_CHECKS=trueExclude policy check comments from pull requests unless there's an actual error from conftest. This also excludes warnings. Defaults to false.
--redis-cluster-addresses
atlantis server --redis-cluster-addresses="redis-node-0:6379,redis-node-1:6379,redis-node-2:6379"
# or
ATLANTIS_REDIS_CLUSTER_ADDRESSES="redis-node-0:6379,redis-node-1:6379,redis-node-2:6379"Comma-delimited list of Redis cluster node addresses in the format host:port. When set, Atlantis uses Redis Cluster mode instead of single-node mode. This is mutually exclusive with --redis-host/--redis-port (which are used for single-node mode).
--redis-db
atlantis server --redis-db=0
# or
ATLANTIS_REDIS_DB=0The Redis Database to use when using a Locking DB type of redis. Defaults to 0.
--redis-host
atlantis server --redis-host="localhost"
# or
ATLANTIS_REDIS_HOST="localhost"The Redis Hostname for when using a Locking DB type of redis.
--redis-insecure-skip-verify
atlantis server --redis-insecure-skip-verify=false
# or
ATLANTIS_REDIS_INSECURE_SKIP_VERIFY=falseControls whether the Redis client verifies the Redis server's certificate chain and host name. If true, accepts any certificate presented by the server and any host name in that certificate. Defaults to false.
SECURITY WARNING
If this is enabled, TLS is susceptible to machine-in-the-middle attacks unless custom verification is used.
--redis-password
atlantis server --redis-password="password123"
# or (recommended)
ATLANTIS_REDIS_PASSWORD="password123"The Redis Password for when using a Locking DB type of redis.
--redis-port
atlantis server --redis-port=6379
# or
ATLANTIS_REDIS_PORT=6379The Redis Port for when using a Locking DB type of redis. Defaults to 6379.
--redis-tls-enabled
atlantis server --redis-tls-enabled=false
# or
ATLANTIS_REDIS_TLS_ENABLED=falseEnables a TLS connection, with min version of 1.2, to Redis when using a Locking DB type of redis. Defaults to false.
--redis-username
atlantis server --redis-username="myuser"
# or
ATLANTIS_REDIS_USERNAME="myuser"The Redis Username for when using a Locking DB type of redis. Useful when Redis is configured with ACL-based authentication.
--repo-allowlist
# NOTE: Use single quotes to avoid shell expansion of *.
atlantis server --repo-allowlist='github.com/myorg/*'
# or
ATLANTIS_REPO_ALLOWLIST='github.com/myorg/*'Atlantis requires you to specify an allowlist of repositories it will accept webhooks from.
Notes:
- Accepts a comma separated list, ex.
definition1,definition2 - Format is
{hostname}/{owner}/{repo}, ex.github.com/runatlantis/atlantis *matches any characters, ex.github.com/runatlantis/*will match all repos in the runatlantis organization- An entry beginning with
!negates it, ex.github.com/foo/*,!github.com/foo/barwill match all github repos in thefooowner exceptbar. - For Bitbucket Server:
{hostname}is the domain without scheme and port,{owner}is the name of the project (not the key), and{repo}is the repo name- User (not project) repositories take on the format:
{hostname}/{full name}/{repo}(e.g.,bitbucket.example.com/Jane Doe/myatlantisfor usernamejdoeand full nameJane Doe, which is not very intuitive)
- User (not project) repositories take on the format:
- For Azure DevOps the allowlist takes one of two forms:
{owner}.visualstudio.com/{owner}/{project}/{repo}ordev.azure.com/{owner}/{project}/{repo} - Microsoft is in the process of changing Azure DevOps to the latter form, so it may be safest to always specify both formats in your repo allowlist for each repository until the change is complete.
Examples:
- Allowlist
myorg/repo1andmyorg/repo2ongithub.com--repo-allowlist=github.com/myorg/repo1,github.com/myorg/repo2
- Allowlist all repos under
myorgongithub.com--repo-allowlist='github.com/myorg/*'
- Allowlist all repos under
myorgongithub.com, excludingmyorg/untrusted-repo--repo-allowlist='github.com/myorg/*,!github.com/myorg/untrusted-repo'
- Allowlist all repos in my GitHub Enterprise installation
--repo-allowlist='github.yourcompany.com/*'
- Allowlist all repos under
myorgprojectmyprojecton Azure DevOps--repo-allowlist='myorg.visualstudio.com/myorg/myproject/*,dev.azure.com/myorg/myproject/*'
- Allowlist all repositories
--repo-allowlist='*'
--repo-config
atlantis server --repo-config="path/to/repos.yaml"
# or
ATLANTIS_REPO_CONFIG="path/to/repos.yaml"Path to a YAML server-side repo config file. See Server Side Repo Config.
--repo-config-json
atlantis server --repo-config-json='{"repos":[{"id":"/.*/", "apply_requirements":["mergeable"]}]}'
# or
ATLANTIS_REPO_CONFIG_JSON='{"repos":[{"id":"/.*/", "apply_requirements":["mergeable"]}]}'Specify server-side repo config as a JSON string. Useful if you don't want to write a config file to disk. See Server Side Repo Config for more details.
TIP
If specifying a Workflow, step's can be specified as follows:
{
"repos": [],
"workflows": {
"custom": {
"plan": {
"steps": [
"init",
{
"plan": {
"extra_args": ["extra", "args"]
}
},
{
"run": "my custom command"
}
]
}
}
}
}--restrict-file-list
atlantis server --restrict-file-list
# or (recommended)
ATLANTIS_RESTRICT_FILE_LIST=true--restrict-file-list will block plan requests from projects outside the files modified in the pull request. When --enable-regexp-cmd is also enabled, regex project plans such as atlantis plan -p .* are scoped to matching projects with files modified in the pull request. Defaults to false.
--share-plan-dir
atlantis server --share-plan-dir="path/to/local/plan/dir"
# or
ATLANTIS_SHARE_PLAN_DIR="path/to/local/plan/dir"Directory where Atlantis will store local Terraform plan files. If unset, this defaults to the resolved --data-dir value so existing installations keep the same on-disk layout. When set to a different directory, checked out repositories remain under --data-dir and generated .tfplan files use the same repo, pull request, workspace, and project path layout under --share-plan-dir.
--silence-allowlist-errors
atlantis server --silence-allowlist-errors
# or
ATLANTIS_SILENCE_ALLOWLIST_ERRORS=trueSome users use the --repo-allowlist flag to control which repos Atlantis responds to. Normally, if Atlantis receives a pull request webhook from a repo not listed in the allowlist, it will comment back with an error. This flag disables that commenting.
Some users find this useful because they prefer to add the Atlantis webhook at an organization level rather than on each repo.
--silence-fork-pr-errors
atlantis server --silence-fork-pr-errors
# or
ATLANTIS_SILENCE_FORK_PR_ERRORS=trueNormally, if Atlantis receives a pull request webhook from a fork and --allow-fork-prs is not set, it will comment back with an error. This flag disables that commenting.
--silence-no-projects
atlantis server --silence-no-projects
# or
ATLANTIS_SILENCE_NO_PROJECTS=true--silence-no-projects will tell Atlantis to ignore PRs if none of the modified files are part of a project defined in the atlantis.yaml file. This flag ensures an Atlantis server only responds to its explicitly declared projects. This has no effect if projects are undefined in the repo level atlantis.yaml. This also silences targeted commands (e.g. atlantis plan -d mydir or atlantis apply -p myproj) so if the project is not in the repo config atlantis.yaml, these commands will not run or report back in a comment.
This is useful when running multiple Atlantis servers against a single repository so you can delegate work to each Atlantis server. Also useful when used with pre_workflow_hooks to dynamically generate an atlantis.yaml file.
--silence-vcs-status-no-plans
atlantis server --silence-vcs-status-no-plans
# or
ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS=true--silence-vcs-status-no-plans will tell Atlantis to ignore setting VCS status on plans if none of the modified files are part of a project defined in the atlantis.yaml file.
--silence-vcs-status-no-projects
atlantis server --silence-vcs-status-no-projects
# or
ATLANTIS_SILENCE_VCS_STATUS_NO_PROJECTS=true--silence-vcs-status-no-projects will tell Atlantis to ignore setting VCS status on any command if none of the modified files are part of a project defined in the atlantis.yaml file.
--skip-clone-no-changes
atlantis server --skip-clone-no-changes
# or
ATLANTIS_SKIP_CLONE_NO_CHANGES=true--skip-clone-no-changes will skip cloning the repo during autoplan if there are no changes to Terraform projects. This will only apply for GitHub and GitLab and only for repos that have atlantis.yaml file. Defaults to false.
--slack-token
atlantis server --slack-token=token
# or (recommended)
ATLANTIS_SLACK_TOKEN='token'API token for Slack notifications. See Using Slack hooks.
--ssl-cert-file
atlantis server --ssl-cert-file="/etc/ssl/certs/my-cert.crt"
# or
ATLANTIS_SSL_CERT_FILE="/etc/ssl/certs/my-cert.crt"File containing x509 Certificate used for serving HTTPS. If the cert is signed by a CA, the file should be the concatenation of the server's certificate, any intermediates, and the CA's certificate.
--ssl-key-file
atlantis server --ssl-key-file="/etc/ssl/private/my-cert.key"
# or
ATLANTIS_SSL_KEY_FILE="/etc/ssl/private/my-cert.key"File containing x509 private key matching --ssl-cert-file.
--stats-namespace
atlantis server --stats-namespace="myatlantis"
# or
ATLANTIS_STATS_NAMESPACE="myatlantis"Namespace for emitting stats/metrics. See stats section.
--tf-distribution
DeprecatedDeprecated for --default-tf-distribution.
--tf-download
atlantis server --tf-download=false
# or
ATLANTIS_TF_DOWNLOAD=falseDefaults to true. Allow Atlantis to list and download additional versions of Terraform. Setting this to false can be useful in an air-gapped environment where a download mirror is not available.
--tf-download-url
atlantis server --tf-download-url="https://releases.company.com"
# or
ATLANTIS_TF_DOWNLOAD_URL="https://releases.company.com"An alternative URL to download Terraform versions if they are missing. Useful in an airgapped environment where releases.hashicorp.com is not available. Directory structure of the custom endpoint should match that of releases.hashicorp.com.
This has no impact if --tf-download is set to false.
This setting is not yet supported when --tf-distribution is set to opentofu.
--tfe-hostname
atlantis server --tfe-hostname="my-terraform-enterprise.company.com"
# or
ATLANTIS_TFE_HOSTNAME="my-terraform-enterprise.company.com"Hostname of your Terraform Enterprise installation to be used in conjunction with --tfe-token. See Terraform Cloud for more details. If using Terraform Cloud (i.e. you don't have your own Terraform Enterprise installation) no need to set since it defaults to app.terraform.io.
--tfe-local-execution-mode
atlantis server --tfe-local-execution-mode
# or
ATLANTIS_TFE_LOCAL_EXECUTION_MODE=trueEnable if you're using local execution mode (instead of TFE/C's remote execution mode). See Terraform Cloud for more details.
--tfe-token
atlantis server --tfe-token="xxx.atlasv1.yyy"
# or (recommended)
ATLANTIS_TFE_TOKEN='xxx.atlasv1.yyy'A token for Terraform Cloud/Terraform Enterprise integration. See Terraform Cloud for more details.
--use-tf-plugin-cache
atlantis server --use-tf-plugin-cache=falseSet to false if you want to disable terraform plugin cache.
This flag is useful when having multiple projects that need to run a plan and apply in the same PR to avoid the race condition of plugin_cache_dir concurrently, this is a terraform known issue, more info:
The effect of the race condition is more evident when using parallel configuration to run plan and apply. Disabling the use of plugin cache will impact the performance when starting a new plan or apply, but in large Atlantis deployments with multiple projects and shared modules the use of --parallel_plan and --parallel_apply is mandatory for an efficient management of the PRs.
--var-file-allowlist
atlantis server --var-file-allowlist='/path/to/tfvars/dir'
# or
ATLANTIS_VAR_FILE_ALLOWLIST='/path/to/tfvars/dir'Comma-separated list of additional directory paths where variable definition files can be read from. The paths in this argument should be absolute paths. Relative paths and globbing are currently not supported. If this argument is not provided, it defaults to Atlantis' data directory, determined by the --data-dir argument.
Notes:
- The allowlist is enforced for every comment command that passes
-var-fileto Terraform (plan,apply,importandstate rm), and for both the-var-fileand--var-filespellings. - Only
-var-filevalues given in comment extra args are checked. Var files named in workflowextra_argsare not. - A path inside the repository is always allowed as written, but once the repository is cloned the file is resolved with symbolic links followed. A link committed to the repository that points outside both the repository and the allowlisted directories is rejected, and so is a link whose target does not exist. A var file path may not contain a
..element, because the operating system follows a symbolic link before applying...
Behavior change
Previously, the allowlist was checked only for atlantis plan, only for the single-dash -var-file spelling, and only against the path as written. Now it is checked for plan, apply, import and state rm, for every spelling (-var-file, --var-file, with a space or =), and again after cloning with symbolic links resolved. Rejected paths fail with var file path <path> is not allowed by the current allowlist: [<dirs>], var file path <path> resolves to <target>, which is not allowed by the current allowlist: [<dirs>], var file path <path> is a symbolic link whose target does not exist or var file path <path> must not contain '..' elements. Move shared var files into the repository or an allowlisted directory, and replace links that point outside them with real files.
--vcs-status-name
atlantis server --vcs-status-name="atlantis-dev"
# or
ATLANTIS_VCS_STATUS_NAME="atlantis-dev"Name used to identify Atlantis when updating a pull request status. Defaults to atlantis.
This is useful when running multiple Atlantis servers against a single repository so you can give each Atlantis server its own unique name to prevent the statuses clashing.
--web-basic-auth
atlantis server --web-basic-auth
# or
ATLANTIS_WEB_BASIC_AUTH=trueEnable Basic Authentication on the Atlantis web service.
--web-password
atlantis server --web-password="atlantis"
# or
ATLANTIS_WEB_PASSWORD="atlantis"Password used for Basic Authentication on the Atlantis web service. Defaults to atlantis.
--web-username
atlantis server --web-username="atlantis"
# or
ATLANTIS_WEB_USERNAME="atlantis"Username used for Basic Authentication on the Atlantis web service. Defaults to atlantis.
--webhook-http-headers
atlantis server --webhook-http-headers='{"Authorization":"Bearer some-token","X-Custom-Header":["value1","value2"]}'
# or
ATLANTIS_WEBHOOK_HTTP_HEADERS='{"Authorization":"Bearer some-token","X-Custom-Header":["value1","value2"]}'Additional headers added to each HTTP POST payload when using http webhooks provided as a JSON string. The map key is the header name and the value is the header value (string) or values (array of string).
--websocket-check-origin
atlantis server --websocket-check-origin
# or
ATLANTIS_WEBSOCKET_CHECK_ORIGIN=trueOnly allow websockets connection when they originate from the running Atlantis web server
--write-git-creds
atlantis server --write-git-creds
# or
ATLANTIS_WRITE_GIT_CREDS=trueWrite out a .git-credentials file with the provider user and token to allow cloning private modules over HTTPS or SSH. See Git Credential Store documentation for more information.
Follow the git::ssh