Farther ShoreDocs
Go to Farther Shore
Bring your own backend
Scaffold a backend service
Transport modes
Infrastructure with OpenTofu
Deploy on Railway
Deploy on Render
Deploy on AWS
Deploy on Google Cloud
Deploy the serviceBind the Cloud Run URLVerify and rotate
Metering & verification
Runtime tokens
Storing per-user data
@farthershore/backend
Add a backend
Connect a direct backend
Add a webhook consumer
@farthershore/backend exports
@farthershore/backend/express exports
@farthershore/backend/reflect exports
@farthershore/backend/runtime exports
@farthershore/backend/testing exports
@farthershore/backend/webhooks exports
backend-sdk HTTP contracts
Status
Docs/Connect your application/Deploy on Google Cloud

Deploy on Google Cloud

Run a direct HTTPS backend on Cloud Run and bind its URL to each Farther Shore environment.

Cloud Run naturally fits direct transport: it provides a stable HTTPS service URL, and @farthershore/backend supplies application-level verification for the gateway's signed requests.

Deploy the service

The application must use Node 22 or newer, listen on PORT, and mount an unsigned /healthz before fs.middleware().

Create the runtime token first:

bash
farthershore backend tokens create my-business --format json --idempotency-key <persisted-backend-tokens-create-attempt-key>

Store its one-time value in Secret Manager. Deploy the backend from its source directory or container and expose the secret to the process as FS_RUNTIME_TOKEN. Grant the Cloud Run service account access only to that secret.

bash
gcloud run deploy application-api \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --set-secrets FS_RUNTIME_TOKEN=fs-runtime-token:latest

--allow-unauthenticated makes the HTTPS network endpoint reachable by Farther Shore; it does not make your business handlers trusted-public. Strict SDK middleware rejects requests that do not carry a valid gateway signature.

Bind the Cloud Run URL

Use the HTTPS URL from the deploy output:

bash
farthershore backend create my-business \
  --name "Cloud Run API" \
  --slug api \
  --transport direct \
  --origin-url https://application-api-<hash>.run.app \
  --idempotency-key <persisted-backend-create-attempt-key> \
  --default

Previews use the production service by default. To isolate one, deploy the preview revision/service and create a matching concrete override:

bash
farthershore backend create my-business \
  --name "Cloud Run API" \
  --slug api \
  --env staging \
  --transport direct \
  --idempotency-key <persisted-backend-create-attempt-key> \
  --origin-url https://application-api-staging-<hash>.run.app

Cloud Run revisions behind one service share a public origin. If you need a hard environment boundary, use separate services and bind each environment to the corresponding URL.

Verify and rotate

bash
farthershore backend list my-business --format json

Test through the Farther Shore gateway with a subscriber key. An unsigned call straight to the Cloud Run business route should fail with missing_signature.

Secret Manager updates do not change environment variables in already-running instances. Deploy a new revision when the token changes. For a zero-downtime planned cutover, create a second matching token, deploy it, verify the new revision, move traffic, and revoke the old token. The rotate command itself revokes the predecessor immediately.

Cloud Run's request-driven lifecycle is optimized for direct transport. An embedded tunnel needs an always-running instance and stable outbound CPU; use long-running compute for tunnel mode unless you have deliberately configured those Cloud Run lifecycle constraints.

PreviousDeploy on AWSNextMetering & verification

On this page

Deploy the serviceBind the Cloud Run URLVerify and rotate