GCP-Native Installation with Cloud Run and Cloud SQL

Overview

This document describes the process for deploying the SOAP-2-REST platform on Google Cloud Platform (GCP) using a native, managed services topology. This approach is considered the lowest-touch deployment path on GCP and has been generally available since v1.0.

The architecture uses Cloud Run to host the application services, Cloud SQL for PostgreSQL for the database, Cloud Storage for the raw traffic archive, and Cloud IAP to secure access. All ingress is configured to be internal-only, meaning the platform has no public-facing endpoint. The GCP Marketplace offering for the platform is based on this same topology.

Prerequisites

Before beginning the deployment, ensure the following resources and permissions are in place:

• A GCP project and a designated region. The reference deployment model uses one project per tenant in a single region.
• A VPC network and subnet. The deployment uses Cloud Run's Direct VPC egress feature to connect to this VPC.
• A Cloud SQL for PostgreSQL instance with a dedicated application database created. IAM database users must be configured for the application's service accounts.
• An IAP access group or a set of principals with the roles/iap.httpsResourceAccessor role granted on the admin backend services.
• The GOOGLE_APPLICATION_CREDENTIALS environment variable must point to a service account JSON key file. This service account needs permissions to deploy resources across projects. The deployment scripts automatically activate this service account, so an interactive gcloud auth login is not required.
• Access to the build and deploy toolchain. The deployment scripts use Cloud Build, so a local Docker installation is not necessary.

Note: In this topology, the Cloud SQL instance is configured for private-IP only. Database access for operators and DBAs must be through the peered VPC's private IP path. The application runtime exclusively uses IAM database authentication, not static passwords.

Architecture

The GCP-native deployment provisions the following resources:

Component	GCP Resource
admin-api, admin-ui, runtime, worker	Cloud Run services (s2r-admin-api, s2r-admin-ui, s2r-runtime, s2r-worker)
Database	Cloud SQL for PostgreSQL, reached over private connectivity with IAM DB auth
Raw traffic archive	Cloud Storage bucket
Front-door identity	Cloud IAP on the admin UI / admin API backend services
Edge	Regional internal HTTP(S) load balancer
Egress to backends	Cloud Run Direct VPC egress (no Serverless VPC connector required)

Each application service (runtime, admin-api, worker, admin-ui) runs under its own least-privilege GCP service account. The service accounts for runtime, admin-api, and worker are granted the cloudsql.client and cloudsql.instanceUser IAM roles to enable IAM database authentication. The runtime service account also has read access to Secret Manager for resolving backend credentials.

Internal-Only Ingress

Access to the platform is strictly controlled. Cloud Run ingress is configured for internal-and-cloud-load-balancing. The primary entry point is a regional internal load balancer at a chosen hostname, which is protected by Cloud IAP. The default *.run.app URLs for the Cloud Run services are not intended for direct access.

Deployment Process

The deployment follows a specific order, with Cloud Run services deployed first using gcloud scripts, followed by the supporting infrastructure using Terraform.

Deployment Order:

1. Build Images: scripts/build-images.ps1 (dispatches a Cloud Build job for each service)
2. Configure IAM: scripts/configure-iam.ps1 (binds service account roles)
3. Deploy Services: scripts/deploy-gcloud.ps1 (deploys all Cloud Run services, starting with admin-api)
4. Apply Infrastructure: scripts/deploy-terraform.ps1 (provisions the load balancer, IAP, and other resources)

The deploy-gcloud.ps1 script handles the deployment of all four Cloud Run services, ensuring they are configured with the correct service accounts, secret bindings, and deployment provenance. On the first deployment of the admin-api, it also runs the Flyway database migrations. The script waits for each service revision to report Ready=True before proceeding. After the services are running, the Terraform script aligns the load balancer and IAP configurations.

Single-Service Deployments

To redeploy a single service, use the -Service parameter with the deployment script. This ensures that critical configuration bindings are preserved.

Example:

./scripts/deploy-gcloud.ps1 -Service admin-api

Do not use a manual gcloud run deploy command for single-service updates. This can cause the service to lose its operator-critical secret bindings.

Verifying the Installation

After deployment, confirm the system is running correctly and securely.

1. Check Service Status: Verify that all s2r-* services are deployed and configured for internal ingress only.

   gcloud run services list --region=<region> --filter='metadata.name~"^s2r-"'
   

2. Check Deployment Provenance: Inspect the running revision to confirm which version of the code is deployed.

   gcloud run revisions describe <revision> \
       --region=<region> \
       --format='value(spec.containers[0].env)' | grep S2R_DEPLOY
   

3. Verify Ingress and IAP:

   • Confirm each Cloud Run service's ingress is set to internal only.
   • Ensure IAP is enabled on the s2r-admin-ui and s2r-admin-api backend services.
   • Verify your IAP access group has the roles/iap.httpsResourceAccessor role for both admin services.
   • Check that the Google-managed IAP service identity has the roles/run.invoker role on s2r-admin-ui and s2r-admin-api.
   • Ensure no stale public allUsers invoker bindings exist on these services.

4. Access the UI: Browse to the IAP-gated hostname for the admin UI, log in with your identity provider, and confirm that the Dashboard loads successfully.

For a complete post-deployment checklist, see the deployment runbook.

Multi-Cloud and Terraform Environments

The platform isolates cloud-specific components (e.g., object storage, secret management) behind a cloud-adapter layer. The active provider is selected at boot time via the s2r.cloud.provider and s2r.relay-vm.provider configuration settings, which default to gcp.

The product provides self-contained Terraform environments as starting points for different deployment topologies.

Directory	Cloud	Purpose
customer-mot-gcp	GCP	Reference GCP-native env (Cloud Run + Cloud SQL + GCS + IAP)
customer-test-aws	AWS	Sample AWS-host env
customer-test-azure	Azure	Sample Azure-host env
customer-vmware-relay-only	vSphere	F5 relay VM on vSphere

While first-class support for other cloud providers is on the roadmap for v1.1, the GCP-native and Helm installations are the currently supported GA options.

See Also

• Configuration Reference
• Deployment Runbook
• Daily Operations
• Authentication
• Network & Data Residency

---

All SOAP-to-REST docs