apointoo.
Request access
HIPAA

Cloud Run for Next.js: A Bounded Healthcare Migration

cmsapointoo··8 min read

Short answer: A bounded Cloud Run migration should move the current Next.js runtime first, prove domains, jobs, secrets, logs, identity, and scale behavior, then evaluate database replacement as a separate gate. As of 2026-08-15, Google Cloud publishes Cloud Run pricing and covered-product guidance. A successful container deployment does not prove tenant authorization, regional handling, backup, or a protected data design.

GCP service fit and regional boundary

Cloud Run is a plausible first migration target when the application can be containerized without changing the data contract. Google Cloud pricing describes request and resource charges, and its HIPAA page describes covered products and shared responsibility. Those sources support a bounded platform evaluation. They do not approve the application, database, jobs, region, or tenant model.

Begin with a deployment inventory: Next.js version, runtime assumptions, environment variables, build output, image, ingress, custom domain, scheduled jobs, queues, database calls, object storage, logs, monitoring, secrets, and backup. Mark each item as moved, retained, replaced, or unknown. A compute lift that silently keeps an unreviewed database bridge is not a complete protected-data migration.

Choose one non-production region and synthetic dataset. Prove container startup, scale behavior, health, request timeout, authentication, secret access, logs, deployment rollback, and custom domain. Keep the database contract stable while measuring runtime behavior. Only after that should the team compare Firestore, Cloud SQL PostgreSQL, or another store.

Phase Scope Exit evidence
Compute lift Container, ingress, runtime, secrets, logs Route and rollback test
Jobs Authenticated scheduler or queue triggers Least-privilege job test
Data proof One vertical slice in candidate databases Query, transaction, and tenant tests
Regional proof Tenant home zone and resource locations Location and denial evidence

Read Cloud Run regions and immutable home zones, then compare Firestore database proof and Cloud SQL PostgreSQL RLS.

Request, data, key, and identity path

The migration is complete only when the request path remains bounded. Trace client, domain, load balancer or mapping, Cloud Run service, identity, tenant membership, database, key, logs, queues, backups, and support. Do not allow browser values to choose tenant or region. Server-side membership must resolve the destination and access scope.

Inventory environment variables without printing values. Identify secret names, service identity, rotation, failure behavior, and deployment permissions. A production service should not inherit broad development secrets. A build identity should not automatically read application data. Store configuration and secret access evidence separately.

Keep the data contract minimum necessary. An approved generic conversion can include generic event name, time, currency, value, and an opaque internal reference only if tenant-specific counsel approval permits it. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising systems.

custom domain
  -> approved ingress
  -> Cloud Run service
  -> authenticated membership check
  -> retained database contract
  -> regional logs and backups

Prove that scheduled jobs and administrative endpoints use a separate identity. If the migration keeps a temporary data bridge, document the exact service, tier, region, contract, retention, and deletion gate. Do not carry protected data through an unverified bridge merely to make the container demo pass.

Jobs, audit, backup, and failure handling

Next.js deployment proof must include non-request paths. Replace unauthenticated cron calls with authenticated jobs, least-privilege identities, retries, and audit evidence. Test cold start, timeout, duplicate trigger, failed secret read, database outage, queue retry, and rollback. Inspect logs for request bodies, query data, stack traces, and secret references.

Cloud Run logs and monitoring should contain operational facts, not full booking records. Record principal, tenant, route, result, timestamp, and reason code where allowed. Review admin access, deployment changes, key use, export, restore, and support. Keep required documentation retention separate from indefinite application retention.

Backups should be tested before database cutover. Restore a synthetic slice, reapply membership and tenant controls, verify region and key, and delete the test copy. A container deployment does not transfer backup ownership from the old system. Add a migration checklist for old snapshots and bridge deletion.

Use a rollback plan that does not reintroduce an unapproved data path. Dual reads, shadow writes, or temporary queues need explicit retention and deletion. The safest first gate may be compute only with synthetic data, followed by a separate database proof. Do not call partial traffic a production migration.

Cost and proof gate

Cloud Run pricing is only one line in a migration estimate. Include requests, vCPU and memory, ingress, load balancer or domain method, logs, storage, keys, secrets, scheduler, queues, database, backups, traffic, support, and engineering verification. Label all figures as estimates with region, workload, and date.

Separate recurring cloud cost from migration work. The compute lift may be modest, while database replacement, query conversion, data backfill, regional controls, and cutover consume most engineering time. A low Cloud Run bill does not prove the migration is cheap or safe.

  • Run a container-only proof with synthetic data.
  • Prove domains, jobs, secrets, logs, identity, rollback, and alerts.
  • Keep database replacement behind a separate decision gate.
  • Measure resource usage under normal and burst traffic.
  • Recalculate current pricing before a commercial promise.

Bounded migration proof

Use a vertical slice and an explicit stop condition.

  1. Build and deploy the current application to a non-production Cloud Run service.
  2. Run a synthetic request through the intended domain and identity.
  3. Trigger every scheduled job with authentication and a least-privilege identity.
  4. Inspect logs, secrets, keys, queues, and backup paths.
  5. Test rollback, duplicate trigger, database outage, and failed secret access.
  6. Prove one database slice with tenant denial, transaction, export, backup, and restore.
  7. Record unresolved agreement, transfer, and legal questions before protected data.

The migration decision should state whether only compute moved, whether a bridge remains, and which data paths are still excluded. Keep the scope truthful until every gate passes.

Migration planning should include a compatibility inventory rather than a broad promise that the application is portable. List runtime APIs, image base, native modules, scheduled jobs, request limits, streaming behavior, custom domains, secrets, database connections, file uploads, background workers, logging, and health checks. Mark each item as proven, changed, or untested. A container that starts is only one line in that inventory.

Use a staged rollback. First prove the new service with synthetic traffic. Then route a controlled test hostname. Keep the old path available only under an approved and time-limited plan, and document which data it can still read or write. If dual writes are used, reconcile counts and idempotency and delete bridge records after the gate closes. Do not leave a hidden path because it is convenient during migration.

The database decision deserves its own acceptance sentence: Firestore is selected only if query completeness, transactions, tenant authorization, exports, backups, restore, and cost proof pass; otherwise evaluate Cloud SQL PostgreSQL. That keeps the compute lift from forcing a database choice. A migration can retain a temporary non-protected bridge only when its exact service, region, tier, agreement, and deletion plan are approved.

Security evidence should include build artifact, deployment identity, runtime identity, key and secret access, logs, jobs, backup, restore, support, and incident runbook. Test wrong tenant, wrong region, missing secret, failed database, duplicate job, rollback, and direct-origin access. The build and artifact cost review adds the release evidence that a runtime smoke test cannot provide.

Budget separately for container work, job conversion, ingress, database proof, data migration, regionalization, cutover, and ownership. Provider runtime pricing is an estimate; engineering verification is a separate cost. Recheck current pricing and product support before signing a commercial plan.

Frequently asked questions

Should the database move with Cloud Run?

Not necessarily. Separate compute lift from database replacement so runtime behavior, query semantics, tenancy, and recovery can be proven independently. A temporary bridge requires its own contract and control review.

Does Cloud Run pricing include the full migration cost?

No. It covers a provider billing input. Add ingress, logs, keys, secrets, jobs, database, backups, support, migration engineering, tests, and cutover work.

What is the first Cloud Run proof?

Deploy a synthetic application, run its intended route, authenticate jobs, inspect logs and secrets, test rollback, and verify that no unapproved database or region is used.

Does a covered product list authorize the migration?

No. It supports provider scope. Customer configuration, application controls, tenant isolation, contracts, risk analysis, and counsel review remain necessary.

References

Related articles