#GCP Cost Estimation

These are estimates based on published GCP pricing as of July 2026 in a US region (us-central1). Actual costs depend on your region, traffic, and any pricing changes by Google. Always verify with the official pricing pages linked at the bottom.

#What Gets Deployed

A typical tsdevstack project (3 NestJS backends + 1 Next.js frontend) creates these billable resources on GCP:

You can override CPU, memory, instance counts, database tier, Redis tier, and disk size per service in infrastructure.json. See Service Configuration for all available options.

#Scenario 1 — Development (Scale-to-Zero)

Backend services and frontend set to minInstances: 0. Kong stays on (minInstances: 1). Assumed traffic: ~1,000 requests/day (testing only).

Cold starts after scale-to-zero: 2-8 seconds. Cloud Run handles this natively — no wake-up mechanisms needed.

#Scenario 2 — Production (Always-On, Single Instance)

All services set to minInstances: 1. Assumed traffic: ~100,000 requests/day (3M/month).

Cloud Run has two billing modes: CPU allocated during requests (request-based, the tsdevstack default) and CPU always allocated (instance-based). Under request-based billing an always-on instance pays memory for the full 730 hours, CPU at the idle rate while waiting, and the active CPU rate only while serving a request. The figures above assume ~3M requests/month at roughly 150ms of CPU each. Slower or heavier requests push these lines up toward the active rate.

#Scenario 3 — Production Under Load (3 Instances, 24/7)

Assumed traffic: ~10M requests/day (300M/month). At this volume every service is effectively serving continuously, so CPU bills at the active rate for most of the month. Whether that arrives as 2 saturated instances or 3 at partial load barely changes the bill: what you pay for is total active vCPU-seconds, and traffic sets that.

#Cloud Run Billing, and Why Kong Is Not $70

An earlier version of this page listed Kong at ~$70/month. That came from 730 hrs × ($0.0864/vCPU-hr + $0.009/GiB-hr), which applies Cloud Run's active CPU rate to every second of the month. It is not one of the two rates Cloud Run actually charges.

For 1 vCPU + 1 GiB over 730 hours:

It is reasonable to assume Kong is expensive because every request passes through it. Kong does see 100% of traffic, but that is not what drives the bill. Kong runs with a request concurrency of 1000, and under request-based billing CPU is charged while any request is in flight, not per request. One thousand concurrent requests cost the same CPU-second as one.

So the billed fraction of the month is 1 - e^(-arrival_rate × request_duration), not the sum of request durations:

*Above ~10M requests/day the $0.40/million request charge overtakes compute.

Kong only reaches ~$70 at roughly 5M requests/day sustained, at which point it would have scaled past one instance anyway.

#What Drives the Cost

#How to Reduce Costs

• Set minInstances: 0 for backend services and the frontend in dev — accept 2-8s cold starts, pay near-zero for idle compute. Kong is clamped to at least 1 regardless, and production should stay at 1.
• Use db-f1-micro for dev databases — upgrade only when needed
• Right-size CPU/memory — monitor actual usage and lower from defaults if your services don't need 1 vCPU
• Committed use discounts — 1-year commitment saves up to 17% on Cloud Run compute

Override any default in .tsdevstack/infrastructure.json:

{
  "version": "1.0.0",
  "services": {
    "auth-service": {
      "cpu": "0.5",
      "memory": "256Mi",
      "minInstances": 0,
      "maxInstances": 3
    }
  },
  "database": {
    "tier": "db-g1-small",
    "diskSize": 20
  },
  "redis": {
    "tier": "STANDARD_HA",
    "memoryGb": 2
  }
}

See Service Configuration for all available options.

#GCP Pricing References

• Cloud Run Pricing
• Cloud SQL Pricing
• Memorystore for Redis Pricing
• Cloud Load Balancing Pricing
• Cloud Armor Pricing
• Secret Manager Pricing
• Cloud DNS Pricing
• Artifact Registry Pricing