When deploying a stack of infrastructure units, Pipelines will concurrently generate a plan for all the infrastructure units in the stack, and display them in a single pull request / merge request comment as separate plans.

Pipelines uses an "apply after merge" approach. This means that while multiple PRs are proposing changes to the same resources, there’s only ever a single source of truth for the infrastructure that will be provisioned (the Infrastructure as Code on the deploy branch e.g. main). During initial implementation we guide teams to using features of their SCM platform to enforce branch protection rules that ensure that plans are recent and applies are predictable.

Pipelines natively integrates with the Terragrunt CLI to drive infrastructure updates through the Directed Acyclic Graph (DAG). When creating or updating multiple infrastructure components, dependencies will be created or updated before dependents (e.g. VPCs before servers), and when deleting infrastructure components, dependents will be destroyed before dependencies (e.g. servers before VPCs). This ordering is applied even if infrastructure is deployed through different units.

Yes, you can make changes to infrastructure components within any number of different environments (e.g. AWS accounts) at the same time in the same PR, and the pipeline will update them concurrently on merge.

Access control to infrastructure is segmented by least privilege principals (e.g. AWS IAM roles) that only have access to individual environments, further segmented by a different principal used for read-only access during pull requests / merge requests open and a principal used for read-write access during pull request merge.

As a consequence, updates to a particular environment will only be done by a principal that only has access to that environment, and can only be used after review by your team.

Pipelines takes full advantage of state isolation using Terragrunt to ensure that infrastructure is only updated if a corresponding code-change would impact that resource.

When you create a PR, Pipelines will run a plan on units affected by the code change. The plan output shows in the PR comments with: (1) a clear plan summary of what specific infrastructure resources were impacted, and (2) a full plan output of what's changing. When you merge the PR, it kicks off the CI/CD pipeline to apply it.

Pipelines is flexible and can be configured to support your repository structure using HCL Configurations as Code. You programmatically define the relationship your Infrastructure as Code has to your environments, and Pipelines will operate in those environments accordingly. Pipelines supports dependencies between Terragrunt units, even if those units are in different environments or require different cloud authentication credentials.

Both are supported.

Usage of OIDC-based credential acquisition means that repositories are trusted to assume particular credentials in target environments. You can delegate management of limited infrastructure to separate repositories, or have all your infrastructure managed in one repository. Pipelines and Terragrunt are designed to scale to very large and sophisticated monorepo structures.

Pipelines uses a GitHub app in GitHub and a GitLab machine user in GitLab to authenticate with the respective Source Code Management (SCM) provider.

When authenticating with cloud providers, Pipelines will perform an OIDC handshake between the repository in the SCM and a principal in a given environment to acquire temporary, least privilege credentials for the actions it needs to perform in that environment. Pipelines also provides an escape-hatch mechanism which allows developers to implement a per-environment custom authentication mechanism to authenticate with arbitrary APIs and pass those credentials into Terragrunt at runtime.

Pipelines creates a clear audit trail of infrastructure changes by tagging each cloud authentication session with unique identifying information of what change initiated that session. In addition, PRs with plan outputs that can be reviewed and approved before merging. Both GitHub and GitLab also provide branch protection rules that require approval before merges. This provides an audit trail of requested changes and approval.

Yes, you can reuse workflow templates across multiple projects or environments and author any steps you want in addition to the ones provided by Gruntwork. Pipelines uses standard GitHub Actions and GitLab CI Pipelines to drive infrastructure updates.

You have full control. All workflows are defined and run in your repository, you can add custom steps, and you're not dependent on calling Gruntwork for infrastructure changes.

Drift detection runs as a GitHub actions workflow / GitLab CI Pipeline at the root of your repository or within a subset (like a directory defining the infrastructure for a specific AWS account). It compares the contents of your Infrastructure as Code (IaC) code against the state of your infrastructure in your cloud environments (e.g. deployed in AWS). When it finds drift (like someone opening port 22 in the AWS console without making a corresponding change in IaC), it creates a PR/MR to remediate the drift by reverting deployed infrastructure to the designated configuration defined in IaC. You can review the impact of remediating the drift in a comment on the PR/MR, then either update the IaC to match the drift, or merge the PR/MR as is to re-apply the IaC specified configuration.

If you are suffering from infrastructure that’s experiencing significant drift from your IaC, first, run drift detection in each environment one-by-one to gradually remediate drift over time. Once you are confident your deployed infrastructure is aligned with the configuration you’ve defined using IaC, schedule automatic runs of Drift Detection once a week to ensure you do not accrue drift.