16 KiB
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
::: warning 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-fork-prsatlantis server --allow-fork-prsRespond to pull requests from forks. Defaults to
false.:::warning 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 planwhich can run arbitrary code if given a malicious Terraform configuration. ::: -
```bash atlantis server --allow-repo-config ``` This flag is deprecated. It allows all repos to use all restricted `atlantis.yaml` keys. See [Repo Level Atlantis.yaml](repo-level-atlantis-yaml.html) for more details.--allow-repo-configInstead of using this flag, create a server-side
--repo-configfile:# repos.yaml repos: - id: /.*/ allowed_overrides: [apply_requirements, workflow] allow_custom_workflows: trueOr use
--repo-config-json='{"repos":[{"id":"/.*/", "allowed_overrides":["apply_requirements","workflow"], "allow_custom_workflows":true}]}'::: warning SECURITY WARNING This setting enables pull requests to run arbitrary code on the Atlantis server. Only enable in trusted settings. :::
-
--atlantis-urlatlantis server --atlantis-url="https://my-domain.com:9090/basepath"Specify the URL that Atlantis is accessible from. Used in the Atlantis UI and in links from pull request comments. Defaults to
http://$(hostname):$portwhere$portis from the--portflag. Supports a basepath if you're hosting Atlantis under a path. -
--automergeatlantis server --automergeAutomatically merge pull requests after all plans have been successfully applied. Defaults to
false. See Automerging for more details. -
--azuredevops-webhook-passwordatlantis server --azuredevops-webhook-password="password123"Azure DevOps basic authentication password for inbound webhooks (see https://docs.microsoft.com/en-us/azure/devops/service-hooks/authorize?view=azure-devops). 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_BASIC_AUTH environment variable.
-
--azuredevops-webhook-useratlantis server --azuredevops-webhook-user="username@example.com"Azure DevOps basic authentication username for inbound webhooks. Can also be specified via the ATLANTIS_AZUREDEVOPS_WEBHOOK_USER environment variable.
-
--azuredevops-tokenatlantis server --azuredevops-token="username@example.com"Azure DevOps token of API user. Can also be specified via the ATLANTIS_AZUREDEVOPS_TOKEN environment variable.
-
--azuredevops-useratlantis server --azuredevops-user="username@example.com"Azure DevOps username of API user.
-
--bitbucket-base-urlatlantis server --bitbucket-base-url="http://bitbucket.corp:7990/basepath"Base URL of Bitbucket Server (aka Stash) installation. Must include
http://orhttps://. If using Bitbucket Cloud (bitbucket.org), do not set. Defaults tohttps://api.bitbucket.org. -
--bitbucket-tokenatlantis server --bitbucket-token="token" # or (recommended) ATLANTIS_BITBUCKET_TOKEN='token' atlantis serverBitbucket app password of API user.
-
--bitbucket-useratlantis server --bitbucket-user="myuser"Bitbucket username of API user.
-
--bitbucket-webhook-secretatlantis server --bitbucket-webhook-secret="secret" # or (recommended) ATLANTIS_BITBUCKET_WEBHOOK_SECRET='secret' atlantis serverSecret used to validate Bitbucket webhooks. Only Bitbucket Server supports webhook secrets. For Bitbucket.org, see Security for mitigations.
::: warning 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. :::
-
--checkout-strategyatlantis server --checkout-strategy="<branch|merge>"How to check out pull requests. Defaults to
branch. See Checkout Strategy for more details. -
--configatlantis server --config="my/config/file.yaml"YAML config file where flags can also be set. See Config File for more details.
-
--data-diratlantis server --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 and downloaded Terraform binaries here. If Atlantis loses this directory, locks will be lost and unapplied plans will be lost. -
--default-tf-versionatlantis server --default-tf-version="v0.12.0"Terraform version to default to. Will download to
<data-dir>/bin/terraform<version>if not inPATH. See Terraform Versions for more details. -
--disable-apply-allatlantis server --disable-apply-allDisable "atlantis apply" command so a specific project/workspace/directory has to be specified for applies.
-
--gh-hostnameatlantis server --gh-hostname="my.github.enterprise.com"Hostname of your GitHub Enterprise installation. If using Github.com, don't set. Defaults to
github.com. -
--gh-tokenatlantis server --gh-token="token" # or (recommended) ATLANTIS_GH_TOKEN='token' atlantis serverGitHub token of API user.
-
--gh-useratlantis server --gh-user="myuser"GitHub username of API user.
-
--gh-webhook-secretatlantis server --gh-webhook-secret="secret" # or (recommended) ATLANTIS_GH_WEBHOOK_SECRET='secret' atlantis serverSecret used to validate GitHub webhooks (see https://developer.github.com/webhooks/securing/).
::: warning 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. :::
-
--gitlab-hostnameatlantis server --gitlab-hostname="my.gitlab.enterprise.com"Hostname of your GitLab Enterprise installation. If using Gitlab.com, don't set. Defaults to
gitlab.com. -
--gitlab-tokenatlantis server --gitlab-token="token" # or (recommended) ATLANTIS_GITLAB_TOKEN='token' atlantis serverGitLab token of API user.
-
--gitlab-useratlantis server --gitlab-user="myuser"GitLab username of API user.
-
--gitlab-webhook-secretatlantis server --gh-webhook-secret="secret" # or (recommended) ATLANTIS_GITLAB_WEBHOOK_SECRET='secret' atlantis serverSecret used to validate GitLab webhooks.
::: warning 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. :::
-
--helpatlantis server --helpView help.
-
--log-levelatlantis server --log-level="<debug|info|warn|error>"Log level. Defaults to
info. -
--portatlantis server --port=8080Port to bind to. Defaults to
4141. -
--repo-configatlantis server --repo-config="path/to/repos.yaml"Path to a YAML server-side repo config file. See Server Side Repo Config.
-
--repo-config-jsonatlantis server --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" } ] } } } }:::
-
--repo-whitelist# NOTE: Use single quotes to avoid shell expansion of *. atlantis server --repo-whitelist='github.com/myorg/*'Atlantis requires you to specify a whitelist 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- 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 whitelist takes one of two forms:
{owner}.visualstudio.com/{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 whitelist for each repository until the change is complete.
Examples:
- Whitelist
myorg/repo1andmyorg/repo2ongithub.com--repo-whitelist=github.com/myorg/repo1,github.com/myorg/repo2
- Whitelist all repos under
myorgongithub.com--repo-whitelist='github.com/myorg/*'
- Whitelist all repos in my GitHub Enterprise installation
--repo-whitelist='github.yourcompany.com/*'
- Whitelist all repos under
myorgprojectmyprojecton Azure DevOps--repo-whitelist='myorg.visualstudio.com/myproject/*,dev.azure.com/myorg/myproject/*'
- Whitelist all repositories
--repo-whitelist='*'
- Accepts a comma separated list, ex.
-
```bash atlantis server --require-approval ``` This flag is deprecated. It requires all pull requests to be approved before `atlantis apply` is allowed. See [Apply Requirements](apply-requirements.html) for more details.--require-approvalInstead of using this flag, create a server-side
--repo-configfile:# repos.yaml repos: - id: /.*/ apply_requirements: [approved]Or use
--repo-config-json='{"repos":[{"id":"/.*/", "apply_requirements":["approved"]}]}'instead. -
```bash atlantis server --require-mergeable ``` This flag is deprecated. It causes all pull requests to be mergeable before `atlantis apply` is allowed. See [Apply Requirements](apply-requirements.html) for more details.--require-mergeableInstead of using this flag, create a server-side
--repo-configfile:# repos.yaml repos: - id: /.*/ apply_requirements: [mergeable]Or use
--repo-config-json='{"repos":[{"id":"/.*/", "apply_requirements":["mergeable"]}]}'instead. -
--silence-fork-pr-errorsatlantis server --silence-fork-pr-errorsNormally, 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-whitelist-errorsatlantis server --silence-whitelist-errorsSome users use the
--repo-whitelistflag to control which repos Atlantis responds to. Normally, if Atlantis receives a pull request webhook from a repo not listed in the whitelist, 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.
-
--slack-tokenatlantis server --slack-token=token # or (recommended) ATLANTIS_SLACK_TOKEN='token' atlantis serverAPI token for Slack notifications. Slack is not fully supported. TODO: Slack docs.
-
--ssl-cert-fileatlantis server --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-fileatlantis server --ssl-cert-file="/etc/ssl/private/my-cert.key"File containing x509 private key matching
--ssl-cert-file. -
--tf-download-urlatlantis server --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.
-
--tfe-hostnameatlantis server --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 toapp.terraform.io. -
--tfe-tokenatlantis server --tfe-token="xxx.atlasv1.yyy" # or (recommended) ATLANTIS_TFE_TOKEN='xxx.atlasv1.yyy' atlantis serverA token for Terraform Cloud/Terraform Enterprise integration. See Terraform Cloud for more details.
-
--vcs-status-nameatlantis server --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.
-
--write-git-credsatlantis server --write-git-credsWrite out a .git-credentials file with the provider user and token to allow cloning private modules over HTTPS or SSH. See here for more information. ::: warning SECURITY WARNING This does write secrets to disk and should only be enabled in a secure environment. :::