Atlantis Walkthrough

This video is a 2017 demo by the Atlantis project showing how to bootstrap and use Atlantis to run a Terraform workflow through GitHub pull requests. The core pitch is that Atlantis gives Terraform a pull-request-native collaboration model: reviewers can see the exact plan and apply output without leaving GitHub, and concurrent changes are serialized through project-level locks.

Bootstrapping Atlantis

The presenter starts Atlantis locally and runs bootstrap. The first prompt asks for a GitHub username, then a GitHub personal access token (PAT) with repo scope so Atlantis can read the repository and comment on pull requests. The bootstrap then forks an example repository into the user’s organization and opens a pull request to demonstrate the workflow.

PAT hygiene note: The demo uses a classic PAT scoped to repo, which is a long-lived credential. Modern deployments should prefer GitHub App authentication or short-lived tokens with minimal permissions. See GitOps Security for current PAT best practices.

The atlantis plan feedback loop

The first PR adds a null_resource to the example Terraform project. The reviewer types atlantis plan in a PR comment. Atlantis runs terraform plan in the background and posts the output as a comment on the pull request. This makes the proposed change visible to the whole team before anyone approves it.

The presenter emphasizes that this removes the need for reviewers to manually check out the branch, run terraform plan locally, or paste screenshots into the PR. The plan output lives in the PR, tied to the exact commit.

Concurrency and project locking

The demo then creates a second pull request while the first one is still open. When the reviewer runs atlantis plan on the second PR, Atlantis reports that the project is locked by the first pull request. This prevents two Terraform applies from running against the same state at the same time, which is the classic Terraform concurrency hazard.

The lock is released only after the first PR is merged. Once the first PR is applied and merged, the second PR can be re-planned. The plan now shows both null_resource additions because the state has advanced.

The atlantis apply gate

After the plan is reviewed, the reviewer runs atlantis apply. The tool runs terraform apply and posts the apply output as another PR comment. The demo shows that this can be configured to require approvals before apply, adding a manual gate to destructive changes.

Centralized credentials

A secondary benefit mentioned is that developers do not need local AWS credentials (or any cloud credentials) as long as the host running Atlantis has them. The Terraform execution is centralized through the Atlantis server, and the developer only interacts with GitHub.

Synthesis

This 2017 video captures the foundational Atlantis value proposition: bring Terraform into the same code-review workflow as application code. The pattern is now a standard GitOps/IaC collaboration primitive: plan-on-PR, approve, apply-on-merge, and serialize concurrent access to shared state. Modern implementations may also use GitHub Actions, GitLab CI, or specialized platforms, but the workflow mechanics shown here remain the same.

See Also

Wiki Concepts

• Atlantis — Terraform collaboration server and PR-driven workflow
• Terraform — HashiCorp’s infrastructure-as-code tool
• GitOps Security — PAT hygiene, branch protection, and PR workflow hardening
• DevSecOps Fundamentals — where IaC validation and policy enforcement fit in the pipeline
• Shift Left Security — finding IaC misconfigurations before deploy
• Container Security — IaC misconfiguration as an attack surface
• Kubernetes Disaster Recovery — Infrastructure-as-Code as a recovery layer
• CKA Study Roadmap — Terraform security as a post-CKA specialization

Related Sources

• DevOps to DevSecOps in 9 Hours — modern DevSecOps pipeline including IaC scanning

Creator / Entity

• The video is hosted by the official Atlantis project channel (no dedicated entity page yet).