Install — GCP-native (Cloud Run + Cloud SQL)

Deploy SOAP-2-REST by Specaria on Google Cloud as managed services: Cloud Run for the services, Cloud SQL (PostgreSQL) with IAM database authentication, Cloud…

Deploy SOAP-2-REST by Specaria on Google Cloud as managed services: Cloud Run for the services, Cloud SQL (PostgreSQL) with IAM database authentication, Cloud Storage for the raw traffic archive, and Cloud IAP at the front door. This is the lowest-touch managed path on GCP, with internal-only ingress — there is no public endpoint.

Since v1.0 the GCP-native topology is generally available; the GCP Marketplace listing uses this same topology under the hood.

What gets deployed

| 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 service runs as its own least-privilege service account. The runtime, admin-api, and worker service accounts hold the Cloud SQL IAM roles (cloudsql.client, cloudsql.instanceUser); the runtime SA additionally has Secret Manager read access for backend credential resolution.

Prerequisites

A GCP project and a region (the reference deployment uses one project per tenant in a single region).
A VPC/subnet (Cloud Run uses Direct VPC egress onto it).
A Cloud SQL PostgreSQL instance and an application database created ahead of time. IAM DB users for the service accounts must exist.
An IAP access group (or principals) authorized for roles/iap.httpsResourceAccessor on the admin backend services.
GOOGLE_APPLICATION_CREDENTIALS pointing at a service-account JSON key with cross-project deploy permission. The deploy scripts auto-activate this service account — no interactive gcloud auth login is required.
The build/deploy toolchain available (the scripts dispatch Cloud Build; no local Docker is required).

Cloud SQL is private-IP only in this topology. Operator/DBA access is over the peered VPC private-IP path; the runtime always uses IAM DB auth, not static password auth.

Deployment order

GCP-native follows the platform's standard order — see the deployment runbook for the operational detail and the rationale.

1. Build images        scripts/build-images.ps1   (Cloud Build per service)
2. Configure IAM       scripts/configure-iam.ps1  (service-account bindings)
3. Deploy services     scripts/deploy-gcloud.ps1  (Cloud Run; admin-api first)
4. Apply infrastructure scripts/deploy-terraform.ps1 (LB, IAP, supporting infra)

gcloud first, Terraform second. The deploy script ships all four Cloud Run services with the correct service-account, secret, and provenance bindings, runs the Flyway migrations on first deploy (via admin-api), and verifies each revision reaches Ready=True before moving on. Terraform then aligns the load balancer, IAP backend, and supporting infrastructure.

Single-service deploys

To deploy one service without losing the centralized secret and provenance bindings, use the -Service filter:

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

Do not fall back to a manual gcloud run deploy — that drops the operator-critical secret bindings (see Configuration reference).

Internal-only ingress

Cloud Run ingress is set to internal-and-cloud-load-balancing. The raw *.run.app URL is not the entry point; access is only through the regional internal load balancer behind Cloud IAP at your chosen hostname. Confirm after deploy that:

Each Cloud Run service is internal ingress only.
IAP is enabled on the admin UI and admin API backend services, and your IAP access group has roles/iap.httpsResourceAccessor on both.
The Google-managed IAP service identity has roles/run.invoker on s2r-admin-ui and s2r-admin-api.
No stale public allUsers invoker bindings remain on those services.

See Authentication and Network & data residency.

Verify the install

# Services are up and internal:
gcloud run services list --region=<region> --filter='metadata.name~"^s2r-"'

# Deploy provenance — confirm which code is actually running:
gcloud run revisions describe <revision> \
    --region=<region> \
    --format='value(spec.containers[0].env)' | grep S2R_DEPLOY

Then browse to your IAP-gated hostname, log in via your IdP, and confirm you land on the Dashboard. For the full post-deploy checklist see the deployment runbook.

Multi-cloud and Terraform environments

The cloud-specific plumbing (object store, secret store, compute provisioner, relay-VM gateway) is isolated behind the cloud-adapter layer, selected at boot via s2r.cloud.provider / s2r.relay-vm.provider (default gcp). See the Configuration reference.

Self-contained sample Terraform environments are provided as starting points for other 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 |

First-class AWS/Azure/Oracle native ports and VM appliance images are on the v1.1 roadmap; the GCP-native and Helm paths are the GA options today.

Next steps

All Specaria SOAP to REST docs

Loading…