Atlantis Server Setup & Workflow Prompt

You are an SRE who has run Atlantis at scale and knows its sharp edges. Help me deploy and configure a hardened Atlantis server for PR-based Terraform.

I will provide:
- VCS (GitHub/GitLab/Bitbucket) and hosting target (ECS, K8s, VM)
- Repos and directory layout to manage
- Cloud auth method and backend type
- Team workflow (who plans, who applies, required approvals)

Your job:

1. **Deployment shape** — recommend the runtime (container on ECS Fargate vs Kubernetes Deployment vs systemd), persistent volume for the data dir, and how to expose the webhook endpoint securely behind TLS.

2. **Server-side repo config** — author `repos.yaml` with an explicit `id` allowlist (never `/.*/` in prod), `allowed_overrides`, and `apply_requirements: [approved, mergeable, undiverged]`. Explain each requirement.

3. **Server-side workflows** — define named workflows (e.g. `default`, `with-policy`) so repo-side `atlantis.yaml` cannot inject arbitrary commands. Show a custom plan stage that runs `terraform plan` plus a Conftest/OPA `policy_check`.

4. **Project discovery** — configure `autoplan` with `when_modified` globs and decide between per-directory projects vs a project-generation step for many stacks.

5. **Locking model** — explain Atlantis apply locks, how a long-lived PR blocks others on the same project, and a convention for unlocking safely.

6. **Cloud credentials** — inject short-lived credentials (IRSA, instance profile, Workload Identity) rather than static keys, scoped per workflow if possible.

7. **Webhook security** — set `--repo-allowlist`, a strong `--webhook-secret`, and restrict the `--gh-app-id`/token scopes. Note the SSRF and command-injection risks of running untrusted PR code.

8. **Operations** — log/audit `atlantis apply` events, set `--parallel-plan`/`--parallel-apply` limits, and define an upgrade and backup procedure for the data dir.

Output as: (a) the deployment manifest, (b) `repos.yaml`, (c) an example repo-side `atlantis.yaml`, (d) the webhook + secret setup, (e) an operational runbook covering locks, upgrades, and incident recovery.

Bias toward: server-side control of workflows, least-privilege cloud auth, explicit allowlists over wildcards.