Terraform is a mature Infrastructure as Code (IaC) tool that enables users to define, provision, and manage cloud infrastructure using a declarative configuration language. The system operates as a command-line interface with a plugin-based architecture, allowing extensibility through providers and provisioners for various cloud platforms and services. Its core functionality includes loading configuration, managing state, generating execution plans via dependency graph resolution, and applying changes to infrastructure. The architecture is modular, separating concerns into distinct packages for CLI commands, configuration loading, state management, plugin handling, and the core execution engine. Key entry points are found in the `main` package and the `internal/command` directory, which implements subcommands like `apply`, `plan`, `state`, and `workspace`. Data flows involve parsing HCL configuration into an internal representation, comparing it with the current state to generate a plan, and executing that plan via provider plugins to update infrastructure and refresh the state. Terraform demonstrates strong engineering practices with a comprehensive test suite, continuous integration, and a well-defined plugin system. While the codebase is large and exhibits some complexity (such as duplication between plugin versions and backend helpers), it remains actively maintained with recent commits and ongoing development. The tool's design emphasizes reusability, as evidenced by components like the generic collections package and the diagnostic system, which could be extracted for use in other projects.
Terragrunt is a mature, production-grade Infrastructure as Code orchestration CLI tool that wraps OpenTofu and Terraform. Its core function is to manage the lifecycle of IaC modules across environments: it parses HCL configuration (`terragrunt.hcl`, stacks), discovers units and stacks in a file tree, resolves inter-module dependencies, executes OpenTofu/Terraform commands with automatic remote state backend management (S3, GCS, Azure), and caches provider downloads and module sources via a content-addressable store (CAS). The architecture is a monolith with a rich CLI surface (over 20 subcommands including `run`, `catalog`, `browse`, `scaffold`, `find`, `list`, `render`, `hcl fmt`, `dag graph`, etc.) and a custom implementation of the CLI framework (`internal/clihelper`). It features a Bubbletea-based TUI for catalog browsing and an extensible filter engine for selecting units by path, attributes, or git changes. The codebase is heavily test-covered (unit, integration, fuzz) and actively maintained by Gruntwork. Key reusable patterns include virtual abstractions for filesystem, execution, and HTTP; a generic concurrent cache; a strict controls system for deprecation gating; and a content-addressable git store for deduplicating source downloads.
This repository is a comprehensive Terraform module for provisioning and managing AWS EKS (Elastic Kubernetes Service) clusters. It provides a modular, production-grade interface to create clusters with all supporting resources: IAM roles, security groups, VPC networking, encryption (KMS), logging, addons, identity providers (OIDC/IRSA), and access entries. The root module orchestrates multiple sub-modules for compute resources including EKS managed node groups, self-managed node groups (autoscaling groups), Fargate profiles, Karpenter integration, hybrid node roles, and EKS capabilities (ACK, ArgoCD, KRO). The architecture follows standard Terraform module patterns with extensive use of `for_each`, `dynamic` blocks, and conditional creation. The codebase demonstrates high craftsmanship through its modular design, comprehensive test infrastructure, and detailed upgrade guides that document breaking changes across major versions (v17 through v21). It includes an internal user data rendering sub-module that supports AL2, AL2023, Bottlerocket, and Windows AMIs, with both cloud-init and custom template support.
This repository is the official HashiCorp Terraform provider for Microsoft Azure (azurerm). It enables declarative management of Azure infrastructure—resources, data sources, and services—through Terraform configurations. The provider is written in Go and uses the Terraform Plugin SDK and Plugin Framework to implement CRUD operations, state migrations, custom polling for asynchronous operations, and extensive input validation. Its architecture follows a modular service registration pattern: each Azure service (e.g., compute, network, storage, appservice) is self-contained within `internal/services/<service>/`, with its own client construction, resource definitions, validation functions, and acceptance tests. Key entry points include `main.go` for provider initialization, `internal/provider/provider.go` for resource registration, and `internal/services/*/registration.go` for service wiring. Data flows from Terraform configuration through the provider's SDK layer to Azure REST APIs via the `go-azure-sdk` library. The codebase is large (43k+ files) but well-organized, with extensive test coverage and tooling for documentation linting, schema API compatibility checks, and PR guide suggestions. It is actively maintained with frequent releases and a large community (5k+ stars, 5k+ forks).
This repository provides a comprehensive suite of GitHub Actions for automating Terraform and OpenTofu workflows in CI/CD pipelines. Each action (e.g., terraform-apply, terraform-plan, terraform-validate) is implemented as a standalone reusable workflow with standardized inputs, outputs, and Docker-based execution environments. The architecture features a common shell library (actions.sh) that handles tool installation, backend initialization, and shared utilities, while individual actions focus on specific operations like plan generation, state management, or pull request commenting. Key capabilities include version detection from multiple sources, backend fingerprinting for state identification, automated PR commenting with approval workflows, and support for both Terraform and OpenTofu. The project emphasizes reliability through extensive testing across versions and backends, with clear separation of concerns between action definitions, implementation logic, and documentation generation.
This repository is a Visual Studio Code extension that provides comprehensive language support for Terraform, including syntax highlighting, completions, diagnostics, and integration with the Terraform Language Server. It also offers deep integration with HCP Terraform for managing workspaces, runs, and state, along with features like module and provider exploration, telemetry collection, and bug report generation. The extension follows a modular architecture with separate modules for features, commands, and providers, and uses patterns such as dependency injection and static feature classes to maintain separation of concerns. Key entry points include the main activation function in src/extension.ts and various commands in src/commands/. The extension relies on external dependencies such as vscode-languageclient, axios, and the terraform-ls binary.
Atlantis is a self-hosted Go application that automates Terraform and OpenTofu workflows triggered by pull request events. It listens for webhooks from GitHub, GitLab, Bitbucket Cloud/Server, Azure DevOps, and Gitea, then executes Terraform commands (plan, apply, import, state rm, version) and reports results via PR comments and commit statuses. The system enforces approval, mergeability, and policy requirements, supports drift detection and remediation, and provides a web UI for lock management and streaming logs. The architecture is a monolithic server with modular components: HTTP controllers for webhook handling, command runners for orchestrating workflows, step runners for individual Terraform operations, VCS client abstractions for multi-provider support, and pluggable persistence (BoltDB embedded, optional Redis, S3 for plan storage). Configuration is layered via server-side YAML, repo-level atlantis.yaml, and CLI flags. Key entry points include main.go (CLI), cmd/server.go (server command), server/controllers/events/events_controller.go (webhook dispatcher), and server/events/command_runner.go (command orchestration). External dependencies include Terraform/OpenTofu binaries, Conftest for policy checks, VCS APIs, and optional Redis/S3. The codebase demonstrates strong engineering practices with extensive unit/integration/e2e tests, instrumentation for metrics, structured logging, and security-conscious design (webhook signature validation, path traversal prevention, shell injection mitigation). While the project is actively maintained, technical drift is medium due to large dependency surface, mock generation sprawl, and complex VCS integration parity.
terraform-docs is a CLI tool written in Go that automatically generates documentation from Terraform modules. It parses Terraform configuration files (variables, outputs, providers, resources, modules, requirements) using HashiCorp's terraform-config-inspect library, then renders the extracted metadata into multiple output formats including Markdown (table and document), AsciiDoc (table and document), JSON, YAML, TOML, XML, a colorized 'pretty' format, and tfvars (HCL and JSON). The tool supports extensive configuration via a YAML file or CLI flags, allowing users to control which sections are shown, sorting order, output file injection or replacement, recursive submodule processing, and custom headers/footers. It also features a plugin system based on go-plugin for extending formatters, and integrates with CI/CD pipelines, pre-commit hooks, and GitHub Actions. The architecture follows a clean separation of concerns: a cobra-based CLI dispatches to format-specific packages, which use Go templates for rendering. The codebase is well-tested with golden file tests covering edge cases like escape characters, code blocks, and multiline descriptions.
Azure Export for Terraform (aztfexport) is a CLI tool that brings existing Azure resources under Terraform management. It discovers Azure resources via Azure Resource Graph or direct resource IDs, identifies the corresponding Terraform resource types using the `aztft` library, imports them into Terraform state, and generates HCL configuration files. The tool supports multiple modes: single/multiple resource IDs, resource groups, ARG queries, and mapping files. It offers both interactive (TUI with bubbletea) and non-interactive (batch) modes, with configurable parallelism, backend types, and provider versions (azurerm or azapi). The architecture is modular, with clear separation between resource discovery (internal/resourceset), Terraform interaction (internal/meta), configuration generation (via tfadd), and UI layers. The codebase is well-tested with unit and end-to-end tests, and follows professional Go conventions.
OpenStatus is a production-grade, self-hostable uptime monitoring, incident management, and status page platform. In production, it runs multi-region synthetic checks (HTTP, TCP, DNS, ICMP, gRPC) from Go-based checker and private-location services, streams check results into Tinybird for time-series analytics, persists workspace state (monitors, pages, incidents, API keys, OAuth clients) in SQLite via Drizzle ORM, and renders results through a Next.js dashboard and a public, i18n-enabled status page app with custom-domain proxy support, password/email/IP access gating, themes, and RSS/JSON/markdown feeds. A Hono-based API server exposes three API surfaces - a frozen legacy REST v1 (OpenAPI), tRPC, and ConnectRPC - plus an MCP server for AI agents and a Slack bot that can resolve incidents conversationally. The architecture is a deliberately polyglot monorepo: 8+ apps (dashboard, status-page, web marketing, Hono server, Go checker, Go private-location, Deno workflows, Go ssh-server) and 20+ internal packages. Business logic is centralized in packages/services behind a consistent ServiceContext + withTransaction + requireScope + emitAudit mutation pattern, then adapted to tRPC, ConnectRPC, and REST entry points. Multi-tenant workspaces include plan-based limits, API keys with scopes, a full OAuth 2.0 authorization server (PKCE), WorkOS SSO, Stripe billing, and append-only audit logging. Background Deno workflows handle cron maintenance: outbox draining, status drift repair, OAuth client pruning, and uptime freezing. Craftsmanship is strong: the service-layer pattern is applied uniformly, there is an explicit ServiceError hierarchy mapped to both tRPC and gRPC errors, external services (Upstash, Tinybird, Slack, analytics) have thorough test doubles, and several packages are genuinely standalone and reusable (CDN header analysis, assertion engine, schema-driven data-table filters, Effect-based status fetchers). Caveats are real but not disqualifying: the REST v1 API is explicitly frozen and bypasses the service layer, identical composition/chart utilities are duplicated across dashboard and status-page apps, a deprecated screenshot-service remains in-tree, the Go/TypeScript protobuf boundary requires manual synchronization, and an in-progress auth migration has left Clerk-era references alongside NextAuth. Overall this is a well-architected, actively maintained codebase that does what it claims.
drawio-skill is a comprehensive toolkit for generating, manipulating, validating, and publishing draw.io architecture diagrams from natural language, codebases, infrastructure-as-code, API specifications, and other structured sources. It provides a unified CLI (`diagramctl.py`) and an optional MCP server (`diagramctl_mcp.py`) that expose workflows for building, syncing, viewing, testing, reviewing, querying, what-if analysis, story generation, and publishing diagrams. The system uses a formal Diagram Intermediate Representation (IR) to separate semantic meaning from geometry, enabling incremental reconciliation, multi-view projection, architecture contract enforcement, and accessible HTML story output. It includes 15+ importers for languages (Python, JS, Go, Rust), IaC (Terraform, Kubernetes, Docker Compose), schemas (SQL, OpenAPI, AsyncAPI, Protobuf, GraphQL), and live infrastructure (Docker, Terraform state). The project is packaged as an AI agent skill compatible with Claude Code, Cursor, Copilot, and other Agent Skills hosts, and ships with GitHub Actions for CI integration. While primarily an application, it also bundles curated icon indices and style presets that could be considered data assets.
Kapitan is a configuration-as-code CLI tool that renders infrastructure manifests (Kubernetes, Terraform, Docker, etc.) from a hierarchical YAML inventory and pluggable template engines (Jsonnet, Jinja2, Kadet, Helm, Kustomize, CUE). It manages secrets via references (GPG, cloud KMS, Vault, base64), fetches remote dependencies (Git, HTTP, OCI, Helm charts), and supports multiple inventory backends (Reclass, OmegaConf). The compilation pipeline is inventory-driven: targets define classes and parameters, which are deep-merged and interpolated, then passed to input-type compilers that produce deterministic output files. The architecture is modular—separate packages for inputs, inventory backends, secrets/references, and dependency management—all orchestrated by the `kapitan compile` CLI command. It is not a data research project; it is a production-grade infrastructure tool with a large test suite, CI/CD, and documented extension points.
decK is a CLI tool for declarative configuration management of Kong API Gateway and Konnect SaaS. It enables users to manage Kong entities (services, routes, plugins, consumers, certificates, etc.) via YAML/JSON state files, supporting sync, diff, dump, apply, reset, and validate operations. The architecture is a single binary with multiple subcommands organized under `gateway`, `file`, `ai`, and `konnect` namespaces, built on top of Kong's go-database-reconciler library for state reconciliation. Key entry points include `main.go` (signal handling), `cmd/root.go` (Cobra CLI), and command handlers in `cmd/gateway_*.go`, `cmd/file_*.go`, and `cmd/ai_*.go`. Data flows involve reading declarative state files, fetching current state from Kong Admin API or Konnect, computing diffs, and applying CRUD operations. External dependencies include Kong Gateway (>=1.x), Kong Enterprise, Konnect, and various Go libraries for Kubernetes, Terraform, and AI Gateway integrations. The repository also includes converters for generating Kubernetes Ingress Controller manifests (`kong2kic`), Terraform resources (`kong2tf`), and version migration rulesets (`convert/`).
Checkov is a static analysis tool for Infrastructure as Code (IaC) security and compliance. It scans Terraform, CloudFormation, Kubernetes, Helm, Dockerfile, ARM, Bicep, and many other IaC frameworks against thousands of built-in policies covering AWS, Azure, GCP, and other cloud providers. The tool operates as a CLI application and can also be used as a Python library or integrated into CI/CD pipelines. Its architecture is modular, with separate runners per framework, a graph-based analysis engine for cross-resource checks, and a pluggable check registry system. Checkov also includes software composition analysis (SCA) for container images and packages, secrets detection, and integration with the Bridgecrew/Prisma Cloud platform for policy management and reporting.
This repository is a comprehensive collection of over 1200 standalone Bash scripts for DevOps automation, cloud infrastructure management, CI/CD pipeline orchestration, and system administration. It is not a single application but a modular toolbox designed to be used interactively or integrated into CI workflows. The architecture is decentralized: each script is self-contained, sourcing shared libraries from the `lib/` directory for common functions like error handling, API authentication, and OS detection. Key entry points include the top-level `Makefile` for bootstrapping, `lib/utils.sh` as the core utility library, and numerous API wrapper scripts (e.g., `github_api.sh`, `aws_foreach_profile.sh`) that provide consistent patterns for interacting with external services. The primary data flows involve querying cloud provider APIs (AWS, GCP, Cloudflare), managing CI/CD platforms (Jenkins, BuildKite, GitHub Actions), manipulating Git repositories, and performing system tasks like disk benchmarking or SSL certificate verification. External dependencies are extensive but well-managed: the scripts assume the presence of `curl`, `jq`, and platform-specific CLIs (`aws`, `gcloud`, `kubectl`, `gh`), with many install scripts provided to bootstrap these tools. The codebase demonstrates high craftsmanship with consistent error handling (`set -euo pipefail`), input validation, and cross-platform compatibility guards. While some scripts are tailored to the author's personal environment, the core patterns and libraries are designed for reuse across projects.
tfenv is a command-line Terraform version manager written in Bash, modelled after rbenv. It provides a `terraform` shim that intercepts invocations and selects the appropriate Terraform binary based on a `.terraform-version` file, the `TFENV_TERRAFORM_VERSION` environment variable, or the default version file under `TFENV_CONFIG_DIR`. The repository implements full version lifecycle operations: install (download, verify SHA256 and optional PGP signatures, unzip), switch (`use`), uninstall (including multiple versions), list local and remote versions, pin current version, and a `min-required`/`latest-allowed` resolver that reads `required_version` constraints from `.tf` files. Architecturally it follows the rbenv pattern: a dispatcher (`bin/tfenv`), a shim (`bin/terraform`), shared libraries in `lib/` (logging, version-file discovery, version-name resolution, execution), and standalone subcommand scripts in `libexec/` that each include boilerplate to resolve `TFENV_ROOT`. The code deliberately avoids shellcheck and additional dependencies, maintaining portability across Linux, macOS, and Windows (git-bash). An extensive integration test suite downloads real Terraform binaries, and CI covers a broad OS matrix plus Docker validation. The codebase demonstrates solid engineering practice for a Bash project: clean separation of concerns, a capable logging library (`lib/bashlog.sh`) that supports file, JSON, syslog and coloured console output; careful handling of cross-platform differences (BSD vs GNU grep, CRLF line endings, ARM architecture detection); and a concurrency-safe install lock using atomic `mkdir`. Notable weaknesses are intentional boilerplate duplication across `libexec/` scripts, a test runner that historically exits 0 on failure (documented as a known bug being fixed), and regex-based HCL constraint parsing that is functional but fragile. A proposed ADR outlines a future Go edition, but the Bash implementation remains canonical.
Nitric is a multi-cloud framework that enables developers to define cloud infrastructure and application logic in code, then deploy to AWS, Azure, or GCP. The framework provides infrastructure-as-code capabilities for cloud resources (APIs, storage, queues, topics, secrets, etc.) with runtime implementations for handling cloud service events. It features a modular architecture with core framework logic, cloud provider implementations, and a documentation site. The system uses a plugin-based worker system for handling cloud events and provides consistent abstractions across cloud providers through well-defined interfaces.
Khue's Homelab is a GitOps-driven infrastructure-as-code framework that automates a complete self-hosted Kubernetes platform from bare metal to user-facing applications. The codebase is organized into five layers: metal (Ansible roles that PXE-boot Fedora Server, bootstrap a k3s cluster with kube-vip HA, and install Cilium for networking/load balancing), system (bootstrap Helm charts for ArgoCD, cert-manager, ingress-nginx, Rook Ceph, and monitoring), platform (Gitea, Woodpecker CI, Grafana, Kanidm identity, Dex SSO, zot container registry), apps (Jellyfin + the *arr stack, Matrix, Paperless, Ollama, and more), and external (Terraform-managed Cloudflare DNS, tunnel, and ntfy alerting). ArgoCD ApplicationSets watch the git repository and deploy every Helm chart, making the repo itself the source of truth; a single top-level `make` drives the entire pipeline. The project demonstrates strong IaC craftsmanship: idempotent Ansible roles with checksum-verified downloads and run_once state handling (k3s token genesis, kubeconfig extraction), an ephemeral PXE server with per-MAC kickstart files and DHCP-proxy mode, declarative random secret generation via a small Go tool combined with the External Secrets Operator for cross-namespace secret sync, and a Terraform module that creates least-privilege Cloudflare API tokens injected directly into the cluster. It also includes a Nix dev shell for reproducible tooling, pre-commit hooks, Woodpecker CI that renders Helm diffs on pull requests, and Terratest-based smoke/integration/version tests. The author explicitly labels the project ALPHA and recommends forking for personal use. It is best treated as a reference architecture and a collection of reusable provisioning patterns rather than a turnkey product; some portions (scripts/hacks, take-screenshots, the gitea config job) are acknowledged work-in-progress, and a few pinned versions lag the ecosystem (Go 1.19 in-cluster compile jobs, k3s 1.30, several stale container image tags).
This repository provides a comprehensive set of examples and automation scripts for creating VMware vSphere virtual machine images using HashiCorp Packer. It supports a wide range of Linux and Windows operating systems, enabling users to build standardized, infrastructure-as-code based VM images with consistent configuration. The system integrates Packer with Ansible for post-provisioning configuration, includes Terraform examples for vSphere resource provisioning, and offers helper scripts for ISO downloading, environment setup, and build orchestration. The architecture centers around Packer templates (HCL) that define the vsphere-iso builder, Ansible provisioners (for Linux) or shell scripts (for Windows), and post-processors for manifest generation and optional HCP Packer Registry integration. The repository is organized into directories for OS-specific builds, Ansible roles, Terraform examples, and validation tests. Key entry points include the interactive build.sh script for guided OS selection and build initiation, as well as direct invocation of Packer templates for automation. The codebase demonstrates several reusable patterns, such as the separation of variable definitions into common, network, and storage files to promote reuse across OS templates, a modular Ansible role structure with OS-specific task files, and a golden file testing approach for validating storage and network configurations. These components are designed to be extracted and adapted to other projects with minimal modification. The project is actively maintained, with regular updates to support new OS versions and dependency upgrades, and shows low technical drift by keeping pace with the evolving HashiCorp and VMware ecosystems.
This repository is a code generation and CI orchestration system for Terraform providers targeting Google Cloud Platform. The core functionality reads YAML definitions of GCP products and resources (hundreds of YAML files under mmv1/products/) and uses Go templates (mmv1/templates/terraform/) to generate the full source code for the google and google-beta Terraform providers, including resources, data sources, IAM policies, tests, and documentation. It also generates code for the terraform-google-conversion (TGC) library used for Cloud Asset Inventory conversion. The CI component (magician) manages pull request workflows: downstream generation, VCR-based acceptance testing, automatic reviewer assignment, scheduled PR reminders, and test failure triage. Additional tools handle breaking change detection, missing test/doc/identity analysis, issue labeling, and template validation. The architecture is a multi-module Go CLI (mmv1 generator + magician + several tools) with extensive use of Go templates, YAML configurations, and Bazel build system. While primarily an application, it includes data processing elements in the diff-processor and test reader that perform schema comparison and coverage analysis, giving it a hybrid flavor dominated by code generation and CI.