Implement CI/CD for Your Infrastructure

By Pulumi Team
Published
Updated

The Challenge

You need to automate your infrastructure deployment workflow so that changes are reviewed, tested, and deployed consistently. Running Pulumi commands manually is error-prone and does not scale as your team grows. A CI/CD pipeline ensures every infrastructure change goes through preview, review, and controlled deployment.

What You'll Build

  • Automated preview on pull requests
  • Infrastructure testing configured
  • Automated deployments on merge to main
  • Approval gates for production deployments
  • Deployment notifications

Neo Try This Prompt in Pulumi Neo

Run this prompt in Neo to deploy your infrastructure, or edit it to customize.

Best For

Use this prompt when you want to move from manual pulumi up commands to an automated deployment workflow. This is essential for teams with multiple contributors, applications with dev/staging/production environments, or any project where infrastructure changes need review before they reach production.

Architecture Overview

This architecture creates a CI/CD pipeline specifically designed for infrastructure code managed by Pulumi. Unlike application CI/CD where the output is a build artifact, infrastructure CI/CD produces a preview of planned changes on pull requests and executes those changes on merge. This workflow gives reviewers visibility into exactly what resources will be created, modified, or destroyed before any change reaches production.

The pipeline has two primary stages. The preview stage runs pulumi preview on every pull request and posts the results as a comment, showing the diff of infrastructure changes. Reviewers can see whether the change adds a new resource, modifies a configuration, or destroys something unexpected. The deployment stage runs pulumi up after the pull request merges, applying the reviewed changes to the target environment.

Approval gates add a human checkpoint before production deployments. After a change deploys successfully to staging, the pipeline pauses and waits for an authorized team member to approve the production deployment. This prevents accidental production changes and creates an audit trail of who approved each deployment. Notifications close the loop by alerting the team when deployments succeed or fail.

Preview on Pull Requests

The preview stage checks out the pull request branch, sets up Pulumi credentials, and runs pulumi preview against the target stack. The output is captured and posted as a pull request comment, so reviewers see the planned changes alongside the code diff. If the preview fails (due to invalid configuration or provider errors), the CI check fails and blocks the merge.

Deployment on Merge

When a pull request merges to the main branch, the pipeline runs pulumi up to apply the changes. The deployment uses the same stack and configuration that was previewed, ensuring consistency between what was reviewed and what gets deployed. The pipeline can target multiple stacks sequentially (dev, then staging, then production) with approval gates between them.

Approval Gates and Notifications

Approval gates are manual checkpoints in the pipeline. Before deploying to production, the pipeline pauses and sends a notification requesting approval. An authorized team member reviews the staging deployment results and approves or rejects the production deployment. Notifications for deployment outcomes go to the team’s communication channel, so everyone stays informed about infrastructure changes.

Common Customizations

  • Add infrastructure tests: Extend the pipeline to run unit tests or integration tests against your Pulumi code before the preview stage.
  • Add drift detection: Schedule periodic pulumi preview runs outside of pull requests to detect manual changes that have drifted from the code-defined state.
  • Support multiple stacks: Configure the pipeline to deploy to dev, staging, and production stacks sequentially, with each stage gated on the success of the previous one.
  • Add cost estimation: Request a cost estimation step that calculates the monthly cost impact of infrastructure changes before they are approved.