GO — Healthy across the board

• Last commit 1d ago
• 38+ active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Atlantis is a self-hosted Go application that automates Terraform workflows in pull requests by listening for VCS webhooks, executing terraform plan, import, and apply commands remotely, and commenting results back to PRs. It bridges the gap between infrastructure-as-code and collaborative team workflows by making Terraform changes visible and executable directly from pull request comments. Monolithic Go application structured as a single package (github.com/runatlantis/atlantis) with webhook handlers as entrypoints. Server-side rendering via Go templates (.github/styles, Go Template 34KB). Web UI components in TypeScript/Vue (12KB + 2KB respectively under runatlantis.io/). Docker-first deployment model (Dockerfile, Dockerfile.dev, .clusterfuzzlite/Dockerfile for testing). Config-driven via .atlantis.yaml (HCL support 8.7KB) in per-repo atlantis configs.

DevOps engineers and infrastructure teams who use Terraform and want to centralize IaC workflows, enable non-ops engineers to safely propose infrastructure changes via PRs, and standardize approval/apply processes across their organization. GitHub, GitLab, and Bitbucket admins who need to audit all Terraform operations.

Production-ready and actively maintained. The project has 8000+ GitHub stars, comprehensive CI/CD via GitHub Actions (.github/workflows/test.yml, release.yml, atlantis-image.yml), OpenSSF Best Practices badge, multiple release channels (via .goreleaser.yml), and clear governance (MAINTAINERS.md, CODEOWNERS). Recent activity visible in Go version constraint (go 1.25.4) and actively updated dependencies (go-github v83/v84, renovate.json5 active).

Low risk for core functionality but moderate operational complexity. Single-sourced from github.com/runatlantis/atlantis as the canonical upstream; dependency surface spans GitHub API clients (github.com/google/go-github), GitLab API (gitlab.com/gitlab-org/api/client-go), and Terraform-adjacent tooling. No indication of stale code, but webhook-driven automation introduces state consistency concerns if multiple Atlantis instances run concurrently. Security posture is strong (OpenSSF scorecard, CodeQL scanning, SBOM/fuzzing via .clusterfuzzlite/), but operational misconfiguration could expose VCS credentials.

Active development with Copilot-guided contributions (.github/copilot-instructions.md), ongoing dependency updates (renovate.json5), security hardening (codeql.yml, dependency-review.yml), and fuzzing integration (.clusterfuzzlite/). Release workflow automated (release.yml), with cherry-pick bot for backports (cherry-pick-bot.yml). Recent focus on labeling (labeler.yml, pr-size-labeler.yml) and stale issue management (stale.yml).

git clone https://github.com/runatlantis/atlantis.git && cd atlantis && make build && make test. Requires Go 1.25.4+ (see go.mod in e2e submodule). Docker alternative: docker build -t atlantis . -f Dockerfile.

Daily commands: make test (runs Go tests), make build (compiles binary to dist/), docker-compose up (if testing locally with postgres). See Makefile for targets. For server: atlantis server --config atlantis.yaml --repo-allowlist='*'.

• main.go — Entry point of the Atlantis server application; all contributors must understand the initialization flow
• cmd/server.go — Core CLI command that configures and starts the Atlantis server; essential for understanding configuration and runtime behavior
• go.mod — Defines all direct dependencies including GitHub/GitLab API clients and Terraform tooling; critical for dependency management and version control
• .github/workflows/test.yml — CI/CD pipeline definition that runs tests and builds; contributors must understand the test requirements and release process
• Dockerfile — Production container image definition; shows runtime environment, dependencies, and deployment configuration
• e2e/e2e.go — End-to-end test harness that validates the complete Terraform automation workflow; demonstrates expected behavior
• CONTRIBUTING.md — Development guidelines and contribution workflow; mandatory reading for any contributor to this project

Add a new CLI command

1. Create a new command file in cmd/ directory following the pattern of cmd/server.go (cmd/newcommand.go)
2. Register the command in the root command structure (cmd/root.go)
3. Add tests for the new command (cmd/newcommand_test.go)
4. Update documentation in the website (runatlantis.io/docs/guides/deploying-atlantis.md)

Add support for a new VCS provider

1. Create VCS-specific implementation file (e.g., e2e/bitbucket.go) mirroring github.go or gitlab.go structure (e2e/bitbucket.go)
2. Implement the VCS interface defined in e2e/vcs.go (e2e/vcs.go)
3. Add VCS-specific test cases to e2e/main.go (e2e/main.go)
4. Update the CI workflow to test the new VCS provider (.github/workflows/test.yml)

Add a new feature with proper testing

1. Create core feature implementation in appropriate package (cmd/server.go)
2. Create unit tests alongside implementation (cmd/server_test.go)
3. Add end-to-end test validation in e2e test suite (e2e/e2e.go)
4. Document the feature in website docs or README (README.md)

Update deployment configuration

1. Modify container build configuration (Dockerfile)
2. Update Kubernetes manifests (kustomize/kustomization.yaml)
3. Update container build workflow if needed (.github/workflows/atlantis-image.yml)
4. Test with local docker-compose if applicable (docker-compose.yml)

• Go/Golang — Compiled, statically-typed language ideal for CLI tools and infrastructure automation; excellent concurrency support for handling multiple webhook events
• Docker & Kubernetes — Industry-standard containerization for reproducible deployments; Kustomize enables flexible configuration management across environments
• GitHub & GitLab APIs — Direct VCS integration allows Atlantis to read pull requests, post comments, and manage permissions without proxy layers
• VitePress — Static site generator for documentation; provides low-overhead, performant hosting of guides without server-side rendering
• GitHub Actions — Native CI/CD platform for the repository; simplifies testing, building, and releasing without external service dependencies

• Monolithic binary application rather than microservices

  • Why: Simpler operational model, single deployment unit, reduced network overhead for webhook processing and Terraform execution
  • Consequence: Vertical scaling only; all features must coordinate within one process; failure of one component affects entire service

• VCS webhooks as primary event source

  • Why: Real-time responsiveness to PR events; eliminates polling overhead; decentralized event delivery
  • Consequence: Requires exposed webhook endpoint; webhook delivery ordering not guaranteed; webhook replay handling must be idempotent

• In-process state storage (not explicitly persistent)

  • Why: Simpler initial deployment; reduces database dependencies; stateless-friendly for container environments
  • Consequence: State loss on restart; horizontal scaling requires external state coordination (e.g., via pull request comments or external database)

• Direct Terraform binary execution

  • Why: Maximum compatibility with Terraform ecosystem; no translation layer or custom DSL
  • Consequence: Terraform binary must be present in runtime; version management overhead; potential security risks from untrusted Terraform configurations

• Does not provide a hosted SaaS offering; targets self-hosted deployment
• Not a Terraform state backend; does not replace Terraform remote state storage
• Does not manage non-Terraform infrastructure workflows (Ansible, CloudFormation, etc.)
• Not designed for real-time collaboration UI; focuses on async PR-based workflow

Webhook signature validation required (HMAC secrets for GitHub/GitLab); if misconfigured, unauthenticated requests can trigger terraform operations. State consistency: no built-in distributed lock if multiple Atlantis instances serve same repos. Terraform binary must be in PATH or configured explicitly at startup (not bundled in minimal images). GitHub App vs. OAuth token behavior differs (installation ID, permissions). VCS rate limits can block concurrent PR operations; no built-in queue backpressure. .atlantis.yaml merge strategy with defaults can be non-obvious (nested project + workspace configs).

• Webhook-driven automation — Atlantis's entire execution model is event-driven by VCS webhooks; understanding pull request lifecycle hooks (opened, synchronize, commented) is critical to debugging why terraform commands do/don't trigger
• Terraform state locking and consistency — Atlantis manages remote terraform execution where state mutations happen server-side; misconfigured locking (DynamoDB, Consul, S3) can cause concurrent apply conflicts that corrupt infrastructure
• VCS OAuth / App-based authentication — Atlantis must authenticate as either a user-scoped OAuth token or a machine GitHub App; permission scopes and token expiry differ significantly, affecting secret rotation strategy
• Terraform plan JSON output parsing — Atlantis parses -json terraform plan output to construct readable PR comments; understanding the plan schema helps when adding custom formatting or filtering logic
• PR comment idempotency — Atlantis must handle re-runs and updates to existing plan comments without duplicating or orphaning old comments; requires tracking comment IDs across VCS platforms
• HMAC webhook signature validation — All incoming webhooks must be cryptographically verified against a shared secret; failure to validate allows attackers to trigger terraform applies on arbitrary repos
• Subprocess isolation and Terraform plugin caching — Atlantis spawns terraform as a child process with per-repo working directories; plugin cache location, credential injection, and temp file cleanup must be carefully managed to avoid cross-repo state leakage

• hashicorp/terraform — Atlantis is built on top of Terraform CLI; understanding Terraform state and command semantics is essential
• terraform-linters/tflint — Complementary tool often integrated into Atlantis workflows for policy-as-code linting before apply
• snyk/snyk-infrastructure-as-code — Security scanning companion for IaC; Atlantis can invoke it in pre-apply hooks
• bridgecrewio/checkov — Policy-as-code framework frequently integrated into Atlantis to enforce compliance on terraform plans
• scalefactory/kops — Kubernetes cluster provisioning use case that heavily relies on Atlantis for GitOps-style Terraform automation

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for e2e GitHub and GitLab client workflows

The e2e module has go.mod dependencies for github.com/google/go-github and gitlab.com/gitlab-org/api/client-go, but the e2e directory structure is sparse (only .gitignore visible). New contributors can add concrete e2e tests that exercise the GitHub and GitLab integrations, validating PR automation workflows end-to-end. This directly improves test coverage for the core Atlantis functionality.

• [ ] Review existing test patterns in cmd/server_test.go and main test files
• [ ] Create e2e/github_integration_test.go with tests for GH installation auth (bradleyfalzon/ghinstallation)
• [ ] Create e2e/gitlab_integration_test.go with tests for GitLab API client workflows
• [ ] Add test fixtures for mock PR events and verify Atlantis processes them correctly
• [ ] Document test setup requirements in e2e/README.md

Add GitHub Actions workflow for Go security scanning and SAST analysis

While the repo has codeql.yml and dependency-review.yml workflows, there is no dedicated Go-specific security linting workflow. The .golangci.yml config exists but isn't explicitly run in a dedicated workflow. A new contributor can create a workflow that runs gosec (Go Security Scanner) and integrates golangci-lint security rules, adding another layer of vulnerability detection for a Terraform automation tool handling sensitive infrastructure.

• [ ] Create .github/workflows/go-security.yml that runs on pull requests and scheduled intervals
• [ ] Add gosec scanning step with appropriate configuration for the atlantis codebase
• [ ] Add golangci-lint with security linters enabled (gosec, sqlc, etc.) referencing .golangci.yml
• [ ] Configure upload of results to GitHub Security tab
• [ ] Test workflow on a branch before submitting PR

Add missing unit tests for cmd/bootstrap.go and cmd/help_fmt.go

While cmd/server_test.go exists, the cmd/bootstrap.go and cmd/help_fmt.go files have no corresponding _test.go files in the visible file structure. These initialization and CLI formatting utilities should have unit test coverage. A new contributor can add tests for bootstrap configuration parsing and help message formatting, improving reliability of the CLI experience.

• [ ] Create cmd/bootstrap_test.go with tests for bootstrap configuration loading and validation
• [ ] Create cmd/help_fmt_test.go with tests for help text formatting edge cases (long flags, descriptions)
• [ ] Add test cases for error scenarios (missing config, malformed input)
• [ ] Verify tests pass with 'make test' or appropriate test command
• [ ] Ensure new tests follow the pattern established in cmd/server_test.go

• Add integration tests for GitLab webhook event parsing (server/events/event_parser.go has GitHub/Bitbucket tests, GitLab coverage sparse)
• Document terraform binary version pinning strategy in runatlantis.io/ docs and add validation to reject mismatched versions
• Implement health check endpoint (/health) for Kubernetes readiness probes; currently no liveness indicator in server/server.go

The Atlantis codebase demonstrates good security practices with pinned Docker image digests, proper use of digest-based image references, and maintained security policy documentation. However, there are concerns around hardcoded credentials in development configuration files, overly permissive volume mounts, and potential missing security header implementations. The project maintains only the latest two minor releases for security updates, which is a reasonable policy. Primary recommendations: migrate credential management away from hardcoded values, restrict container volume access, and explicitly implement security headers. The codebase shows OpenSSF scorecard and best practices badges, indicating active security consideration.

• Medium · Hardcoded Redis Password in docker-compose.yml — docker-compose.yml (redis service). The Redis service is configured with a hardcoded password 'test123' in the docker-compose.yml file. While this is marked as a development-only file, hardcoded credentials should never be used even in development environments as the file may be accidentally committed or shared. Fix: Use environment variables or .env files to manage sensitive credentials. Load the password from atlantis.env or use docker secrets in production. For development, consider using a unique per-developer password or removing the requirepass requirement for local development only.
• Medium · Overly Permissive Docker Volume Mount — docker-compose.yml (atlantis service volumes). The docker-compose.yml mounts the user's SSH directory (/.ssh:ro) and the entire project source directory into the container. While read-only, this increases the attack surface if the container is compromised, allowing access to SSH keys and source code. Fix: Limit volume mounts to only necessary directories. Consider using SSH agent forwarding instead of mounting .ssh directory. Implement proper container security policies and network segmentation.
• Low · Unspecified Latest Image Tag for ngrok — docker-compose.yml (ngrok service image). The ngrok service uses 'ngrok/ngrok:latest' with a pinned digest, but latest tags can still cause unexpected behavior. While the digest pinning provides some protection, this is a development image and should be more strictly versioned. Fix: Use specific version tags instead of 'latest' (e.g., 'ngrok/ngrok:3.x.x'). Document the exact version being used and update deliberately rather than automatically.
• Low · Missing Security Headers Configuration — Server configuration (cmd/server.go and related). The codebase appears to be a web application (Terraform automation tool) but no explicit security headers configuration is visible in the analyzed files. Standard security headers like CSP, X-Frame-Options, X-Content-Type-Options may be missing. Fix: Implement standard security headers in all HTTP responses. Add Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, X-XSS-Protection, and Strict-Transport-Security headers.
• Low · Development Credentials in atlantis.env — docker-compose.yml (env_file references). Reference to 'atlantis.env' file in docker-compose.yml suggests environment variables are stored in a file. This file is not shown but is often used for sensitive configuration and should be carefully managed. Fix: Ensure atlantis.env is properly added to .gitignore and never committed to the repository. Use secrets management systems in production. Document required environment variables in a template file (e.g., atlantis.env.example).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/runatlantis/atlantis shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live runatlantis/atlantis repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/runatlantis/atlantis.

What it runs against: a local clone of runatlantis/atlantis — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in runatlantis/atlantis | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of runatlantis/atlantis. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/runatlantis/atlantis.git
#   cd atlantis
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of runatlantis/atlantis and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "runatlantis/atlantis(\\.git)?\\b" \\
  && ok "origin remote is runatlantis/atlantis" \\
  || miss "origin remote is not runatlantis/atlantis (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "main.go" \\
  && ok "main.go" \\
  || miss "missing critical file: main.go"
test -f "cmd/server.go" \\
  && ok "cmd/server.go" \\
  || miss "missing critical file: cmd/server.go"
test -f "go.mod" \\
  && ok "go.mod" \\
  || miss "missing critical file: go.mod"
test -f ".github/workflows/test.yml" \\
  && ok ".github/workflows/test.yml" \\
  || miss "missing critical file: .github/workflows/test.yml"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/runatlantis/atlantis"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.