This page covers getting Atlantis up and running in your infrastructure.
::: tip Prerequisites
- You have created access credentials for your Atlantis user
- You have created a webhook secret :::
Atlantis is a simple Go app. It receives webhooks from your Git host and executes Terraform commands locally. There is an official Atlantis Docker image.
Atlantis and your Git host need to be able to route and communicate with one another. Your Git host needs to be able to send webhooks to Atlantis and Atlantis needs to be able to make API calls to your Git host. If you're using a public Git host like github.com, gitlab.com, gitea.com, bitbucket.org, or dev.azure.com then you'll need to expose Atlantis to the internet.
If you're using a private Git host like GitHub Enterprise, GitLab Enterprise, self-hosted Gitea or Bitbucket Server, then Atlantis needs to be routable from the private host and Atlantis will need to be able to route to the private host.
Atlantis has no external database. Atlantis stores Terraform plan files on disk.
If Atlantis loses that data in between a plan
and apply
cycle, then users will have
to re-run plan
. Because of this, you may want to provision a persistent disk
for Atlantis.
Pick your deployment type:
- Kubernetes Helm Chart
- Kubernetes Manifests
- Kubernetes Kustomize
- OpenShift
- AWS Fargate
- Google Kubernetes Engine (GKE)
- Docker
- Roll Your Own
Atlantis has an official Helm chart
To install:
-
Add the runatlantis helm chart repository to helm
helm repo add runatlantis https://runatlantis.github.io/helm-charts
-
cd
into a directory where you're going to configure your Atlantis Helm chart -
Create a
values.yaml
file by runninghelm inspect values runatlantis/atlantis > values.yaml
-
Edit
values.yaml
and add your access credentials and webhook secret# for example github: user: foo token: bar secret: baz
-
Edit
values.yaml
and set yourorgAllowlist
(see Repo Allowlist for more information)orgAllowlist: github.com/runatlantis/*
Note: For helm chart version <
4.0.2
,orgWhitelist
must be used instead. -
Configure any other variables (see Atlantis Helm Chart: Customization for documentation)
-
Run
helm install atlantis runatlantis/atlantis -f values.yaml
If you are using helm v2, run:
helm install -f values.yaml runatlantis/atlantis
Atlantis should be up and running in minutes! See Next Steps for what to do next.
If you'd like to use a raw Kubernetes manifest, we offer either a Deployment or a Statefulset with persistent storage.
StatefulSet is recommended because Atlantis stores its data on disk and so if your Pod dies
or you upgrade Atlantis, you won't lose plans that haven't been applied. If
you do lose that data, you just need to run atlantis plan
again so it's not the end of the world.
Regardless of whether you choose a Deployment or StatefulSet, first create a Secret with the webhook secret and access token:
echo -n "yourtoken" > token
echo -n "yoursecret" > webhook-secret
kubectl create secret generic atlantis-vcs --from-file=token --from-file=webhook-secret
::: tip Note If you're using Bitbucket Cloud then there is no webhook secret since it's not supported. :::
Next, edit the manifests below as follows:
- Replace
<VERSION>
inimage: ghcr.io/runatlantis/atlantis:<VERSION>
with the most recent version from GitHub: Atlantis latest release.- NOTE: You never want to run with
:latest
because if your Pod moves to a new node, Kubernetes will pull the latest image and you might end up upgrading Atlantis by accident!
- NOTE: You never want to run with
- Replace
value: github.com/yourorg/*
undername: ATLANTIS_REPO_ALLOWLIST
with the allowlist pattern for your Terraform repos. See --repo-allowlist for more details. - If you're using GitHub:
- Replace
<YOUR_GITHUB_USER>
with the username of your Atlantis GitHub user without the@
. - Delete all the
ATLANTIS_GITLAB_*
,ATLANTIS_GITEA_*
,ATLANTIS_BITBUCKET_*
, andATLANTIS_AZUREDEVOPS_*
environment variables.
- Replace
- If you're using GitLab:
- Replace
<YOUR_GITLAB_USER>
with the username of your Atlantis GitLab user without the@
. - Delete all the
ATLANTIS_GH_*
,ATLANTIS_GITEA_*
,ATLANTIS_BITBUCKET_*
, andATLANTIS_AZUREDEVOPS_*
environment variables.
- Replace
- If you're using Gitea:
- Replace
<YOUR_GITEA_USER>
with the username of your Atlantis Gitea user without the@
. - Delete all the
ATLANTIS_GH_*
,ATLANTIS_GITLAB_*
,ATLANTIS_BITBUCKET_*
, andATLANTIS_AZUREDEVOPS_*
environment variables.
- Replace
- If you're using Bitbucket:
- Replace
<YOUR_BITBUCKET_USER>
with the username of your Atlantis Bitbucket user without the@
. - Delete all the
ATLANTIS_GH_*
,ATLANTIS_GITLAB_*
,ATLANTIS_GITEA_*
, andATLANTIS_AZUREDEVOPS_*
environment variables.
- Replace
- If you're using Azure DevOps:
- Replace
<YOUR_AZUREDEVOPS_USER>
with the username of your Atlantis Azure DevOps user without the@
. - Delete all the
ATLANTIS_GH_*
,ATLANTIS_GITLAB_*
,ATLANTIS_GITEA_*
, andATLANTIS_BITBUCKET_*
environment variables.
- Replace
Show...
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: atlantis
spec:
serviceName: atlantis
replicas: 1
updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 0
selector:
matchLabels:
app.kubernetes.io/name: atlantis
template:
metadata:
labels:
app.kubernetes.io/name: atlantis
spec:
securityContext:
fsGroup: 1000 # Atlantis group (1000) read/write access to volumes.
containers:
- name: atlantis
image: ghcr.io/runatlantis/atlantis:v<VERSION> # 1. Replace <VERSION> with the most recent release.
env:
- name: ATLANTIS_REPO_ALLOWLIST
value: github.com/yourorg/* # 2. Replace this with your own repo allowlist.
### GitHub Config ###
- name: ATLANTIS_GH_USER
value: <YOUR_GITHUB_USER> # 3i. If you're using GitHub replace <YOUR_GITHUB_USER> with the username of your Atlantis GitHub user without the `@`.
- name: ATLANTIS_GH_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GH_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
### End GitHub Config ###
### GitLab Config ###
- name: ATLANTIS_GITLAB_USER
value: <YOUR_GITLAB_USER> # 4i. If you're using GitLab replace <YOUR_GITLAB_USER> with the username of your Atlantis GitLab user without the `@`.
- name: ATLANTIS_GITLAB_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GITLAB_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
### End GitLab Config ###
### Gitea Config ###
- name: ATLANTIS_GITEA_USER
value: <YOUR_GITEA_USER> # 4i. If you're using Gitea replace <YOUR_GITEA_USER> with the username of your Atlantis Gitea user without the `@`.
- name: ATLANTIS_GITEA_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GITEA_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
### End Gitea Config ###
### Bitbucket Config ###
- name: ATLANTIS_BITBUCKET_USER
value: <YOUR_BITBUCKET_USER> # 5i. If you're using Bitbucket replace <YOUR_BITBUCKET_USER> with the username of your Atlantis Bitbucket user without the `@`.
- name: ATLANTIS_BITBUCKET_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
### End Bitbucket Config ###
### Azure DevOps Config ###
- name: ATLANTIS_AZUREDEVOPS_USER
value: <YOUR_AZUREDEVOPS_USER> # 6i. If you're using Azure DevOps replace <YOUR_AZUREDEVOPS_USER> with the username of your Atlantis Azure DevOps user without the `@`.
- name: ATLANTIS_AZUREDEVOPS_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_AZUREDEVOPS_WEBHOOK_USER
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: basic-user
- name: ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: basic-password
### End Azure DevOps Config ###
- name: ATLANTIS_DATA_DIR
value: /atlantis
- name: ATLANTIS_PORT
value: "4141" # Kubernetes sets an ATLANTIS_PORT variable so we need to override.
volumeMounts:
- name: atlantis-data
mountPath: /atlantis
ports:
- name: atlantis
containerPort: 4141
resources:
requests:
memory: 256Mi
cpu: 100m
limits:
memory: 256Mi
cpu: 100m
livenessProbe:
# We only need to check every 60s since Atlantis is not a
# high-throughput service.
periodSeconds: 60
httpGet:
path: /healthz
port: 4141
# If using https, change this to HTTPS
scheme: HTTP
readinessProbe:
periodSeconds: 60
httpGet:
path: /healthz
port: 4141
# If using https, change this to HTTPS
scheme: HTTP
volumeClaimTemplates:
- metadata:
name: atlantis-data
spec:
accessModes: ["ReadWriteOnce"] # Volume should not be shared by multiple nodes.
resources:
requests:
# The biggest thing Atlantis stores is the Git repo when it checks it out.
# It deletes the repo after the pull request is merged.
storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
name: atlantis
spec:
type: ClusterIP
ports:
- name: atlantis
port: 80
targetPort: 4141
selector:
app.kubernetes.io/name: atlantis
Show...
apiVersion: apps/v1
kind: Deployment
metadata:
name: atlantis
labels:
app.kubernetes.io/name: atlantis
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: atlantis
template:
metadata:
labels:
app.kubernetes.io/name: atlantis
spec:
containers:
- name: atlantis
image: ghcr.io/runatlantis/atlantis:v<VERSION> # 1. Replace <VERSION> with the most recent release.
env:
- name: ATLANTIS_REPO_ALLOWLIST
value: github.com/yourorg/* # 2. Replace this with your own repo allowlist.
### GitHub Config ###
- name: ATLANTIS_GH_USER
value: <YOUR_GITHUB_USER> # 3i. If you're using GitHub replace <YOUR_GITHUB_USER> with the username of your Atlantis GitHub user without the `@`.
- name: ATLANTIS_GH_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GH_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
### End GitHub Config ###
### GitLab Config ###
- name: ATLANTIS_GITLAB_USER
value: <YOUR_GITLAB_USER> # 4i. If you're using GitLab replace <YOUR_GITLAB_USER> with the username of your Atlantis GitLab user without the `@`.
- name: ATLANTIS_GITLAB_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GITLAB_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
### End GitLab Config ###
### Gitea Config ###
- name: ATLANTIS_GITEA_USER
value: <YOUR_GITEA_USER> # 4i. If you're using Gitea replace <YOUR_GITEA_USER> with the username of your Atlantis Gitea user without the `@`.
- name: ATLANTIS_GITEA_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GITEA_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
### End Gitea Config ###
### Bitbucket Config ###
- name: ATLANTIS_BITBUCKET_USER
value: <YOUR_BITBUCKET_USER> # 5i. If you're using Bitbucket replace <YOUR_BITBUCKET_USER> with the username of your Atlantis Bitbucket user without the `@`.
- name: ATLANTIS_BITBUCKET_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
### End Bitbucket Config ###
### Azure DevOps Config ###
- name: ATLANTIS_AZUREDEVOPS_USER
value: <YOUR_AZUREDEVOPS_USER> # 6i. If you're using Azure DevOps replace <YOUR_AZUREDEVOPS_USER> with the username of your Atlantis Azure DevOps user without the `@`.
- name: ATLANTIS_AZUREDEVOPS_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_AZUREDEVOPS_WEBHOOK_USER
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: basic-user
- name: ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: basic-password
### End Azure DevOps Config ###
- name: ATLANTIS_PORT
value: "4141" # Kubernetes sets an ATLANTIS_PORT variable so we need to override.
ports:
- name: atlantis
containerPort: 4141
resources:
requests:
memory: 256Mi
cpu: 100m
limits:
memory: 256Mi
cpu: 100m
livenessProbe:
# We only need to check every 60s since Atlantis is not a
# high-throughput service.
periodSeconds: 60
httpGet:
path: /healthz
port: 4141
# If using https, change this to HTTPS
scheme: HTTP
readinessProbe:
periodSeconds: 60
httpGet:
path: /healthz
port: 4141
# If using https, change this to HTTPS
scheme: HTTP
---
apiVersion: v1
kind: Service
metadata:
name: atlantis
spec:
type: ClusterIP
ports:
- name: atlantis
port: 80
targetPort: 4141
selector:
app.kubernetes.io/name: atlantis
The manifests above create a Kubernetes Service
of type: ClusterIP
which isn't accessible outside your cluster.
Depending on how you're doing routing into Kubernetes, you may want to use a Service of type: LoadBalancer
so that Atlantis is accessible
to GitHub/GitLab and your internal users.
If you want to add SSL you can use something like cert-manager to generate SSL
certs and mount them into the Pod. Then set the ATLANTIS_SSL_CERT_FILE
and ATLANTIS_SSL_KEY_FILE
environment variables to enable SSL.
You could also set up SSL at your LoadBalancer.
You're done! See Next Steps for what to do next.
A kustomization.yaml
file is provided in the directory kustomize/
, so you may use this repository as a remote base for deploying Atlantis with Kustomize.
You will need to provide a secret (with the default name of atlantis-vcs
) to configure Atlantis with access credentials for your remote repositories.
Example:
bases:
- github.com/runatlantis/atlantis//kustomize
resources:
- secrets.yaml
Important: You must ensure you patch the provided manifests with the correct environment variables for your installation. You can create inline patches from your kustomization.yaml
file such as below:
patchesStrategicMerge:
- |-
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: atlantis
spec:
template:
spec:
...
...
containers:
- name: atlantis
env:
- name: ATLANTIS_REPO_ALLOWLIST
value: github.com/yourorg/* # 2. Replace this with your own repo allowlist.
...
containers:
- name: atlantis
env:
- name: ATLANTIS_GITLAB_USER
value: <YOUR_GITLAB_USER> # 4i. If you're using GitLab replace <YOUR_GITLAB_USER> with the username of your Atlantis GitLab user without the `@`.
- name: ATLANTIS_GITLAB_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GITLAB_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
containers:
- name: atlantis
env:
- name: ATLANTIS_GITEA_USER
value: <YOUR_GITEA_USER> # 4i. If you're using Gitea replace <YOUR_GITEA_USER> with the username of your Atlantis Gitea user without the `@`.
- name: ATLANTIS_GITEA_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GITEA_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
...
containers:
- name: atlantis
env:
- name: ATLANTIS_GH_USER
value: <YOUR_GITHUB_USER> # 3i. If you're using GitHub replace <YOUR_GITHUB_USER> with the username of your Atlantis GitHub user without the `@`.
- name: ATLANTIS_GH_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
- name: ATLANTIS_GH_WEBHOOK_SECRET
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: webhook-secret
...
containers:
- name: atlantis
env:
- name: ATLANTIS_BITBUCKET_USER
value: <YOUR_BITBUCKET_USER> # 5i. If you're using Bitbucket replace <YOUR_BITBUCKET_USER> with the username of your Atlantis Bitbucket user without the `@`.
- name: ATLANTIS_BITBUCKET_TOKEN
valueFrom:
secretKeyRef:
name: atlantis-vcs
key: token
The Helm chart and Kubernetes manifests above are compatible with OpenShift, however you need to run
with an additional environment variable: HOME=/home/atlantis
. This is required because
OpenShift runs Docker images with random user id's that use /
as their home directory.
If you'd like to run Atlantis on AWS Fargate check out the Atlantis module on the Terraform Module Registry and then check out the Next Steps.
You can run Atlantis on GKE using the Helm chart or the manifests.
There is also a set of full Terraform configurations that create a GKE Cluster, Cloud Storage Backend and TLS certs: sethvargo atlantis-on-gke.
Once you're done, see Next Steps.
Atlantis can be run on Google Compute Engine using a Terraform module that deploys it as a Docker container on a managed Compute Engine instance.
This Terraform module features the creation of a Cloud load balancer, a Container-Optimized OS-based VM, a persistent data disk, and a managed instance group.
After it is deployed, see Next Steps.
Atlantis has an official Docker image: ghcr.io/runatlantis/atlantis
.
If you need to modify the Docker image that we provide, for instance to add the terragrunt binary, you can do something like this:
-
Create a custom docker file
FROM ghcr.io/runatlantis/atlantis:{latest version} # copy a terraform binary of the version you need USER root COPY terragrunt /usr/local/bin/terragrunt
Beginning with version 0.26.0, the Atlantis image has been updated to run under the atlantis user, replacing the previous root user configuration. This change necessitates adjustments in existing container definitions and scripts to accommodate the new user settings. In scenarios where additional packages from other images are required, users can temporarily switch to the root user by inserting USER root in the Dockerfile. Following the installation of necessary packages, it is advisable to revert to the atlantis user for initiating the Atlantis service. Additionally, the /docker-entrypoint.d/ directory offers a flexible option for introducing extra scripts to be executed prior to the launch of the Atlantis server. This feature is particularly beneficial for users seeking to customize their Atlantis instance without the need to develop a dedicated pipeline. Important Notice: There is a critical update regarding the data directory in Atlantis. In versions prior to 0.26.0, the directory was configured to be accessible by the root user. However, with the transition to the atlantis user in newer versions, it is imperative to update the directory permissions accordingly in your current deployment when upgrading to a version later than 0.26.0. This step ensures seamless access and functionality for the atlantis user.
-
Build your Docker image
docker build -t {YOUR_DOCKER_ORG}/atlantis-custom .
-
Run your image
docker run {YOUR_DOCKER_ORG}/atlantis-custom server --gh-user=GITHUB_USERNAME --gh-token=GITHUB_TOKEN
The standard Kubernetes Helm Chart should work fine on Azure Kubernetes Service.
Another option is Azure Container Instances. See this community member's repo or the new and more up-to-date Terraform module for install scripts and more information on running Atlantis on ACI.
Note on ACI Deployment: Due to a bug in earlier Docker releases, Docker v23.0.0 or later is required for straightforward deployment. Alternatively, the Atlantis Docker image can be pushed to a private registry such as ACR and then used.
If you want to roll your own Atlantis installation, you can get the atlantis
binary from GitHub
or use the official Docker image.
The exact flags to atlantis server
depends on your Git host:
atlantis server \
--atlantis-url="$URL" \
--gh-user="$USERNAME" \
--gh-token="$TOKEN" \
--gh-webhook-secret="$SECRET" \
--repo-allowlist="$REPO_ALLOWLIST"
HOSTNAME=YOUR_GITHUB_ENTERPRISE_HOSTNAME # ex. github.runatlantis.io
atlantis server \
--atlantis-url="$URL" \
--gh-user="$USERNAME" \
--gh-token="$TOKEN" \
--gh-webhook-secret="$SECRET" \
--gh-hostname="$HOSTNAME" \
--repo-allowlist="$REPO_ALLOWLIST"
atlantis server \
--atlantis-url="$URL" \
--gitlab-user="$USERNAME" \
--gitlab-token="$TOKEN" \
--gitlab-webhook-secret="$SECRET" \
--repo-allowlist="$REPO_ALLOWLIST"
HOSTNAME=YOUR_GITLAB_ENTERPRISE_HOSTNAME # ex. gitlab.runatlantis.io
atlantis server \
--atlantis-url="$URL" \
--gitlab-user="$USERNAME" \
--gitlab-token="$TOKEN" \
--gitlab-webhook-secret="$SECRET" \
--gitlab-hostname="$HOSTNAME" \
--repo-allowlist="$REPO_ALLOWLIST"
atlantis server \
--atlantis-url="$URL" \
--gitea-user="$USERNAME" \
--gitea-token="$TOKEN" \
--gitea-webhook-secret="$SECRET" \
--gitea-page-size=30 \
--repo-allowlist="$REPO_ALLOWLIST"
atlantis server \
--atlantis-url="$URL" \
--bitbucket-user="$USERNAME" \
--bitbucket-token="$TOKEN" \
--repo-allowlist="$REPO_ALLOWLIST"
BASE_URL=YOUR_BITBUCKET_SERVER_URL # ex. http://bitbucket.mycorp:7990
atlantis server \
--atlantis-url="$URL" \
--bitbucket-user="$USERNAME" \
--bitbucket-token="$TOKEN" \
--bitbucket-webhook-secret="$SECRET" \
--bitbucket-base-url="$BASE_URL" \
--repo-allowlist="$REPO_ALLOWLIST"
A certificate and private key are required if using Basic authentication for webhooks.
atlantis server \
--atlantis-url="$URL" \
--azuredevops-user="$USERNAME" \
--azuredevops-token="$TOKEN" \
--azuredevops-webhook-user="$ATLANTIS_AZUREDEVOPS_WEBHOOK_USER" \
--azuredevops-webhook-password="$ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD" \
--repo-allowlist="$REPO_ALLOWLIST"
--ssl-cert-file=file.crt
--ssl-key-file=file.key
Where
$URL
is the URL that Atlantis can be reached at$USERNAME
is the GitHub/GitLab/Gitea/Bitbucket/AzureDevops username you generated the token for$TOKEN
is the access token you created. If you don't want this to be passed in as an argument for security reasons you can specify it in a config file (see Configuration) or as an environment variable:ATLANTIS_GH_TOKEN
orATLANTIS_GITLAB_TOKEN
orATLANTIS_GITEA_TOKEN
orATLANTIS_BITBUCKET_TOKEN
orATLANTIS_AZUREDEVOPS_TOKEN
$SECRET
is the random key you used for the webhook secret. If you don't want this to be passed in as an argument for security reasons you can specify it in a config file (see Configuration) or as an environment variable:ATLANTIS_GH_WEBHOOK_SECRET
orATLANTIS_GITLAB_WEBHOOK_SECRET
orATLANTIS_GITEA_WEBHOOK_SECRET
$REPO_ALLOWLIST
is which repos Atlantis can run on, ex.github.com/runatlantis/*
orgithub.enterprise.corp.com/*
. See --repo-allowlist for more details.
Atlantis is now running! ::: tip We recommend running it under something like Systemd or Supervisord that will restart it in case of failure. :::
- To ensure Atlantis is running, load its UI. By default Atlantis runs on port
4141
. - Now you're ready to add Webhooks to your repos. See Configuring Webhooks.