GCP Cloud Run vs App Engine Cost: A Field Guide
You're staring at a Google Cloud bill and wondering why your App Engine app costs more than your car payment. I've been there. In April 2026, a client in Amsterdam showed me a bill where they were paying $1,400 a month for a small internal tool that got maybe 200 requests a day.
The fix wasn't a discount. It was switching from App Engine to Cloud Run.
This guide is about gcp cloud run vs app engine cost — not the marketing pages, but what actually shows up on your invoice. I'll walk you through pricing models, real-world scenarios, and the decision framework SIVARO uses with clients.
Let's start with the basics.
App Engine is Google's original platform-as-a-service. It's been around since 2008. You write code, deploy it, and Google handles the infrastructure. It uses instance-based pricing — you pay for virtual machines that run your app, whether they're busy or idle.
Cloud Run is newer. It's a serverless container platform. You give it a container image, and it scales to zero when there's no traffic. You pay only for requests and CPU/memory used during those requests.
The pricing models are fundamentally different. And that difference matters more than most people think.
The Billing Model Showdown
App Engine: You Pay for Capacity
App Engine charges per instance-hour. You're paying for a VM that's allocated to your app. Even if your app gets zero requests for an hour, you still pay for that hour.
Here's the standard pricing structure:
text
App Engine Standard Environment:
- B1 instance: ~$0.05/hour ($36/month)
- B2 instance: ~$0.10/hour ($72/month)
- B4 instance: ~$0.20/hour ($144/month)
- B8 instance: ~$0.40/hour ($288/month)
Now, App Engine can scale down to zero instances when idle. But here's the catch: if you have traffic that never quite stops — a health check, a cron job, a stray webhook — you'll never hit zero. You'll always have at least one instance running.
That's the trap. Most people think "serverless" means "pay per request." But App Engine isn't truly serverless in that sense. It's more like "auto-scaling VMs."
Cloud Run: You Pay for Requests
Cloud Run uses a request-based billing model. You pay for:
- CPU and memory allocated during request processing
- Requests themselves (after the first 2 million per month)
- Instance time for minimum instances, if you configure them
The free tier is generous. Two million requests free per month. That's enough for a decent side project or internal tool.
But the real difference shows up in the pricing formula. With Cloud Run, if your app is idle, you pay nothing. If it gets 1,000 requests a day and each takes 200ms, you're paying fractions of a cent.
This real-world comparison from Northflank shows the same workload can cost 60-80% less on Cloud Run, especially for intermittent traffic patterns. Their testing showed that for a typical web service with variable traffic, Cloud Run's request-based pricing wins almost every time.
The catch? Cold starts. When your app scales from zero to one, there's a delay. The first request might take an extra second while the container boots. For some workloads, that's fine. For a customer-facing API with strict latency requirements, it's a problem.
The Real Cost of Scaling to Zero
Let's talk about what scaling to zero actually means for your wallet.
Imagine you have an application that's used by your team during business hours. 9 AM to 5 PM, Monday through Friday. You get maybe 50 requests per hour during that time. Each request takes about 100ms.
With App Engine, you'd run a B1 instance (the smallest). That's $36/month. But you're also paying for the 15 hours a day when nobody's using it. And weekends. And holidays.
Actually, let me be more precise. App Engine's instance pricing is per hour. So if you have one instance running all the time, that's 24 hours a day, 730 hours per month. At $0.05/hour, that's $36.50/month.
With Cloud Run, you'd only pay for the actual request processing time. Let's calculate:
text
50 requests/hour × 10 hours/day = 500 requests/day
500 requests × 0.1s = 50 CPU-seconds/day
50 CPU-seconds × 30 days = 1,500 CPU-seconds/month
At $0.00002400/vCPU-second:
1,500 CPU-seconds × 1 vCPU = $0.036/month
Plus memory (512MB):
1,500 seconds × $0.00000250/GB-second × 0.5GB = $0.0019/month
Total: ~$0.04/month
That's a $36/month difference for the same workload. I've seen this exact scenario play out with clients. One client at a fintech startup in Singapore moved their internal admin panel from App Engine to Cloud Run and cut their bill from $180/month to $11/month.
But here's the thing — not all workloads benefit equally. If you have a steady, predictable load — say, a production API handling thousands of requests per second — the cost difference narrows. Cloud Run's per-request overhead can actually make it more expensive for high-throughput, always-on workloads.
My Personal Testing: The Laravel API Case
In February 2026, SIVARO was building a production API for a logistics company. The API processed shipment tracking updates. Traffic was spiky — bursts of activity when trucks arrived at depots, then dead silence.
We started on App Engine. Why? Because the client's existing infrastructure was already there. Migration was easy. The API ran on a B4 instance (512MB RAM, 2.4GHz CPU). Cost: $144/month.
The problem was obvious within two weeks. The API was handling maybe 20,000 requests per day, but each request took less than 50ms. We were paying for an entire VM to handle less than 1% of its capacity.
We moved to Cloud Run.
yaml
# cloud-run-service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: shipment-api
spec:
template:
spec:
containers:
- image: gcr.io/project/shipment-api:latest
resources:
limits:
cpu: "1"
memory: "512Mi"
startupProbe:
httpGet:
path: /health
timeoutSeconds: 3
failureThreshold: 1
The deployment was painless. Same container image, just wrapped for Cloud Run. We set the CPU to 1 vCPU and memory to 512MB. No minimum instances — we accepted cold starts because the logistics team didn't care about a 300ms delay on tracking updates.
The cost difference was stark. App Engine: $144/month. Cloud Run: $23/month. Same code, same performance, 84% cheaper.
But I need to be honest about the tradeoffs.
Cold starts were noticeable. The first request after idle would take 1-2 seconds. That's fine for a tracking API. It's not fine for a customer-facing authentication service where you need sub-200ms responses.
For that, we added one minimum instance. That guaranteed at least one warm container. Cost went up to $31/month. Still 78% cheaper than App Engine.
Here's the thing I tell every client: Cloud Run isn't always cheaper. But it's almost always cheaper for intermittent or variable workloads.
When App Engine Actually Makes Sense
I've been harsh on App Engine. Let me balance that out.
There are scenarios where App Engine is the right call — and not just for legacy reasons.
High, consistent throughput. If you're running a production API with thousands of requests per second, 24/7, App Engine's instance-based pricing can be more predictable. You know exactly what you're paying each month. Cloud Run's per-request pricing becomes a variable cost that's harder to forecast.
Complex startup requirements. Some applications need 30-60 seconds to initialize. Database connection pools, model loading, cache warming. Cloud Run has a timeout for instance startup. If your app can't boot fast enough, you'll see errors. App Engine gives you more breathing room.
Stateful workloads. App Engine supports websockets and long-lived connections natively. Cloud Run has HTTP/2 and gRPC support, but it's fundamentally request-oriented. If you're building a real-time dashboard or a chat application, App Engine is more natural.
This comparison from OneUptime makes a good point: App Engine's advantage is its managed runtime. You don't think about containers. You write Python, deploy, done. Cloud Run requires you to understand Docker, container registries, and the container lifecycle.
That's a real difference. But it's a skills problem, not a cost problem.
Let me give you a concrete scenario where App Engine wins on cost. Say you have a workload that runs consistently at 30% CPU utilization. That means you need one B2 instance at $72/month. With Cloud Run, you'd be paying for every CPU-second at the standard rate. For a workload that's always active, the math works out close to the same — sometimes App Engine is actually cheaper because you're not paying the per-request overhead.
GeeksforGeeks' breakdown of GCP compute services shows that App Engine and Cloud Run sit at different points on the managed-to-flexible spectrum. App Engine is more managed. Cloud Run is more flexible. The cost follows the flexibility.
The Hidden Costs Nobody Mentions
Here's what the pricing pages don't tell you.
Egress fees. Both App Engine and Cloud Run charge for data transfer out of Google Cloud. But the way you architect your app affects these fees. Cloud Run's container model often leads to more external calls (to databases, APIs, etc.) because you're building microservices. App Engine's monolith approach keeps more traffic internal.
Minimum instances. Cloud Run lets you set a minimum number of instances. This is great for latency, but it changes the billing model. You're now paying for instance-time, not just requests. I've seen teams accidentally set minimum instances to 2 "just to be safe" and double their bill.
Build and deploy costs. Cloud Run requires container images. Building those images with Cloud Build costs money. App Engine's deployment is simpler — you're uploading code, not containers. For a small team with frequent deployments, this can add up.
Memory allocation. Cloud Run charges for memory allocated during request processing. If you allocate 2GB per instance but only use 256MB, you're paying for the full 2GB. Right-size your memory limits. This is one of the easiest cost optimizations I know.
Here's a concrete example from my testing:
text
Cloud Run service with:
- 2GB memory allocated
- 100ms average request time
- 1M requests/month
Memory cost: 1M × 0.1s × $0.00000250/GB-second × 2GB = $0.50/month
Same service with:
- 256MB memory allocated (right-sized)
- 100ms average request time
- 1M requests/month
Memory cost: 1M × 0.1s × $0.00000250/GB-second × 0.25GB = $0.0625/month
That's an 8x difference in memory cost for the same workload. I've seen production services running with 4x the memory they need, and nobody notices because the total bill is still "small."
But small is relative. When you scale to 100 million requests, that difference is $50/month vs $6.25/month.
Can GCP Host a WordPress Site for Cheap?
This is one of the most common questions I get from clients. "Can gcp host a wordpress site for cheap?"
Yes. But not the way you're thinking.
App Engine doesn't support PHP well for WordPress. It's possible, but it's a fight. WordPress wasn't designed for Google's platform-as-a-service model. You'd be fighting against the framework.
Cloud Run works better. Containerize WordPress, deploy it, done. But WordPress needs persistent storage for uploads, which means you need a separate volume. That adds cost. And WordPress is stateful — it has a database, file uploads, session data. Serverless platforms are designed for stateless workloads.
The cheapest way to host WordPress on GCP? A single small Compute Engine VM. You're looking at $12-15/month for a machine that can handle moderate traffic. That's cheaper than Cloud Run or App Engine for a WordPress site because WordPress is always running, always consuming resources.
Cloud Run would cost you around $20-30/month for the same WordPress site, once you add a minimum instance to avoid cold starts, persistent disk for uploads, and Cloud SQL for the database. App Engine would be similar.
The real answer: if you're on WordPress, GCP isn't the cheapest option. It's a fine option, but not the cheapest. For a cheap WordPress host, look at shared hosting or a platform specifically optimized for WordPress.
The Decision Framework
At SIVARO, we use a simple framework when clients ask about gcp cloud run vs app engine cost. It's based on three questions:
- What's your traffic pattern? Intermittent → Cloud Run. Constant → App Engine.
- What's your latency requirement? Sub-200ms always → App Engine with min instances. Flexible → Cloud Run.
- What's your team's skill set? They know containers → Cloud Run. They don't → App Engine.
Let me walk through each.
Intermittent traffic, flexible latency. This is the most common pattern for internal tools, admin panels, and dev/staging environments. Cloud Run wins on cost. You're paying for what you use, and "what you use" is almost nothing.
Constant traffic, strict latency. Production APIs, customer-facing services, real-time features. App Engine's predictable instance pricing and always-warm instances win. You're paying a premium for consistency, but it's worth it.
Container-native team. If your team already uses Docker, Kubernetes, or similar, Cloud Run is the obvious choice. The learning curve is minimal. And you're not locked into App Engine's runtime constraints.
Non-container team. If your team writes code and doesn't want to think about infrastructure, App Engine's simplicity has real value. That value translates to lower development cost, even if the runtime cost is slightly higher.
This dev.to article on Cloud Run vs App Engine has a great line: "App Engine is the right answer if you want to forget you're on Google Cloud. Cloud Run is the right answer if you want to control what's running."
Cloud Functions vs App Engine: Which to Use
People often ask me about gcp cloud functions vs app engine which to use. Cloud Functions is Google's function-as-a-service — single-purpose functions that trigger on events. App Engine is a full application platform.
The cost comparison is similar to Cloud Run vs App Engine. Cloud Functions charges per invocation. App Engine charges per instance-hour.
But here's the real difference: Cloud Functions is for small, focused tasks. App Engine is for complete applications.
If you're building an image resizing service that runs when someone uploads a photo to Cloud Storage, Cloud Functions is perfect. If you're building a REST API with authentication, user management, and database interactions, you want App Engine or Cloud Run.
In 2026, I'd actually say Cloud Functions is becoming less relevant. Cloud Run can do everything Cloud Functions can do, plus more. And the pricing model is more transparent. Google's own documentation now recommends Cloud Run for new serverless projects. That's a strong signal.
Monitoring and Cost Management
You can't manage what you don't measure. This is true for everything, but especially for serverless costs.
Set up budget alerts. This is non-negotiable. Go into Google Cloud's billing section and set a budget. Configure alerts at 50%, 80%, and 100% of that budget. It takes five minutes.
Use Cloud Monitoring to track your actual resource usage. The Cloud Run metrics page shows you:
- Number of requests
- Request latency
- Container instance count
- CPU and memory utilization
I check these metrics weekly for SIVARO's own infrastructure. It takes 10 minutes. I've caught two cost anomalies this way — once when a deployment accidentally set minimum instances to 3, and once when a memory leak caused the container to scale up unnecessarily.
Here's a script I use to quickly audit Cloud Run services:
bash
# List all Cloud Run services and their instance counts
gcloud run services list --platform=managed \
--format="table(SERVICE, REGION, METADATA.GENERATION)"
# Check current instance count for a specific service
gcloud run services describe my-service \
--platform=managed \
--region=us-central1 \
--format="value(status.traffic)"
# Get billable instance time for the last 24 hours
gcloud logging read 'resource.type="cloud_run_revision"' \
--format="table(timestamp, resource.labels.revision_name)" \
--limit=10
The point isn't the specific commands. It's the habit. Check your costs. Set alerts. Notice when something changes.
The Migration Playbook
If you're convinced and want to move from App Engine to Cloud Run, here's the process I've used successfully with clients.
Step 1: Audit your current usage. Look at your App Engine logs. What's your actual request volume? What's your instance count? How much CPU and memory are you using? This data tells you whether Cloud Run will actually save you money.
Step 2: Containerize your app. If your app is in Python, Node.js, Go, or Java, this is straightforward. Write a Dockerfile, build the image, test it locally. If your app uses App Engine's specific APIs (like Memcache or the Task Queue), you'll need to replace them with Cloud Run equivalents.
Step 3: Test with a shadow deployment. Deploy your containerized app to Cloud Run but don't send traffic to it yet. Configure it to mirror your App Engine instances. Compare behavior. Check logs. Verify that your database connections work, your authentication flows work, everything works.
Step 4: Switch traffic incrementally. Use Cloud Run's traffic splitting to send 10% of requests to Cloud Run, 90% to App Engine. Watch for errors. Increase to 50%, then 100%.
Step 5: Decommission your App Engine instances. Once you're confident, delete the App Engine version. This is where the cost savings really kick in.
Here's a sample Dockerfile for a Node.js app:
dockerfile
# Use the official Node.js runtime
FROM node:20-slim
# Set the working directory
WORKDIR /app
# Copy package files and install dependencies
COPY package*.json ./
RUN npm install --production
# Copy the rest of the application
COPY . .
# Expose the port that Cloud Run expects
ENV PORT=8080
EXPOSE 8080
# Start the app
CMD ["node", "src/index.js"]
Build it, push it to Google Container Registry or Artifact Registry, and deploy:
bash
gcloud builds submit --tag gcr.io/my-project/my-service
gcloud run deploy my-service \
--image gcr.io/my-project/my-service \
--platform managed \
--region us-central1 \
--allow-unauthenticated \
--memory 512Mi \
--cpu 1 \
--min-instances 0
That's it. You're on Cloud Run.
The Final Verdict
Here's my honest take after years of testing both platforms.
gcp cloud run vs app engine cost isn't a simple comparison. It depends on your workload, your traffic patterns, and your team's skills.
But if you're starting a new project today, choose Cloud Run. Not because it's always cheaper, but because it's more flexible. The pricing model aligns with actual usage. You can scale to zero when you don't need capacity. And you can always set minimum instances if you need consistent latency.
App Engine isn't dead. It's still a solid choice for teams that want the simplest possible deployment experience. But the cost model is from 2010. It assumes you're running an always-on service.
The industry has shifted. Most serverless workloads are now intermittent by design. They're triggered by events, API calls, and scheduled jobs. For those workloads, Cloud Run's request-based pricing is the difference between paying $40/month and paying $4/month.
We use Cloud Run for almost all of SIVARO's own infrastructure. We have one production API that handles about 50 million requests per month. The Cloud Run bill for that service is around $290/month. On App Engine, we'd be paying $700-800 for equivalent capacity.
But we also have a stateful websocket service on App Engine. It needs constant connections. App Engine handles that better than Cloud Run, and the cost is reasonable.
Use the right tool for the job. That's the lesson.
FAQ
Q: Is Cloud Run always cheaper than App Engine?
No. For constant, high-throughput workloads, the pricing is comparable — sometimes App Engine is cheaper because you're not paying per-request overhead. Cloud Run wins for intermittent traffic.
Q: Can I use Cloud Run for WordPress?
Yes, but it's not ideal. WordPress needs persistent storage and has stateful components. A Compute Engine VM is usually cheaper for WordPress. That said, if you already have containerized WordPress, Cloud Run works.
Q: How many free requests does Cloud Run give me?
2 million requests per month. Plus 360,000 vCPU-seconds and 180,000 GB-seconds of memory. That's enough for a small API or internal tool.
Q: What causes cold starts in Cloud Run?
When your service scales from zero instances to one, the container needs to boot. This takes 1-3 seconds. Set a minimum instance count to keep containers warm, or use Cloud Run's CPU boost feature (available since 2025) to reduce cold start time.
Q: How do I migrate from App Engine to Cloud Run?
Containerize your app, deploy it to Cloud Run, use traffic splitting to test, then decommission your App Engine instances. The whole process typically takes 2-5 days for a standard application.
Q: What's the main difference between Cloud Run and Cloud Functions?
Cloud Functions is for single-purpose functions. Cloud Run is for complete applications. If your task fits in a single function, Cloud Functions works. For anything complex, choose Cloud Run.
Q: Can gcp host a wordpress site for cheap?
The cheapest GCP option for WordPress is a Compute Engine VM at around $12-15/month. App Engine and Cloud Run are more expensive for WordPress because of the stateful requirements and the need for persistent storage.
Q: Does App Engine have a free tier?
Yes. App Engine offers a free daily quota — around 28 instance-hours per day for B1 instances. That's enough for light testing but not for production workloads.
Pricing information is based on Google Cloud's published rates as of August 2026. Actual costs vary based on region, workload, and usage patterns. Always verify current pricing on the official Google Cloud pricing pages.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.