Terraform blueprints
terraform-presponsieve-self-hosted-blueprints provisions the surrounding infrastructure and then installs this chart.
Use it when you are starting from an empty cloud account. If your platform team already owns the cluster and network, the existing_cluster example is Helm-only and is the more common enterprise path.
Requirements
Terraform 1.11 or later. The modules use write-only variables introduced in that release.
Examples
| Example | Builds |
|---|---|
existing_cluster | Nothing. Helm release only |
gcp_all_inclusive | VPC, GKE, Cloud SQL with IAM auth, GCS, IAP, release |
aws_all_inclusive | VPC, EKS, RDS, S3, ALB, release |
azure_all_inclusive | VNet, AKS, Flexible Server, Key Vault, App Gateway, release |
Running one
git clone https://github.com/m-a-m-a-ai/terraform-presponsieve-self-hosted-blueprints
cd terraform-presponsieve-self-hosted-blueprints/examples/gcp_all_inclusive
cp provider.example.tf provider.tf
# edit the locals block at the top of main.tf
terraform init && terraform apply
Each example has one locals block holding everything you need to change.
Copy them, do not submodule them
These are blueprints, not a dependency. Copy the example into your own repository and own it from there. A vendored copy you control is easier to reason about than a pinned module reference that changes underneath you.
The two-stage apply
Every cloud has the same wrinkle. The Kubernetes and Helm providers are configured from cluster module outputs that do not exist during the first plan. If you hit Invalid provider configuration on a clean run:
terraform apply -target=module.vpc -target=module.gke
terraform apply
This is a Terraform limitation around provider configuration depending on resource attributes, not something the modules can work around.
Pin your versions
chart_version and image_tag both default to null, which resolves to whatever is newest at apply time. Pin both. Moving those strings is the upgrade, and it shows up in review and in terraform plan.
Destroy guards
Databases carry prevent_destroy and provider-level deletion protection. terraform destroy fails until you remove both deliberately. That is intentional: the database holds behavioral profiles, and losing it to a mistyped -target is not recoverable.