Atlantis Documentation

repository·main·Indexed 27 days ago

https://github.com/runatlantis/atlantis

Atlantis is a self-hosted Go application for Terraform pull request automation. It integrates with VCS providers like GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea via webhooks to automate terraform plan, import, and apply commands directly through PR comments. The tool allows teams to standardize workflows, make infrastructure changes visible, and enable collaborative infrastructure-as-code management.

Tokens
70.4K
Snippets
192
Records
411
Agent score
88%

What's inside Atlantis

  1. Overview of the Atlantis Terraform workflow

    main

    Atlantis enables a Terraform workflow directly within Pull Requests (PRs). Instead of running commands locally, developers and operators use Atlantis to:

    1. Run terraform plan: Atlantis executes the plan and comments the output directly on the Pull Request, allowing reviewers to see exactly what changes will occur.
    2. Run terraform apply: Atlantis executes the apply command from the Pull Request. This ensures that the code in the branch is what is actually applied to infrastructure, preventing the master branch from getting out of sync.

    This workflow allows developers to write Terraform without needing local credentials, as all commands are executed by the Atlantis server.

  2. Overview of Atlantis

    main

    Atlantis is a self-hosted Go application designed for Terraform Pull Request automation. It listens for Terraform pull request events via webhooks and automates the execution of Terraform commands.

    Key capabilities include:

    • Running terraform plan, import, and apply remotely.
    • Commenting the command output directly back onto the pull request.
    • Making Terraform changes visible to the entire team.
    • Enabling non-operations engineers to collaborate on infrastructure code.
    • Standardizing Terraform workflows across an organization.
  3. Install, configure, and use Atlantis

    main

    To move beyond the initial guide, follow these primary documentation paths:

    • Installation: Follow the Installation Guide to get Atlantis up and running.
    • Configuration: Use the Configuring Atlantis guide to tailor Atlantis behavior to your specific use-cases.
    • Usage: Refer to the Using Atlantis documentation to learn how to interact with the tool.
    • Architecture: Read How Atlantis Works to understand the internal mechanics of the service.
  4. Understand the Atlantis workflow

    main

    Atlantis automates Terraform operations via pull requests (GitHub, GitLab, or Bitbucket) using webhooks. The standard workflow is:

    1. Plan: Atlantis listens for pull request webhooks, runs terraform plan, and posts the output as a comment on the pull request.
    2. Apply: To execute changes, comment atlantis apply on the pull request. Atlantis will then run terraform apply and post the resulting output back to the pull request.

    Atlantis is deployed as a standalone application within your own infrastructure, ensuring no third-party access to your credentials.

  5. Understand Atlantis locking behavior

    main

    Atlantis implements locking at the directory and Terraform workspace level to prevent concurrent operations on the same infrastructure state across different pull requests.

    • Scope: Only the specific directory in the repo and the associated Terraform workspace are locked, not the entire repository.
    • Automatic Unlocking: Locks are automatically released when the pull request is merged or closed.
    • Apply Safety: Atlantis checks the global apply lock before running atlantis apply. If the lock backend is unreachable, Atlantis fails closed and rejects the apply.
    • Terraform State Locking: Atlantis locking operates at a higher level than Terraform state locking. While Terraform locks the state during an apply to prevent concurrent execution, Atlantis prevents multiple pull requests from working on the same state simultaneously.
  6. Provide provider credentials to Atlantis

    main

    Atlantis executes terraform plan and apply on its host server. To work, it requires the same provider credentials you would use when running Terraform locally.

    Common methods for providing credentials include:

    • Cloud Identity/Roles: Use native cloud mechanisms like AWS EC2 Roles or GCE Instance Service Accounts.
    • Environment Variables: Set variables like AWS_ACCESS_KEY on the Atlantis server.
    • Config Files: Create necessary configuration files (e.g., ~/.aws/credentials) on the Atlantis server.
    • Vault: Use the HashiCorp Vault Provider to obtain credentials.
    • Deployment-specific mechanisms: Use the specific credential mechanisms provided by the Atlantis Helm Chart or AWS Fargate Module.

    Rule of thumb: If you can ssh or exec into the Atlantis server and run terraform commands successfully, Atlantis will work.

  7. Override Terraform commands with custom run steps

    main

    For advanced customization not supported by extra_args, you can completely override init, plan, or apply using the run step.

    Requirements for custom plan/apply:

    • You MUST output the plan using -out $PLANFILE because Atlantis expects plans to be in a specific location.
    • For apply, you must use the $PLANFILE environment variable.
    • If using workspaces, select the workspace using the $WORKSPACE environment variable.
    • Use the output: hide option on a run step if you want to prevent command output from appearing in the Atlantis PR comment.
    # atlantis.yaml or repos.yaml
    workflows:
      myworkflow:
        plan:
          steps:
          - run:
              command: terraform init -input=false
              output: hide
          - run: terraform workspace select $WORKSPACE
          - run: terraform plan -input=false -refresh -out $PLANFILE
        apply:
          steps:
          - run: terraform apply $PLANFILE
  8. Deploy Atlantis to Google Cloud Run

    main

    Deploying Atlantis to Google Cloud Run allows for a serverless, auto-scaling architecture. When deploying, use a dedicated service account for least-privilege security and configure a min_instance_count of at least 1 to avoid cold starts and the loss of in-memory ephemeral storage.

    Key environment variables for a Redis-backed Cloud Run deployment include:

    • ATLANTIS_LOCKING_DB_TYPE: Set to redis.
    • ATLANTIS_REDIS_HOST: The host of your Redis instance.
    • ATLANTIS_REDIS_DB: The Redis database index (e.g., 0).
    • ATLANTIS_DATA_DIR: The path for writable ephemeral storage.
    • ATLANTIS_USE_TF_PLUGIN_CACHE: Set to true to optimize provider downloads.
    resource "google_cloud_run_v2_service" "atlantis_management" {
      provider             = google-beta
      name                 = "atlantis-management"
      location             = "your-region"
      deletion_protection  = false
      ingress              = "INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER"
      invoker_iam_disabled = true
      launch_stage         = "GA"
    
      template {
        scaling {
          min_instance_count = 1
          max_instance_count = 1
        }
        execution_environment = "EXECUTION_ENVIRONMENT_GEN2"
        service_account       = google_service_account.atlantis_management.email
        containers {
          image = "ghcr.io/runatlantis/atlantis:v0.35.1"
          resources {
            limits = {
              cpu    = "1"
              memory = "2Gi"
            }
          }
          volume_mounts {
            name       = "atlantis"
            mount_path = "/app/atlantis"
          }
          env {
            name  = "ATLANTIS_PORT"
            value = "8080"
          }
          env {
            name  = "ATLANTIS_DATA_DIR"
            value = "/app/atlantis"
          }
          env {
            name  = "ATLANTIS_USE_TF_PLUGIN_CACHE"
            value = "true"
          }
          env {
            name  = "ATLANTIS_LOCKING_DB_TYPE"
            value = "redis"
          }
          env {
            name  = "ATLANTIS_REDIS_HOST"
            value = google_redis_instance.atlantis.host
          }
          env {
            name  = "ATLANTIS_REDIS_DB"
            value = "0"
          }
          env {
            name  = "ATLANTIS_ATLANTIS_URL"
            value = "https://management.atlantis.acme.com"
          }
          env {
            name  = "ATLANTIS_REPO_CONFIG_JSON"
            value = jsonencode(yamldecode(file("${path.module}/atlantis/management.yaml")))
          }
        }
        vpc_access {
          egress = "ALL_TRAFFIC"
          network_interfaces {
            network    = "your-network-id"
            subnetwork = "your-subnetwork-id"
          }
        }
        volumes {
          name = "atlantis"
          empty_dir {
            medium     = "MEMORY"
            size_limit = "5Gi"
          }
        }
      }
      project = "your-project-id"
    }
  9. Expose local Atlantis to GitHub via ngrok

    main

    To allow GitHub to call your local Atlantis instance, use ngrok to create a public tunnel.

    1. Start Atlantis in server mode (see Running Atlantis locally).
    2. Run ngrok on port 4141:
      ngrok http 4141
    3. Copy the https URL provided by ngrok.
    4. Configure a GitHub Webhook in your repository using that URL, appending /events to the end (e.g., https://<id>.ngrok.io/events).
    5. Create a pull request and type atlantis help to verify the connection.
    ngrok http 4141