GCP

Use this page to choose and configure a Google Cloud deployment path for Corridor.

Recommended GCP Paths

Path	Use when	Primary docs
GKE	You already operate Kubernetes or need Kubernetes-native scaling and operations	Kubernetes
Cloud Run	You want Google-managed containers without managing a Kubernetes cluster	Terraform
Compute Engine VMs	You want a traditional VM-based install and direct OS control	Manual

GKE-Specific Configuration

GKE uses the shared corridor/kubernetes-ggx manifests. Start with the Kubernetes page, then apply the GCP-specific requirements below.

Required GCP Services

• Google Kubernetes Engine for the managed Kubernetes cluster.
• Cloud SQL for PostgreSQL for Corridor metadata.
• Filestore or another approved read-write-many storage provider.
• VPC with private networking for cluster, database, and storage connectivity.
• Cloud NAT when private nodes need outbound internet access.

Optional but common services:

• Cloud DNS for DNS.
• Secret Manager for sensitive configuration.
• Cloud Monitoring and Cloud Logging for observability.
• Cloud Armor for edge protection.
• Cloud CDN for static asset caching.

Permissions

The deploying identity needs permission to manage:

• GKE clusters and node pools.
• VPC networks, subnets, firewall rules, routers, and Cloud NAT.
• Service accounts and IAM bindings.
• Cloud SQL instances, databases, and users.
• Filestore instances or the selected storage provider.
• Cloud DNS records and certificate resources when managed in GCP.
• Secret Manager secrets when application secrets are stored there.

Enable the required APIs before deployment, including Kubernetes Engine, Compute Engine, Cloud SQL, and any storage, DNS, certificate, or monitoring APIs used by your environment.

Cluster Add-ons

Install or enable these before applying the Corridor overlay:

• Ingress controller appropriate for your load balancer strategy.
• cert-manager if TLS is issued from the cluster.
• NFS or Filestore CSI/provisioning components for read-write-many volumes.
• Workload Identity if pods need direct access to Google Cloud services.
• Cloud Monitoring integration or another approved observability stack.

Networking

Production GKE deployments should normally use private nodes with outbound internet through Cloud NAT. Firewall rules must allow:

• Ingress load balancer to reach corridor-app and corridor-jupyter.
• Corridor pods to reach Cloud SQL.
• Corridor pods to mount Filestore or the selected storage provider.
• Pods to pull Corridor images from the configured registry.

Cloud Run With Terraform

The corridor/terraform-google-ggx module deploys Corridor on Cloud Run. This is the main non-Kubernetes GCP container path.

The module provisions or configures:

• corridor-migration as a Cloud Run Job.
• corridor-app as a public Cloud Run service.
• corridor-worker as an internal Cloud Run service with minimum instances.
• corridor-jupyter as a public Cloud Run service.
• Cloud SQL for PostgreSQL.
• Cloud Storage for shared file-backed state.
• Direct VPC egress from Cloud Run to private services.
• External HTTPS load balancer with serverless NEGs so / routes to the app and /jupyter routes to Jupyter.

Configure the module with the project ID, image, hostname, database password, license key, and SMTP values if email is required.

terraform init
terraform plan
terraform apply

After apply, point DNS at the reserved load balancer IP and wait for the managed certificate to become active.

Compute Engine VM-Based Installs

A Compute Engine deployment follows the Manual path. The Compute Engine installation pattern is:

1. Create a Compute Engine VM, commonly n2-standard-8 or similar for all-in-one deployments.
2. Create Cloud SQL for PostgreSQL.
3. Install Python 3.11, Java 8 for Spark, Nginx, and unzip.
4. Extract the Corridor installation bundle.
5. Install the app, api, worker-api, worker-spark, and jupyter components.
6. Configure database and application settings.
7. Run database migrations.
8. Create systemd services and start the components.

Use Compute Engine when you need direct host access or your organization standardizes on VM operations. Use GKE or Cloud Run when you want managed container operations.

Security Notes

• Use service accounts with least-privilege IAM roles.
• Store secrets in Secret Manager or an approved secret store.
• Use private IP connectivity for Cloud SQL where possible.
• Enable encryption, automated backups, and monitoring.
• Restrict SSH access and prefer OS Login or IAP where available.
• Enable Cloud Logging and alerting before production rollout.