You have packaged your app as a container. On Google Cloud there are two main places to run it: Cloud Run and Google Kubernetes Engine (GKE). Both are good. They suit different teams, and picking the wrong one usually means either paying for a cluster you don’t need or outgrowing a platform that can’t do what you want.

The short version

• Cloud Run: you give Google a container, it gives you a web address. It scales up with traffic and back down to zero when nobody is using it. No servers or clusters to look after.
• GKE: a managed Kubernetes cluster. You get the full Kubernetes toolkit and fine control over networking, scheduling and storage, and you take on more to manage.

Side by side

What it costs to sit idle

This is where small teams feel the difference most.

• Cloud Run with request-based billing charges nothing for instances that aren’t handling requests, as long as you haven’t set a minimum number of instances. Its free tier covers 2 million requests and 180,000 vCPU-seconds a month per billing account. Many internal tools and early-stage apps cost very little.
• GKE charges a cluster management fee of US$0.10 per cluster per hour, about US$73 a month. A monthly credit of US$74.40 per billing account covers one Autopilot or zonal cluster. A second cluster, or a regional cluster, is paid in full. On top of that you pay for your pods (Autopilot) or VMs (Standard), even at 3 a.m. when nobody is using the app.

Choose Cloud Run when

• You run websites, APIs or internal tools that answer web requests.
• Traffic goes up and down: busy in office hours, quiet at night, spikes during a sale.
• Nobody on the team knows Kubernetes, and you would rather not hire for it yet.
• You have scheduled or background tasks. Cloud Run jobs run a container to completion, such as a nightly report or a data import.
• You want to launch this week.

Choose GKE when

• You run many services that talk to each other and need fine control over how they connect.
• You depend on Kubernetes tools: Helm charts, operators, a service mesh, or software that ships only as Kubernetes manifests.
• You have long-running or stateful workloads that don’t fit a request-and-response model.
• Your load is steady and high around the clock, so paying for reserved capacity works out cheaper.
• Your team already knows Kubernetes, or you need the same setup on more than one cloud.

A worked example

Take a typical small company app: a customer portal busy from 9 to 7 on weekdays, quiet at night and at weekends, with a reporting job that runs once a night.

• On Cloud Run, the portal runs as a service that scales with visitors and drops to zero overnight, and the report runs as a Cloud Run job. There is no cluster to patch and nothing to pay for while it sits idle.
• On GKE, the same app needs a cluster that is always there, pods that are always running, and someone who keeps the cluster up to date. It works well, but most of the capacity is paid for while nobody is using it.

Now take a different company: forty services, a message queue, steady traffic all day and night, and a team that already runs Kubernetes elsewhere. Here GKE is the natural home, and its extra control pays for itself.

Questions to ask before you decide

1. Does anyone on the team know Kubernetes well, and will they still be here in a year?
2. Is traffic uneven, or steady around the clock?
3. Does any tool you rely on ship only for Kubernetes?
4. How many services do you run today, and how many in a year?
5. Who will be on call when something breaks at night?

If most answers point to “small team, uneven traffic, few services”, start with Cloud Run.

Start small, move later

The good news is that the choice isn’t permanent. Both run the same container images, which you keep in Artifact Registry. A sensible path for most small teams:

1. Start on Cloud Run in an Indian region, Mumbai (asia-south1) or Delhi (asia-south2).
2. Keep your app stateless: store data in a managed database such as Cloud SQL, and files in Cloud Storage.
3. Build and deploy with a pipeline (Cloud Build or GitHub Actions), not by hand.
4. Move a service to GKE Autopilot only when you hit something Cloud Run can’t do. Your containers come with you.

Mistakes we see

• A GKE Standard cluster for one small app. Weeks of set-up and a monthly bill for capacity that sits mostly empty.
• Minimum instances everywhere on Cloud Run. Keeping instances warm avoids slow first requests, but you pay for them. Use it only on the services where speed matters.
• Regional clusters by default. They are more resilient, but the free monthly credit doesn’t cover them. Decide on purpose.
• Secrets in environment variables. Use Secret Manager on either platform.

Where DevOps TechLab fits

We help teams pick the platform, set it up in an Indian region, and build the pipeline that ships every change. If you are already on GKE and the bill feels high for what you run, we can tell you whether Cloud Run or Autopilot would cost less, and what moving would involve.