Cloud Run

Cloud Run runs containerized HTTP services and jobs on a fully managed platform. You ship the same Docker image used locally; GCP scales instances by request concurrency, supports custom domains, and integrates with IAM and Cloud Logging out of the box.

					apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - image: gcr.io/project/api:1.4.0
          ports:
            - containerPort: 8080
          env:
            - name: NODE_ENV
              value: production
          resources:
            limits:
              memory: 512Mi
              cpu: '1'
				

| Setting | Purpose | |---------|---------| | Concurrency | Requests per instance before scaling out | | Min instances | Reduce cold starts at the cost of idle billing | | CPU always allocated | Better for background work inside the container |

Node.js APIs should listen on `PORT`, handle `SIGTERM`, and keep sessions or uploads in external stores.

On interviews: Cloud Run versus Cloud Functions versus GKE; cold starts and min instances; stateless design; IAM invoker permissions; request timeouts.

Common pitfalls: assuming WebSocket or long-lived connections work without extra design; writing to local disk; oversized images slowing cold start; missing health on startup.

The trade-off is operational simplicity and per-request billing versus less control over networking, node tuning, and exotic runtime needs.

Checklist:

• Deploy immutable container images per revision.
• Externalize sessions, caches, and uploads.
• Set concurrency, memory, and timeout deliberately.
• Use min instances only where latency SLO requires it.