Skip to main content
Reference architecture only. This page is not a production-certified deployment procedure and predates the current activation, image-pinning, secret-management, and network-isolation baseline. Use the supported on-premises guide or complete an enterprise architecture review before deployment.
The repository deployment workflows now build and deploy the complete service set, including the private, always-on casebender-connector-worker. See Integration Execution Plane for its required secrets, queue contract, and health checks.

Overview

This guide walks you through deploying CaseBender on Google Cloud Run using our pre-built Docker images.

Prerequisites

  1. Google Cloud Account
  2. Google Cloud CLI installed
  3. Docker installed

Step 1: Initial Setup

Install Google Cloud CLI

Initialize Project

Step 2: Set Up Cloud Infrastructure

Connect existing Cloud Storage buckets

CaseBender uses customer-owned GCS buckets. It does not create, empty, or delete buckets. Provision separate quarantine, records, and ephemeral buckets before this deployment. Use Cloud Run service identity or GKE Workload Identity with Application Default Credentials. Do not download a service-account key for a new production deployment.
The canonical runtime variables are STORAGE_PROVIDER=gcs, GCS_BUCKET, and optional GCS_PROJECT_ID. GOOGLE_STORAGE_BUCKET is not a CaseBender storage variable. See Enterprise Storage Overview and Storage Security Baseline.

Set Up Cloud SQL (PostgreSQL)

Set Up Memorystore (Redis)

Configure Secret Manager

CaseBender’s web, api, and worker services require one stable AUDIT_INTEGRITY_SECRET to authenticate the tamper-evident audit chain. Create it once, grant the runtime service account access, and bind the same secret to all three services. Never replace it during a normal deployment. The repository’s deploy/gcloud/setup-infrastructure.sh and deploy-gcloud.yml workflow create the secret only when it is absent and preserve existing values. For a manual deployment:

Step 3: Pull and Push Docker Images

Step 4: Deploy Services

Deploy Main Application

Apply the same AUDIT_INTEGRITY_SECRET binding to the API and worker deployments. A missing binding does not necessarily fail a basic health probe; it fails the first operation that must append a protected audit record.

Configure authenticated Pub/Sub alert pushes

Pub/Sub must attach a Google-signed OIDC token when it pushes alerts to /api/pubsub/alerts. Configure an exact audience and an allow-list that maps each push service account to an existing organization and active organization member. CaseBender uses the mapped member as the audit actor and always scopes created alerts to the mapped organization.
Set these variables on the web service:
PUBSUB_PUSH_IDENTITY_MAPPINGS must be a JSON array. Service-account emails must be unique, and every referenced organization and system user must already exist. The system user must be active and belong to the mapped organization. Requests with a missing, forged, expired, wrong-audience, or unlisted-identity token are rejected before the message body is processed.
PUBSUB_AUTH_MODE=disabled is accepted only when NODE_ENV is development or test, and it still requires exactly one organization mapping. Never set it on a deployed service.
Include AUDIT_INTEGRITY_SECRET in the protected recovery inventory. Losing or rotating it prevents verification of audit entries written with the previous key.

Deploy Workflow Processor

Deploy Connector Worker

Deploy MISP Processor

Step 5: Configure Domain and SSL

Map Custom Domain

Follow the DNS verification steps in the Google Cloud Console to complete domain mapping.

Monitoring and Maintenance

Set Up Monitoring

  1. Navigate to Cloud Monitoring in Google Cloud Console
  2. Create an uptime check for your service
  3. Set up alerts for:
    • Error rates
    • Latency
    • Instance count
    • Memory usage

View Logs

Update Application

To deploy updates:

Cost Optimization

  1. Autoscaling Configuration
  2. Resource Allocation

Troubleshooting

Common Issues

  1. Connection Issues
    • Verify Cloud SQL connection
    • Check Redis connectivity
    • Validate environment variables
  2. Performance Problems
    • Review instance metrics
    • Check resource allocation
    • Analyze request patterns
  3. Deployment Failures
    • Check build logs
    • Verify service account permissions
    • Review deployment configuration
  4. Seed did not run
    • Cloud Run web startup must call ts-node --transpile-only for prisma/seed.ts.
    • Without --transpile-only, seed typechecks console/process and exits with Seed already run or failed (non-critical) while the app still starts.
  5. Uploaded images stay on HTTP 409
    • GET /attachment/{id}?ready=1 returns 409 until the worker marks the object CLEAN and promotes it out of quarantine.
    • Cloud Run has no ClamAV sidecar. The worker must set MALWARE_SCANNER_PROVIDER=skip. Without it, logs show A supported external malware scanner must be configured and uploads never leave quarantine.

Next Steps

  • Set up CI/CD pipelines
  • Configure backup strategies
  • Implement monitoring and alerting
  • Review security best practices