Your infrastructure team is brilliant. They understand Kubernetes networking, can debug Terraform state conflicts in their sleep, and architect multi-region deployments that scale to millions of users.

So why are they spending three days rebuilding the same GitLab CI pipeline they created last month?

We see this pattern everywhere. Teams copy configs from old projects, tweak them for new requirements, and inevitably introduce gaps or miss critical production considerations.

Time to stop this cycle.

4 scripts that cover 80% of infrastructure CI/CD

We’ve open-sourced four production-ready pipeline scripts that handle the patterns every infrastructure team rebuilds. These aren’t proof-of-concept demos, they’re battle-tested configurations we use for real client projects.

 Multi-environment AWS Terraform pipeline

This script sets up proper multi-environment deployments using AWS OIDC authentication. No more long-lived credentials stored in CI variables.

What it includes:

• OpenID Connect integration with GitLab
• Separate AWS accounts for dev/prod isolation
• Terraform state management with proper locking
• Plan artifacts with human-readable change summaries
• Manual approval gates for production deployments

The pipeline validates your Terraform first, then plans changes for both environments. Production deployments require manual approval, while development can auto-deploy on merge to main branch.

Google Cloud Terraform with GitLab-managed state

The Problem: Managing Terraform state files manually is error-prone and doesn’t scale.

This script leverages GitLab’s built-in Terraform state management, removing the complexity of setting up remote backends while maintaining team collaboration features.

What it includes:

• GitLab-managed Terraform state (no S3 buckets to configure)
• Cloud Run function deployment automation
• Environment-specific variable management
• Manual triggers for apply/destroy operations

The script is particularly useful for teams deploying containerized applications to Google Cloud. It handles the infrastructure for Cloud Run functions, including IAM permissions, networking, and monitoring setup.

Helm chart validation and publishing

This script automates Helm chart validation and publishing to GitLab’s container registry. It catches configuration issues early through comprehensive linting and templating checks.

What it includes:

• Multi-stage validation (lint, template, security checks)
• Automated chart packaging and versioning
• Registry publishing with proper tagging
• Dependency validation for chart requirements
• Integration with GitLab’s package registry

The script runs validation on every merge request, ensuring chart quality before code reaches the main branch. When you’re ready to release, it handles versioning and publishing automatically.

Terraform module registry management

This script handles multiple Terraform modules in a single repository, automatically publishing them to GitLab’s module registry when you tag releases.

What it supports:

• Mono-repo module organization (AWS, GCP, Azure modules together)
• Semantic versioning with automated publishing
• Module dependency tracking and validation
• Documentation generation from code comments
• Cross-module compatibility testing

Simply push a tag like vpc/v1.2.3 and the pipeline publishes that specific module version to the registry. Other teams can then reference it in their Terraform configurations with confidence.

When using the GitLab Terraform module registry, pipelines need to be configured to have access to it, that can be done with the following little script:

echo ‘credentials “gitlab.com” {‘ > ~/.terraformrc
echo ” token = \”$GITLAB_ACCESS_TOKEN\”” >> ~/.terraformrc
echo ‘}’ >> ~/.terraformrc

Getting started: adapt, don’t copy

These scripts work best when you adapt them to your specific needs rather than copying them 1 on 1. This is how you should approach implementation:

Start Small: Pick one script that matches your most common use case. Get it working in a non-critical project first. Understand how each piece fits together before rolling it out to production workloads.

Customize Thoughtfully: The scripts include variables and configuration points for common variations. Resist the urge to modify core security patterns unless you understand the implications. Most customization should happen in the variables and environment-specific configurations.

Contribute Back: Found a bug? Implemented a useful enhancement? Contribute it back to the repository. These scripts improve when the community shares improvements and edge cases.

Ready to stop rebuilding the same pipelines?

Grab the scripts from our GitHub repository. Your infrastructure team has better things to do than reinvent CI/CD configs.