This step configures all the variables that Terraform uses to provision your infrastructure. You will:
After completing this page, your terraform.tfvars file will contain all values needed to provision infrastructure.
Terraform uses variables to customize deployments. Instead of editing the Terraform code directly, you provide values in a terraform.tfvars file. This keeps your configuration separate from the code, making updates easier.
The repository includes template files with sensible defaults. You copy a template and fill in your specific values.
Navigate to the GCP Terraform directory:
Copy the appropriate environment template:
What’s the difference? Both templates use the same default instance sizes.
The key differences are the environment name (stage vs prod), which affects
resource naming. You can adjust all values after copying.
Open terraform.tfvars in your editor. The following sections explain each variable group.
These variables name and identify your deployment:
Region selection matters. Choose a region close to your users and compliant with your data residency requirements. Once deployed, you cannot easily change regions—it requires a full redeployment.
Organization region restrictions: Some organizations only allow deployments in specific regions (via Org Policy gcp.resourceLocations). Verify your region is approved before proceeding.
If you’re creating a new VPC, configure the address spaces:
CIDR conflicts cause connectivity failures. If your corporate network uses the same IP range (e.g., 10.0.x.x), you’ll have problems connecting via VPN. Common conflict-free alternatives:
172.16.0.0/16 (172.16.x.x)192.168.0.0/16 (192.168.x.x)10.100.0.0/16 (10.100.x.x)Check with your network team before choosing.
If deploying into an existing VPC, disable VPC creation and provide the existing resource IDs:
Using an existing VPC requires coordination with your network team. You need:
Many existing VPCs have restrictive firewall rules or missing Cloud NAT configurations that will cause deployment failures.
These settings control the VMs that run your Kubernetes workloads:
Recommended sizes:
GKE also creates a fixed system pool with 2x n2-standard-4 nodes for
Kubernetes system components. This is separate from the worker pool configured
above.
GCP CPU quotas can block deployment. GCP projects have default limits on how many CPUs you can run per VM family per region.
Check your quotas: GCP Console → IAM & Admin → Quotas → Filter by “N2 CPUs” in your region
Request an increase if your limit is below: (system_nodes × 4) + (desired_worker_nodes × vCPUs per node)
Cloud SQL for PostgreSQL settings:
Generate a strong database password. Use openssl rand -base64 24 to create a secure
random password. This value is stored in Google Secret Manager by Terraform. Do not commit
it to version control.
Regional HA is enabled by default. This creates a standby replica in a different zone for automatic failover. Disable it for development/testing environments to reduce costs.
The subdomain must be the root domain, not a subdomain.
Correct: confident_subdomain = "acme.com"
Wrong: confident_subdomain = "confidentai.acme.com"
Authentication cookies are set on the subdomain and must be accessible by both frontend and backend. If you use the full subdomain, cookies won’t work correctly.
Trusted origins must include the protocol. Use
https://app.yourdomain.com not app.yourdomain.com. Missing protocol causes
authentication to fail silently.
OpenAI API key requires sufficient quota. Evaluations can consume significant tokens. Ensure your OpenAI account has appropriate rate limits and spending caps configured.
These variables control internal naming conventions for GCP resources. The defaults are suitable for most deployments:
Public GKE is only recommended for testing. Setting confident_public_gke = true makes the GKE API server and ingress accessible from the internet. Never use this in production.
Bucket names are constructed as <application_name>-<environment>-<suffix> (e.g., confidentai-stage-testcases).
ClickHouse serves as the analytics database, deployed via the ClickHouse Operator on GKE:
Do not change confident_clickhouse_user from default. The ClickHouse Operator expects this
username. Changing it will cause connectivity failures.
A GCS bucket is created for ClickHouse backups:
Backup lifecycle policy: Terraform configures a lifecycle policy that automatically deletes ClickHouse backup objects older than 30 days and snapshots older than 7 days.
These credentials allow your GKE cluster to pull Confident AI container images from AWS ECR:
These values are provided by your Confident AI representative. Don’t modify them unless instructed.
Terraform tracks what resources it created in a “state file.” This should be stored remotely so multiple team members can collaborate and state isn’t lost.
Edit provider.tf to configure your GCS backend:
If the bucket doesn’t exist, create it:
Your organization may have existing Terraform state infrastructure. Many companies have:
Check with your infrastructure team before creating a new bucket.
Never delete or modify the state file manually. Terraform state tracks the mapping between your configuration and real GCP resources. Corrupting it can cause Terraform to lose track of resources, leading to orphaned infrastructure or accidental deletions.
Before proceeding, verify these security considerations:
terraform.tfvars is in .gitignore (never commit secrets)Once configuration is complete, proceed to Provisioning to create the GCP infrastructure.