Skip to main content
GCP Cloud Run is the preferred GCP deployment. Keyring obtains a short-lived OAuth access token from the metadata server as the service’s assigned identity; no service-account key file is required.

​
1. Provision keys and service identity

Create two symmetric Cloud KMS CryptoKeys and one asymmetric decrypt CryptoKeyVersion using an RSA OAEP SHA-256 algorithm. Enter your values once. Every command on this page fills them in automatically. Assign a dedicated Cloud Run service account. At the narrowest practical key scope, grant: The predefined roles/cloudkms.cryptoKeyEncrypterDecrypter covers symmetric use. Grant public-key access only for the transfer key, or create a custom role with the exact permissions above. See Cloud KMS IAM guidance. Bind the runtime identity on each exact key instead of granting a project-wide KMS role: Labels make the three keys easy to inventory and audit. The exact per-key IAM bindings—not the labels—enforce access. Do not grant the Cloud Run identity KMS Admin, project Editor, or permission to change IAM policies. Cloud Run makes the assigned service identity available through metadata; Keyring requests and refreshes its short-lived token.

​
2. Store the encryption configuration

Use the complete GCP KMS configuration, with each adapter configured for metadata auth:
Store the complete configuration as compact JSON in a Secret Manager secret named keyring-encryption-config. Do not set origin_policy for the standard bundled Composio policy.

​
3. Deploy the service

Choose a telemetry delivery path before deploying. A collector sidecar is recommended; use a direct OTLP endpoint only when a sidecar is not feasible. Use the official Docker Hub image. The container reads Cloud Run’s injected PORT; set only HOST=0.0.0.0: Grant the Cloud Run service identity Secret Manager access to that secret. Google documents secret environment-variable injection.
--allow-unauthenticated disables the Google identity-token gate because Composio authenticates with a Keyring JWT, not a Google ID token. It does not make the intended path open to every source: the next step forces traffic through the load balancer and Cloud Armor allowlist.

​
4. Add the restricted HTTPS edge

Create a global external Application Load Balancer with a serverless NEG pointing to the Cloud Run service. Attach a Cloud Armor policy that:
  1. allows the four Composio backend /32 addresses;
  2. denies all other source addresses by default; and
  3. optionally rate-limits the allowed sources at a value agreed with Composio.
Keep Cloud Run ingress at internal-and-cloud-load-balancing and the default run.app URL disabled. This prevents direct internet traffic from bypassing the load balancer and Cloud Armor. Follow Google’s serverless NEG load-balancer guide and Cloud Run ingress reference.

​
5. Verify and connect

After DNS and a managed certificate are ready: Then connect the deployment to Composio. In logs, verify that Cloud KMS initialized with metadata identity. Never log metadata tokens, environment secrets, or encrypted credential data.