Google Cloud

Connect a Google Cloud project and run services on Cloud Run with Cloud SQL, Memorystore and Cloud Storage.

Loomplane builds a service with Cloud Build, stores its image in Artifact Registry and runs it on Cloud Run. It also provisions Cloud SQL (Postgres and MySQL), Memorystore (Redis) and Cloud Storage buckets. Everything happens in your project.

Connect a project

You connect a service account key.

In the Google Cloud console, create a service account in the project you'll deploy to.

Grant it roles that cover the permissions in the table below.

Create a JSON key for it and download it.

In Loomplane, open Integrations, choose Google Cloud, and paste the key.

Loomplane parses the key, then asks Google which permissions the account holds on the project (testIamPermissions). A key that isn't a service account key, or that Google has deleted, disabled or revoked, is refused. A key that's missing permissions makes the connection incomplete, and Loomplane lists each one.

The project ID comes from the key. Only the project and the service account's email are ever shown back to you.

Used forPermissions Loomplane checks
Buildscloudbuild.builds.create, cloudbuild.builds.get, artifactregistry.repositories.create, artifactregistry.repositories.get
Cloud Runrun.services.create, run.services.get, run.services.update, run.services.setIamPolicy, run.operations.get, iam.serviceAccounts.actAs
Secretssecretmanager.secrets.create, secretmanager.secrets.setIamPolicy, secretmanager.versions.add
Cloud SQLcloudsql.instances.create, cloudsql.instances.delete, cloudsql.instances.get, cloudsql.databases.create, cloudsql.users.create, cloudsql.users.update
Memorystoreredis.instances.create, redis.instances.delete, redis.instances.get, redis.instances.getAuthString
Cloud Storagestorage.buckets.create, storage.buckets.delete, storage.buckets.get, storage.buckets.getIamPolicy, storage.buckets.setIamPolicy, storage.objects.create, storage.objects.delete, storage.objects.list
Projectresourcemanager.projects.get

Build logs come from Cloud Logging, so the account also needs permission to read there. Without it the deployment still works and the logs show as unavailable.

Joining a Cloud Run service to AWS through a link needs Compute Network Admin (roles/compute.networkAdmin) as well. See Gateways and networking.

Use it in a manifest

version: 1
defaults:
  provider: cloud-run
  region: us-central1
services:
  api:
    source: go:services/api
    needs: [db, cache, uploads]
resources:
  db:
    kind: postgres
    provider: cloud-sql
    version: "17"
  cache:
    kind: redis
    provider: memorystore
  uploads:
    kind: object-storage
    provider: cloud-storage

Regions Loomplane lists are us-central1, us-east1, us-east4, us-west1, northamerica-northeast1, southamerica-east1, europe-west1, europe-west2, europe-west3, europe-west4, asia-east1, asia-northeast1, asia-south1, asia-southeast1 and australia-southeast1. You can name any region, but the planner warns about one it doesn't know, since a typo would otherwise only show up as a failed deployment.

How things behave

A private Cloud Run service only takes calls from the project's own services, which must send a Google ID token. Services that need a private one get its address in a variable.

Cloud SQL is reached through the Cloud SQL connector. Memorystore only has an address on the project's default network, so Cloud Run services that need it send their private traffic there with direct VPC egress. Buckets are private, and services reach them as the Cloud Run runtime account, so STORAGE_URL carries no credentials (gs://bucket).

On Google Cloud you pick the region per service or resource. Moving one starts the new copy first. Cloud SQL instances and Cloud Storage buckets carry their region in their names, so the new one never collides with the one it replaces.

Managed Cloud SQL creation and recovery are checked against controlled Google endpoints. Live Google Cloud creation, SQL persistence and restore aren't qualified yet. Database services has the details.

On this page