When would you run Terraform through a purpose-built run service such as Atlantis or HCP Terraform instead of hand-written plan and apply jobs in your existing CI system?

## The three shapes **Hand-rolled CI jobs.** Your existing CI system checks out the repo, installs Terraform, and runs plan and apply. Credentials are federated to the job. The pipeline definition lives in the repository, next to the code it applies. **Atlantis.** A self-hosted service that listens to pull-request webhooks. On a PR it runs plan for the affected projects and posts the output back as a comment; engineers drive it by commenting `atlantis plan` and `atlantis apply` on the PR, and it holds its own lock on a project and workspace until the PR is merged or closed, so a second PR touching the same project is told which PR is blocking it. It executes Terraform itself, so your CI system never touches cloud credentials. **HCP Terraform** (the hosted service formerly called Terraform Cloud). It goes further: it hosts the state, connects directly to the VCS repository, produces a speculative plan on every PR, queues runs per workspace, holds the variables and credentials as workspace configuration, and keeps a durable run history with the plan, the approver and the result attached. Applies wait for confirmation in its own UI or API. Where infrastructure is not internet-reachable, agents run inside your network and poll for work. ## What you are actually buying 1. **A credential boundary.** In the hand-rolled shape, the CI system is the thing with the power to change production, so its supply chain — every action, every plugin, every fork trigger — is in scope for that power. A run service moves the credentials out, leaving CI with only the ability to ask for a run. 2. **Uniformity without copy-paste.** Forty repositories with hand-written pipelines become forty slightly different pipelines. Their drift is invisible until the one that skipped the validation step ships something bad. A run service applies the same lifecycle everywhere by construction. 3. **Serialisation and locking as a product feature.** Both tools queue per project or workspace out of the box, which removes the concurrency design work you would otherwise do per pipeline. 4. **Audit and evidence.** "Show me every production change last quarter, who approved it, and the diff" is a query against one run history rather than an archaeology exercise across CI logs with expired retention. 5. **A hook for guardrails.** Policy evaluation attaches to the run itself rather than being re-wired into each pipeline. ## What you pay - **An operational dependency.** Atlantis is a service you run, upgrade, secure and make highly available; when it is down, nobody ships infrastructure. HCP Terraform is somebody else's uptime and a per-resource bill that scales with the size of your estate. - **Reduced flexibility.** Bespoke steps — a pre-plan schema migration, a custom cost check, an unusual credential broker — are trivial in a general-purpose pipeline and awkward inside an opinionated run lifecycle. - **Network placement.** A hosted service cannot reach a private VPC endpoint. That means agents inside the network, which is another fleet to run, and one that holds the credentials. - **Coupling to the tool's model.** Workspace-per-environment, VCS-driven runs and the service's variable handling become how your team thinks. Migrating away later is a project. ## The decision I would use hand-rolled jobs while the estate is small, one team owns it, and the pipeline definition fits on a screen — the transparency is worth more than the features. I would move to a run service when at least two of these are true: pipeline YAML is duplicated across many repositories and has begun to drift; the audit question is asked by someone outside the team and the current answer is unconvincing; the CI system's blast radius has become the security concern rather than the cloud permissions themselves; or engineers outside the platform team need to make infrastructure changes and need a guided path rather than a set of conventions. Between the two, the axis is control versus completeness. Atlantis keeps state and backend choices yours and costs only the effort of running it, which suits an organisation that already has strong platform capability and dislikes vendor coupling. HCP Terraform takes over state and run history too, which is exactly what an organisation without that capability wants — and exactly the coupling the first one is avoiding. Whichever you choose, the pipeline shape underneath does not change: plan is a preview a human reads, apply is bound to reviewed code, credentials are short-lived, and runs against one state are serialised. The service automates that shape; it does not replace it.