Cloud Run uses a fully managed, pay-as-you-go pricing model. You are charged only for the resources your workload actually consumes, billed per 100ms.

There is also a monthly Free Tier

On Google Cloud Run, you can deploy any stateless containerized application that runs in a Linux-based Docker container (x86_64 or ARM64).

• For a Cloud Run Service, the container must listen on a network port (typically PORT, default 8080) for HTTP/gRPC traffic.
• For Jobs and Worker Pools, the container does not need to expose an HTTP port — it just needs to run and perform its task.

In short: If it runs in a Linux container, Cloud Run can run it — whether it’s a FastAPI app, a Node service, a Go binary, a batch script, or a background worker.

When you write a Dockerfile, build it, and push it to Google Artifact Registry, you are just uploading a tarball (a zipped folder of your Linux environment and Python code). When Cloud Run "runs" it, it is NOT running on a dedicated Virtual Machine just for you.

It is running on Google's massive, planetary-scale internal server fleet (called Borg). Because Google is running your code on the same physical hardware as other companies' code, they cannot trust standard Docker (which shares the host OS kernel).

You are renting an isolated, heavily sandboxed Linux process on a Google supercomputer.

An instance is one physical, running copy of your container. Think of your Docker image as a blueprint. The instance is the actual house built from the blueprint.

• If you set Cloud Run limits to 4 vCPUs and 16GB RAM, one instance has exactly that much power.
• As mentioned in the previous answer, if you set concurrency to 80, this one instance will accept up to 80 simultaneous requests.
• If request #81 comes in, the Cloud Run Load Balancer says, "This instance is full!" and instantly builds a second instance (another 4 vCPU / 16GB RAM clone) to handle request #81.

Now you have two instances. You are paying for two instances.

Concurrency isn't just a number; it's a cost and performance lever.

• Default: 80
• Max: 1000

Formula for Python: Set your THREADS or WORKERS equal to your concurrency if you are using a synchronous server (like Gunicorn/Flask) to ensure the instance can actually handle the simultaneous load.

In Cloud Run, there is one non-negotiable rule: Your server must listen on 0.0.0.0 (all network interfaces), and it must bind to the port Cloud Run expects (which defaults to 8080). Ideally this port is mentionned as an environment variable in the Dockerfile.

Then need to build the image to artifact registry, and then deploy to cloud run using that image.

Yes, but how they are handled depends entirely on your framework and server configuration. Cloud Run will gladly send 80 requests at the exact same millisecond to your single container instance.

With Flask (WSGI / Synchronous) — By default, standard Python is synchronous. If you don't configure your WSGI server (like Gunicorn) with threads or multiple workers, Flask processes one request at a time. The other 79 requests will sit in a queue waiting for the first one to finish.

With FastAPI (ASGI / Asynchronous) — FastAPI runs on an event loop. If your code uses async def and is doing I/O-bound tasks (like waiting for OpenAI's API or a database), a single worker can pause the waiting request and start processing the other 79 concurrently.

Only if you configure Gunicorn correctly.

If your Dockerfile just says:
CMD ["gunicorn", "-b", "0.0.0.0:8080", "app:app"]

You have 1 synchronous worker. It will handle exactly 1 request at a time. If a request takes 5 seconds to run your AI inference, the next request waits 5 seconds. Concurrency is effectively 0.

To fix this for Flask:
You must add threads or workers to Gunicorn.

CMD ["gunicorn", "--workers", "1", "--threads", "8", "-b", "0.0.0.0:8080", "app:app"]

Now, Gunicorn uses a thread pool. When Request A hits an I/O pause, the Python GIL (Global Interpreter Lock) switches to Request B. You can now handle 8 concurrent requests. No need to put any 'async' in front of the code.

Yes, highly concurrently—but ONLY for I/O-bound tasks.

Because Uvicorn uses an asynchronous event loop (asyncio), 1 single Uvicorn worker can handle hundreds of concurrent requests. If your endpoints are async def and you do a network call (e.g., await client.chat.completions.create(...)), concurrency works perfectly.

However, if you put CPU-bound work (e.g., matrix multiplications, pandas data processing, or standard synchronous PyTorch model inference) directly inside an async def function, you will block the event loop.

If the event loop is blocked, your concurrency immediately drops back to 1. No other requests can be processed until the CPU finishes that math. One way to not block the event loop is to run the CPU-bound code in a threadpool (run_in_threadpool function in FastAPI).

Another way is to define the route as def and have synchronous code inside. This makes FastAPI handle the concurrency itself.

• Throttling (Default): You pay per request. CPU is throttled to nearly zero the moment the response is sent. Result: Background threads freeze.
• Instance-based billing or Always-Allocated: You pay for the entire life of the instance. CPU is always available.

The New "Startup CPU Boost": There is now a middle ground. You can enable Startup CPU Boost, which gives your container extra CPU power only during startup and for 10 seconds after. This is the "Goldilocks" setting for Python apps with heavy imports (like pandas or tensorflow)—it speeds up cold starts without the high cost of Always-On CPU.

Cold start is the latency between the first request arriving and the container being ready to serve it.

Contrary to popular belief, image size matters less than you think. Google uses a "streaming" file system for images. It pulls the chunks it needs to start the app first. However, a 2GB image will still be slower than a 200MB image because of metadata overhead. Use Slim or Distroless images.

When Cloud Run decides to scale down (because traffic dropped) or a deployment happens, it doesn't just pull the plug.

• The Signal: It sends a SIGTERM to your container (Process ID 1).
• The Grace Period: You have 10 seconds (default) to wrap up.
• The Kill: After the grace period, it sends SIGKILL.

Why this matters: If you are halfway through writing a file to Cloud Storage or updating a DB, you need to catch that SIGTERM in Python using the signal library to shut down gracefully.

No. There are two reasons why the file is not guaranteed to be there:

• Horizontal Scaling: The second request might be routed to a different instance (a completely fresh container) that doesn't share the /tmp directory of the first one.
• Scale-to-Zero: If no other traffic occurred during those 5 minutes, Cloud Run likely terminated the original instance to save costs, wiping its in-memory file system (RAM) entirely.

The Rule: Cloud Run is stateless. Treat /tmp as volatile storage that exists only for the duration of a single request. For persistence, use Cloud Storage or a Cloud SQL database.