Alternative to Atlantis
Tags: atlantis, terraform, devops, cicd
Published: 2021-10-24 23:13:32

Atlantis is an old and battle-tested self-hosted tool that provides a layer of automation and collaboration for Terraform. Lacking a user interface other than server [flags](https://www.runatlantis.io/docs/server-configuration.html#flags) and [YAML configuration files](https://www.runatlantis.io/docs/server-side-repo-config.html#do-i-need-a-server-side-repo-config-file), Atlantis uses your VCS as one, listening for pull request notifications and posting feedback as comments.

Using Atlantis has two major benefits over running Terraform in a “generic” CI system. First, it strikes the right balance between specialized and flexible: [custom workflows](https://www.runatlantis.io/docs/custom-workflows.html) give you a level of control that’s not possible within a tool like [Terraform Cloud](https://www.terraform.io/docs/cloud/index.html). Second, it runs on your infrastructure, which allows it to access resources inside a VPC or use cloud-specific dynamic credentials.

Spacelift embraces all those characteristics of Atlantis but offers them in as a modern and sophisticated SaaS product that provides:

* a more intuitive, [versatile](https://docs.spacelift.io/concepts/policy/git-push-policy) and [robust](https://docs.spacelift.io/concepts/run#run-state-machine) workflow;
* extremely granular access controls on [account](https://docs.spacelift.io/concepts/policy/login-policy) and [project level](https://docs.spacelift.io/concepts/policy/stack-access-policy) that work well with [an identity provider of your choice](https://docs.spacelift.io/integrations/single-sign-on) (SSO);
* an [automated code review](https://docs.spacelift.io/concepts/policy/terraform-plan-policy) and [threat detection](https://docs.spacelift.io/concepts/policy/task-run-policy) using a consistent open-source [policy-as-code framework](https://www.openpolicyagent.org/);
* the ability to [declare complex workflows](https://docs.spacelift.io/concepts/policy/trigger-policy) between projects across multiple repositories;
* a [built-in private module registry](https://docs.spacelift.io/concepts/modules) with a full CI system for modules;
* effortless setup and customization with [per-project environment management](https://docs.spacelift.io/concepts/configuration/environment) and [Docker integration](https://docs.spacelift.io/integrations/docker);
* [programmatic configuration](https://docs.spacelift.io/integrations/terraform-provider) using Terraform;
* [drift detection](https://docs.spacelift.io/concepts/stack/drift-detection);
* … and a myriad of creature comforts like [contexts](https://docs.spacelift.io/concepts/configuration/context), [tasks](https://docs.spacelift.io/concepts/run/task) or [stack locking](https://docs.spacelift.io/concepts/stack#stack-locking);

Let’s talk through each of these features one by one.

#1) Workflow

One of most frequent challenges while using Atlantis in practice is a non-intuitive workflow driven by its reliance on pull requests. Not only is it a lot of work to set up multiple [workspaces](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#use-cases) pointing to the same Git repository but the result is fragile and nondeterministic. Since there’s no concept of mapping projects to branches or tags, anyone that can comment on an approved pull request can deploy arbitrary code to production, even if the approval was meant for a short-lived experimental environment.

Spacelift does not depend on pull requests. Sure, it will post beautiful comments there for your convenience, but it’s mostly driven by push and tag events, so it’s easy to build a sophisticated Git flow. Spacelift will report the outcome of its jobs as commit status checks, which then allows you to block merging the code on a failing Spacelift check. There are [two main types of runs](https://docs.spacelift.io/concepts/run#where-do-runs-come-from) – proposed and tracked. By default, each project points at a particular branch (and optionally also a path) – pushing to that branch will trigger a tracked run – one that can be applied. This behavior can be customized using [Git push policies](https://docs.spacelift.io/concepts/policy/git-push-policy). Thanks to that, Spacelift can provide the same level of comfort and security to teams using one project per repository and those using monorepos with hundreds of interdependent projects. You can read more about our approach to VCS integration [here](https://docs.spacelift.io/integrations/source-control/github#tracked-branches).

#2) Access Control

Another pain point when using Atlantis at scale is its access control model. By relying on comments on pull requests to drive infrastructure deployments, Atlantis effectively yields control over your infrastructure to the VCS provider. While this is usually fine when a single repository drives a single Terraform project, this becomes a huge liability for more complex scenarios.

Spacelift ships with a sophisticated mechanism allowing administrators to declare [who can log in](https://docs.spacelift.io/concepts/policy/login-policy) (and under what circumstances) and [what should be their level of access](https://docs.spacelift.io/concepts/policy/stack-access-policy) to each of the managed projects. Since it’s 2020, Spacelift ships with SSO out of the box, supporting every identity provider that speaks SAML 2.0 protocol. Even our [Slack integration](https://docs.spacelift.io/integrations/slack) can be subject to policy controls, allowing an admin to grant access to a project [based on Slack-specific data](https://docs.spacelift.io/integrations/slack#managing-access-to-stacks-with-policies) (think team, channel, user etc.). For extra protection, powerful features like Tasks have their own independent policy controls.

#3) Policy Framework

Both Spacelift and Atlantis let you use [Open Policy Agent](https://www.openpolicyagent.org/) – an open-source solution endorsed by [Cloud Native Computing Foundation](https://www.cncf.io/) – to ensure that your infrastructure is compliant with industry best practices and your company policies. Atlantis integrates with [conftest](https://www.runatlantis.io/docs/policy-checking.html#how-it-works) to achieve that and lets you verify each Terraform plan using OPA policies.

Spacelift goes a few steps further though and puts policy-as-code in the center of its value proposition and builds a consistent, [robust policy framework](https://docs.spacelift.io/concepts/policy). Apart from providing a comprehensive automated change review and ensuring compliance of your [Terraform changes](https://docs.spacelift.io/concepts/policy/terraform-plan-policy), Spacelift uses the same approach to allow you to declare rules around [account](https://docs.spacelift.io/concepts/policy/login-policy) and [project access](https://docs.spacelift.io/concepts/policy/stack-access-policy), [handling push notifications](https://docs.spacelift.io/concepts/policy/git-push-policy), [starting runs](https://docs.spacelift.io/concepts/policy/run-initialization-policy) and [triggering tasks](https://docs.spacelift.io/concepts/policy/task-run-policy), and creating [relationships between projects](https://docs.spacelift.io/concepts/policy/trigger-policy). It also provides the Policy Workbench, which lets you view past executions of your policy – including the inputs and decisions that have been made – and lets you interactively edit your policy, while simulating its execution on these previous inputs. You can use our [starter repo](https://github.com/spacelift-io/terraform-starter) to quickly provision a bunch of policies and get a feel for how you can work with them in Spacelift.

#4) Complex Workflows

Handling interdependencies between projects has always been Terraform’s Achilles’ heel and Atlantis is no different in that regard. The usual approach to this problem is adding another layer of abstraction in the form of a Terraform wrapper like [Terragrunt](https://terragrunt.gruntwork.io/). While this breaks the problem into smaller chunks, it’s only a partial solution achieved at a cost of locking yourself into another dependency.

[Spacelift’s trigger policies](https://docs.spacelift.io/concepts/policy/trigger-policy) on the other hand provide a smart, declarative automation layer on top of vanilla Terraform. These allow you to plug into state changes of individual projects and declare dependencies that should be resolved following the changes that have just been applied. In fact, this is just a subset of all use cases covered by trigger policies. [Read more](https://docs.spacelift.io/concepts/policy/trigger-policy) to discover other exciting possibilities.

#5) Private Module Registry

Another problem that one needs to solve externally when using Atlantis is authoring and maintaining reusable Terraform modules for your organization. Terraform is flexible in allowing modules to come from [various sources](https://www.terraform.io/docs/language/modules/sources.html) but ensuring confidential access as well as testing and versioning are left to you, the user.

Until now, the golden standard in that regard has been the [private module registry from HashiCorp](https://www.terraform.io/docs/cloud/registry/index.html). But Spacelift offers that, and much more. Far from being just a glorified package manager, Spacelift adds a [full CI solution for Terraform modules](https://docs.spacelift.io/vendors/terraform/module-registry), out of the box and free of charge. You can thus ensure that your private modules are healthy before you distribute them to the rest of your organization.

#6) Effortless Setup and Customization

If you manage a single or a handful of rarely changing projects using Atlantis, it’s likely that you just set it up once and forget about it. But in a more dynamic environment, where microservices come and go, new environments proliferate and new product teams require their own Terraform workspaces, the need to configure Atlantis each and every time becomes a major nuisance putting a lot of pressure on your DevOps team.

Enter Spacelift. In Spacelift, much of the configuration can be handled by the project owners themselves – you can add Terraform and/or [environment variables](https://docs.spacelift.io/concepts/configuration/environment) and mount files (even inject Terraform code!) programmatically or through the GUI without the need for administrative privileges or changing the central server configuration. For administrators, adding new projects requires minimal hassle since there’s no need to set up webhooks or change any YAML. And it can all be done programmatically, using Terraform.

#7) Programmatic Configuration

What comes as a pleasant surprise to long-time Atlantis users, Spacelift entities like stacks, contexts, modules or policies as well as their configuration can be managed in a declarative way using your favorite infra-as-code tool. Yes, that’s right – [Spacelift offers a Terraform provider](https://docs.spacelift.io/vendors/terraform/terraform-provider) that allows you to manage the lifecycle of its own resources programmatically.

Administrative stacks get credential-less access to the subset of our [GraphQL API](https://docs.spacelift.io/integrations/api) that does not involve managing the actual infrastructure. For more sophisticated use cases, Spacelift allows you to generate API keys that are subject to the same access controls as normal users are, allowing you to create single-purpose tokens for restricted use by your internal scripts.

#8) Drift Detection

[Infrastructure drift happens](https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform). Either somebody will make manual changes while debugging and then forget about them, or you might have data sources whose outputs change periodically. Normally, you would notice these changes only after you execute your next plan or apply.

Spacelift has got you covered here. You can configure periodic [drift detection](https://docs.spacelift.io/concepts/stack/drift-detection) to be notified whenever drift happens and take immediate action. You can go a step further too with optional automatic [reconciliation](https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile), ensuring your infrastructure always resembles your Terraform configuration.

#9) Creature Comforts

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. [Contexts](https://docs.spacelift.io/concepts/configuration/context) for example allow you to attach entire collections of configuration to individual stacks and modules. [Tasks](https://docs.spacelift.io/concepts/run/task) provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment – subject to [their own policy constraints](https://docs.spacelift.io/concepts/run/task). [Stack locking](https://docs.spacelift.io/concepts/stack#stack-locking) allows a single individual to take exclusive control over a stack to ensure that nobody is able to modify its state while crucial changes are being made. The [resources visualization](https://docs.spacelift.io/concepts/resources) shows you all the resources you’re managing in your account, when and how they’ve last been updated, and lets you slice and dice them using a plethora of views, filters and groupings.