Planning a new product for Cloud Run before you write it

Planning a new product for Cloud Run means deciding before the first commit where state lives: sessions in signed cookies, files in Cloud Storage, timers in Cloud Scheduler, slow work in Cloud Tasks, and the data in one database. At 300 visitors a day the service fits Google's free tier, and the product costs about $10 a month with Cloud SQL or under $1 with Firestore.

In short

• The smallest Cloud SQL for PostgreSQL, db-f1-micro with 10 GiB, is $9.37 a month, takes 25 connections and has no SLA; a dedicated core is about $51.
• Firestore gives each project one free database with 1 GiB, 50,000 reads, 20,000 writes and 20,000 deletes a day.
• The sample product costs $9.89 with Cloud SQL or $0.53 with Firestore at 300 visitors a day, and $111.26 or $70.24 at 20,000.
• Cloud Tasks is free for the first million operations a month; Cloud Scheduler gives 3 jobs free per billing account, then $0.10 per job per 31 days.

Prices are europe-west1 list prices, read on October 12, 2026.

Why plan for Cloud Run first

Most of the work of moving an app to Cloud Run is undoing a few habits of a server (the patterns that break on Cloud Run): a timer inside the process, files written to the local disk, sessions kept in memory, a worker that runs all day waiting for a queue. A product planned for Cloud Run from the first commit never picks them up, and it grows by raising limits, not by a rebuild.

Cloud Run bills a service only while it works. On the default request-based billing, an instance gets CPU while it handles a request, and when no requests arrive Cloud Run stops every instance and bills nothing. That model is what makes a small product cheap, and it is also what breaks the habits above: an instance that is stopped runs no timer, an instance that is replaced loses its memory and its disk, and work done after the response gets no CPU.

So a product for Cloud Run is built from parts that hold no state, each with its own way of being woken up. A product sold to many customers adds tenants, sign-in and customer domains to the same parts, as in a SaaS architecture on Cloud Run.

Where state lives

A Cloud Run service may run as zero copies at night and twenty at noon, and any copy may answer any request. Its disk is a part of its memory and disappears with it. So nothing a request needs later can stay inside one copy.

• Sessions go into a signed, encrypted cookie, or into a sessions table in the database for anything larger than a few kilobytes. No Redis is needed for this; our sessions guide shows both.
• Files go to a Cloud Storage bucket. The browser uploads straight to the bucket with a signed URL, which gives time-limited access to one object, so large files never pass through the service. See the files guide.
• Scheduled work runs as a Cloud Run job that Cloud Scheduler starts on a cron schedule. The job does its work and exits; nothing stays running between runs. See the cron guide.
• Settings are environment variables on the service, and secrets come from Secret Manager into those variables, so no file of keys lives in the image or the repository.

Pick the database by the bill and by the data

The database is usually the largest line of a small product's bill, because it is the one part that runs all the time. The choice is mostly between two, and our database comparison goes deeper.

Cloud SQL for PostgreSQL is the familiar choice: the same SQL, drivers, migrations and tools, daily backups and point-in-time recovery. The smallest instance, db-f1-micro, shares a CPU core and costs $0.0105 an hour in europe-west1, $7.67 a month, plus $1.70 for its smallest 10 GiB disk: $9.37. Two limits come with it. Its connection limit is 25, so every copy of the service needs a small pool (five connections a copy allows four copies with room for a migration job). And Google states that shared-core instances are not covered by the Cloud SQL SLA and are meant for testing and development; a product with paying users moves to a dedicated core, about $51 a month for 1 vCPU and 3.75 GiB.

Firestore has no instance. It bills per document read, write and delete and per GiB stored, and each project gets exactly one free database with 1 GiB of storage, 50,000 reads, 20,000 writes and 20,000 deletes a day. Past that, in europe-west1, reads are $0.033 per 100,000, writes $0.099 per 100,000 and storage $0.165 per GiB-month. A small product often pays nothing. The price is in the code: data is documents in collections, there are no joins, and a page that would be one SQL query can be several reads.

A rule that holds for most products: if the data is relational (customers, orders, invoices, permissions across them), start with Cloud SQL and budget $10 a month, then a dedicated core before the first paying customers. If the data is mostly documents read by key (profiles, settings, a feed), Firestore costs less and needs no pool.

Background work and schedules

• Work a user starts, such as sending an email, resizing an image or calling a slow outside API, goes to Cloud Tasks. The service puts a task on a queue and answers at once; Cloud Tasks then calls the service back with the task, retries it if it fails, and limits how many run at a time. The first million operations a month are free, then $0.40 per million. See the Cloud Tasks guide.
• Work on a schedule runs as a Cloud Run job started by Cloud Scheduler. A Scheduler job costs $0.10 per 31 days, and each billing account gets three free, counted across all its projects.
• A consumer that must listen all the time, for Pub/Sub pull or Kafka, runs as a worker pool, which Google made generally available in 2026. Most small products do not need one: Pub/Sub can push messages to the service as requests instead.

Never run work after the response in the service itself. On request-based billing it gets almost no CPU once the response is sent, and an instance may be stopped before it finishes; our guide on that shows what happens.

Payments, webhooks and live updates

A payment provider's webhook is an ordinary HTTPS request, so the service takes it like any other. Plan it like this from the start: check the signature, put a task on the queue keyed by the provider's event id so a retried webhook is not processed twice, and answer 200 at once. Our webhooks guide has the code.

Live updates over WebSockets or server-sent events work on Cloud Run, but each open connection is a request, and requests are subject to the request timeout: 5 minutes by default, 60 at most. The client has to reconnect when it ends, and may reach another instance. An instance with an open connection is billed for as long as the connection is open, so a thousand idle browser tabs keep instances running. If a page refresh or polling every few seconds is enough, plan that; if not, read the WebSockets guide first.

Region, project and deploys

Put the service and the database in one region, nearest your users: traffic between Google services in the same region is free, and every query that crosses regions adds latency. Google prices Cloud Run in two tiers, and Tier 2 regions cost more for the same work; europe-west1 (Belgium) and us-central1 (Iowa) are Tier 1. Our region guide lists them.

Keep production in a project of its own, with a budget alert from the first day; the project setup guide walks through it. Deploy from CI with Workload Identity Federation, so no service account key exists to leak, as in the keyless deploys guide.

What it costs at launch and in a year

To put numbers on it, take a sample product: lesson bookings and payments for independent tutors, built as the diagram above. Assume each visitor makes 8 requests of 0.25 s on an instance of 1 vCPU and 512 MiB, no two requests share an instance (an upper bound), every second visitor triggers an email task, 300 visitors a day send 5 GB of responses a month, and traffic and files grow with visitors. With Firestore, each request reads 5 documents and every second one writes one. Prices are europe-west1 list prices read on October 12, 2026, for a 730-hour month.

• At launch, 300 visitors a day. 73,000 requests a month use 18,250 vCPU-seconds, a tenth of the free tier, so the service costs $0. The bill is the database ($9.37 for Cloud SQL, $0 for Firestore), $0.49 of traffic at $0.105 per GiB and $0.04 of file storage: $9.89 or $0.53.
• In a year, at 15% growth a month. 1,605 visitors a day make 390,568 requests a month, still inside the free tier. Traffic grows to $2.62. Firestore's reads pass the free 50,000 a day and cost $0.14. Total $12.08 or $2.86.
• Busy, 20,000 visitors a day. 4.87 million requests: $24.88 of CPU, $0.62 of memory and $1.15 of requests after the free tier, $32.60 of traffic and $1.00 of files. Cloud SQL moves to a dedicated core at $51.01; Firestore costs $10.00 in reads, writes and storage. Total $111.26 or $70.24.

So at launch the database is more than nine-tenths of the bill, and the choice of database matters more than anything else. As traffic grows, the service and the traffic out become the larger part, and the first thing to size up is the database's tier, not the service. The cost of every other part (Tasks, Scheduler, Secret Manager, a few stored images) stays at or near zero at all three sizes.

How Exodus plans it

Exodus plans a new product with the same command line it uses for a move. Run exodus init with its new-product flag in an empty folder, as in the terminal below; it writes instructions for your coding agent, which then asks you eight questions (what the product does, who uses it and from where, visitors a day, growth, payments, live updates, language and framework, traffic out), records each answer with exodus answer, writes down the design decisions above for your product, and builds the plan.

For the sample product in europe-west1, exodus 0.1.3 priced the launch at $10.04 a month: $0 for the service, Cloud Tasks and the Scheduler job, $9.37 for Cloud SQL, $0.04 for files, $0.03 for stored images and $0.60 for 5 GB of traffic at $0.12. Its plan has 11 tasks in four phases (Scaffold, Build the core, Stand up on Google Cloud, Launch), one per design decision, plus the infrastructure with "a database pool of 5 a copy, because db-f1-micro takes 25 connections" and keyless deploys from CI.

Two differences from the model above are worth knowing. The report's forecast for the year keeps traffic at the 5 GB you answered, so it shows $10.04 in a year as well; the chart above grows traffic with visitors. And its "What works differently" list says a Cloud Run job can run for up to 24 hours, where Google's current limit is 168 hours. The report states the assumptions it used, so you can see both.

What breaks

• Firestore chosen for relational data. Joins become several reads, and changing a customer's name means rewriting every document that copied it. Pick by the shape of the data, not only by the price.
• The micro instance in production. It has no SLA and 25 connections. Plan the move to a dedicated core before the first paying customers, and set the pool size from day one.
• A pool sized for a server. Twenty connections a copy across five copies is 100 connections, four times what the micro instance takes. Size the pool from the database's limit and the service's maximum instances.
• Webhooks processed twice. Providers retry. Key each task by the event id and make the handler idempotent.
• WebSockets for everything. Open connections keep instances billed and end at the request timeout. Use them where the product needs them.
• Local files in development. Code that writes uploads to a folder works on a laptop and loses them on Cloud Run. Use the bucket, or its emulator, from the first commit.

Checklist

1. One Cloud Run service for the web app or API, keeping nothing between requests.
2. Sessions in signed cookies or the database; files in Cloud Storage through signed URLs.
3. Schedules as Cloud Scheduler starting Cloud Run jobs; slow work as Cloud Tasks.
4. The database chosen by the shape of the data and the bill: Cloud SQL at $9.37 a month to start, a dedicated core before paying users, or Firestore.
5. A connection pool sized from the database's limit.
6. Webhooks that check the signature, queue the work and answer at once.
7. One region, nearest the users, Tier 1 if it suits; production in its own project with a budget alert.
8. Deploys from CI without key files.

FAQ

How much does a small product cost to run on Cloud Run?

Our sample product with 300 visitors a day costs $9.89 a month with Cloud SQL or $0.53 with Firestore in europe-west1. Its 73,000 requests use a tenth of the free tier, so the service costs nothing and the database is most of the bill. At 20,000 visitors a day it is $111.26 or $70.24.

Should a new product on Cloud Run use Cloud SQL or Firestore?

Pick by the shape of the data. Relational data, such as customers, orders, invoices and permissions across them, starts on Cloud SQL at about $10 a month. Documents read by key, such as profiles, settings or a feed, cost less on Firestore, which has a free tier and needs no connection pool.

Is the db-f1-micro Cloud SQL instance enough for production?

Google says shared-core instances are not covered by the Cloud SQL SLA and are meant for testing and development, and db-f1-micro takes 25 connections. Start on it, size the pool from that limit, and move to a dedicated core, about $51 a month for 1 vCPU and 3.75 GiB, before the first paying customers.

Does a new product on Cloud Run need Redis?

Not for sessions or queues. Sessions go into a signed cookie, or a sessions table in the database for anything larger than a few kilobytes. Slow work goes to Cloud Tasks, free for the first million operations a month, and scheduled work to Cloud Scheduler starting a Cloud Run job.

Which region should a new Cloud Run product use?

The one nearest your users, with the service and the database in the same region, since traffic between Google services in one region is free. Tier 1 regions such as europe-west1 (Belgium) and us-central1 (Iowa) cost less for the same work than Tier 2.