{/* banner prompt: A minimal, clean top-down view of a Scandinavian-style light wood desk where a developer's hands arrange five simple wooden cards, each with an icon and a price, bathed in soft natural light from a window.

Additional instructions: The cards must show only simple engraved icons and short word labels, with no numbers, no dollar signs, and no price figures anywhere in the image. Anatomically correct, exactly two hands. */}
Cloudflare has become a default stop for anyone putting something on the internet, and the reason is simple: it gives away an unusual amount for free. Point your domain's nameservers at it and you get **DNS hosting** that's fast and free, **caching and CDN** so your site is served from a few hundred cities instead of one box, **DDoS protection** with no attack-size cap, and **free SSL certificates** that renew themselves. For a huge number of sites that's the entire relationship with Cloudflare: a free, genuinely excellent front door, and no invoice.

What's less widely known is the rest of the platform sitting behind that front door: a full developer stack (compute, SQL, stateful coordination, email, containers) that a lot of developers end up using once they're already there. These are the services that *do* meter, and because the free front door sets the expectation that Cloudflare is the cheap option, it's worth knowing in detail what each one does and what it charges before you build on it.

Every number below was pulled from Cloudflare's developer docs at the time of writing; links are in the [references](#references) section at the end so you can re-check them yourself, because cloud pricing pages change.

## D1: Cloudflare's serverless SQL database

[D1](https://developers.cloudflare.com/d1/) is a managed SQLite database that runs close to your Workers. You get normal SQL (tables, indexes, joins, transactions) without running a database server, and it replicates for read availability without you configuring anything. For a Worker that needs structured, queryable state (a SaaS app's primary store, a CMS, a small analytics table), it's genuinely pleasant to use: no connection pooling to think about, no server to patch, first ~5 GB free.

**Good use cases:** the backing store for a small-to-medium web app, per-tenant data for a multi-tenant SaaS (D1 supports many databases cheaply), read-heavy content like a blog's post index, anything where "a Postgres box I have to manage" is overkill.

**How it's billed:** per *row* read and written, not per query. Writes are roughly 1,000x the unit price of reads, which is worth keeping in mind when you design your access patterns.

<Table data={
    {
        headers: ['Dimension', 'Free (Workers Free)', 'Included (Workers Paid)', 'Overage'],
        rows: [
            ['Rows read', '5 million / day', '25 billion / month', '$0.001 per million rows'],
            ['Rows written', '100,000 / day', '50 million / month', '$1.00 per million rows'],
            ['Storage', '5 GB total', '5 GB included', '$0.75 / GB-month'],
        ]
    }
} />

## Durable Objects: stateful coordination at the edge

[Durable Objects](https://developers.cloudflare.com/durable-objects/) give you a single, globally-addressable instance of a class that holds state in memory and on disk, with strong consistency. That's the thing Workers alone can't do, since a Worker has no persistent identity between requests. They're the right tool for coordination problems: a chat room, a multiplayer game session, a per-user rate limiter, a websocket hub, a workflow that needs to "wake up" later via an **alarm**.

**Good use cases:** anything that needs one authoritative, stateful coordinator. WebSocket fan-out, collaborative editing, a queue-per-tenant, a cron-like job scheduled with `setAlarm()`.

**How it's billed:** on *three* axes at once. Requests (including alarm invocations), GB-seconds of duration while the object is live, and the same SQLite row-read/row-write storage rates as D1 for anything it persists.

<Table data={
    {
        headers: ['Dimension', 'Included (Workers Paid)', 'Overage'],
        rows: [
            ['Requests (HTTP/RPC/WS/alarms)', '1 million / month', '$0.15 per million'],
            ['Duration', '400,000 GB-s / month', '$12.50 per million GB-s'],
            ['SQLite rows read', '25 billion / month', '$0.001 per million rows'],
            ['SQLite rows written', '50 million / month', '$1.00 per million rows'],
            ['SQLite stored data', '5 GB-month', '$0.20 / GB-month'],
        ]
    }
} />

## Workers: the compute underneath everything else

[Workers](https://developers.cloudflare.com/workers/) is the serverless JS/WASM runtime everything above actually runs on. It's billed on two axes: **requests** (how many times your code ran) and **CPU time** (how long it actually used the CPU per invocation, not wall-clock time spent waiting on I/O, just active compute). The free plan is genuinely usable for small projects; the paid plan's $5/month buys a real amount of headroom.

**Good use cases:** API backends, edge middleware (auth, redirects, A/B routing), webhook handlers, anything latency-sensitive that benefits from running in 300+ cities instead of one region.

**How it's billed:** on both axes independently: the number of invocations, and the CPU milliseconds they consume. Note that CPU time counts only active compute, not wall-clock time spent waiting on a `fetch()` or a database round-trip, so an I/O-heavy Worker is cheaper than its response time suggests.

<Table data={
    {
        headers: ['Dimension', 'Free plan', 'Included (Workers Paid, $5/mo)', 'Overage'],
        rows: [
            ['Requests', '100,000 / day', '10 million / month', '$0.30 per million'],
            ['CPU time', '10 ms / invocation, no overage', '30 million CPU-ms / month', '$0.02 per million CPU-ms'],
        ]
    }
} />

30 million CPU-ms is about 8.3 CPU-hours a month before overage kicks in. The overage rate works out to roughly $0.072 per CPU-hour, which is cheap *per unit* but adds up quickly if individual requests are taking seconds instead of milliseconds.

## Email Sending: transactional mail without a third-party provider

The [Email Workers send binding](https://developers.cloudflare.com/email-routing/email-workers/send-email-workers/) lets a Worker send transactional email directly (magic-link logins, notifications, receipts) without wiring up a separate provider. It requires the Workers Paid plan, and the price per email is low.

**Good use cases:** magic-link authentication, transactional notifications, low-volume outbound mail tied to app events.

**How it's billed:** per email sent, after a monthly allowance. Hard bounces still count against the quota; sends to verified destination addresses in your own account are free and don't consume it.

<Table data={
    {
        headers: ['Dimension', 'Included (Workers Paid)', 'Overage'],
        rows: [
            ['Emails sent', '3,000 / month', '$0.35 per 1,000 emails'],
        ]
    }
} />

## Containers: a real Docker container, at real-infrastructure prices

[Cloudflare Containers](https://developers.cloudflare.com/containers/) let you run an actual Docker container at the edge, orchestrated from a Worker. It's useful when a workload genuinely needs a full OS process (a headless browser, a compiled binary, a long-running agent loop) rather than the constrained Workers runtime. It's the one product on this list that behaves like traditional infrastructure, and it's priced like it too.

**Good use cases:** sandboxed code execution, headless browser automation, anything that needs a real filesystem and process model Workers can't provide.

**How it's billed:** unlike everything else on this list, a container is metered on wall-clock time, not on work done. Memory, vCPU, and disk all accrue continuously while it's running, idle or not. The Workers Paid plan's $5 includes a modest allowance, after which a small always-on container runs to roughly **$30/month** before it has served a single request. That's VPS-shaped pricing, and worth comparing against an actual VPS.

<Table data={
    {
        headers: ['Dimension', 'Included (Workers Paid, $5/mo)', 'Overage'],
        rows: [
            ['Memory', '25 GiB-hours / month', '$0.0000025 per GiB-second'],
            ['vCPU', '375 vCPU-minutes / month', '$0.000020 per vCPU-second'],
            ['Disk', '200 GB-hours / month', '$0.00000007 per GB-second'],
        ]
    }
} />

## So when does Cloudflare actually make sense?

One point is worth stating plainly, because the free front door tends to obscure it: **past a certain scale, serverless on Cloudflare is almost always more expensive than a VPS you manage yourself.** That's not a knock on Cloudflare. It's the normal shape of serverless pricing anywhere. You're paying a premium per unit of work in exchange for not running servers, auto-scaling to zero, and being distributed across hundreds of edge locations by default.

That trade is worth it when:

- **Traffic is spiky or unpredictable.** You'd otherwise be paying for idle VPS capacity most of the time.
- **Global latency matters** and running your own multi-region fleet isn't realistic.
- **You're pre-product-market-fit** and the free tiers cover you entirely, genuinely free until real usage shows up.
- **The workload is naturally short-lived**, like a webhook handler, an API route or a redirect, where CPU time per request is milliseconds, not seconds.

It's worth a second look when:

- **Volume is large and steady.** A busy, predictable workload is the case where a $20-40/month VPS running Postgres and a web server will beat D1 + Workers + Durable Objects billed per-operation, often by a lot.
- **The workload is a persistent process**, not a request/response cycle. Containers exist for this, but at VPS-and-up pricing, not Workers pricing.

The other thing to understand before you build on any of this is what happens when the code driving these meters has a bug in it. Every service above bills on a dimension (rows written, GB-seconds, vCPU-seconds, emails) that a runaway loop can multiply by orders of magnitude without ever throwing an error. That's the subject of the [companion post](/blog/2026/10/09-the-vibe-coding-trap-how-ai-written-code-turns-into-a-five-figure-cloud-bill/), which walks through what those bills actually looked like for the people who got them.

## References

- [D1 pricing](https://developers.cloudflare.com/d1/platform/pricing/), Cloudflare Developer Docs
- [Durable Objects pricing](https://developers.cloudflare.com/durable-objects/platform/pricing/), Cloudflare Developer Docs
- [Workers pricing](https://developers.cloudflare.com/workers/platform/pricing/), Cloudflare Developer Docs
- [Email Service (Email Sending) pricing](https://developers.cloudflare.com/email-service/platform/pricing/), Cloudflare Developer Docs
- [Containers pricing](https://developers.cloudflare.com/containers/pricing/), Cloudflare Developer Docs

*Prices current as of October 2026 and sourced directly from Cloudflare's own documentation. Always check the live pricing page before budgeting, since cloud providers change these numbers without much notice.*


d929424c1dcaf173f095ba851c8742134352b25c62c457842e4ccadb48c8e8c0

What Cloudflare D1, Durable Objects, Workers, Email Sending, and Containers actually do, realistic use cases for each, and their current official pricing, verified against Cloudflare's own documentation.

A practical look at five Cloudflare developer products (D1, Durable Objects, Workers, Email Sending, and Containers): what each is for, when it earns its place, and what it actually costs according to Cloudflare's current price sheet.

Cloudflare's Developer Platform: Services, Use Cases, and Real Pricing

{/* banner prompt: A clean isometric scene on a light gray background, showing a user at a minimalist desk connected by a simple, glowing data stream to a small, elegant cloud block which then connects to a stylized globe, while a large, outdated server rack sits far in the background, featuring a soft pastel color palette and crisp shadows, 16:9. */}

We all need freedom of information access and privacy protection. It's just a fact of modern digital life. When direct access isn't available, we need alternative routes. The go-to solution? VPNs. But what if I told you there's a lighter, faster way?

## The VPN Struggle Is Real

People visiting certain countries absolutely need VPNs; they open up the world of communication. Sometimes folks use them just to pretend they're residents of a particular country. Look, I won't judge your reasons.

Traditional VPN setups are often quite complicated. Old legacy protocols aren't supported on newer systems anymore. And there are so many protocols to choose from it'll make your head spin.

For my own practice, I initially used WireGuard. The configuration is really easy, and if you're having trouble setting it up, you can simply ask any AI agent. They'll be able to set it up for you without breaking a sweat.

## The VPN Downside Nobody Talks About

Here's the thing though: the entire VPN setup is heavy. You need to buy or rent a VPS. We've got wide selections to choose from: Google Cloud, AWS, Microsoft Azure, Digital Ocean, Hetzner, Linode, Liquid Web, OVHcloud. The list goes on.

The big three cloud providers offer pay-as-you-go pricing. They charge based on hours you use, which is good. You can leave the VPN server running 24/7, so whenever you need your VPN service, you have it straightaway. Multi-platform support is there too.

But here's the kicker: for those who don't really need the VPN server running 24/7, the VPN approach isn't particularly ideal. The speed for access isn't great either. You're routing everything through another server, after all.

## What If There Was a Better Way?

Do we have a better choice? Something that's light and simple? Something that runs only when we need it? We don't have to start the VPN server, stop the server, and we certainly don't have to maintain another server, let alone deal with all those configurations.

Turns out, yes. Google Cloud Run is advertised as:

> Run frontend and backend services, batch jobs, host LLMs, and queue processing workloads without the need to manage infrastructure.

The sweet part? You get two million requests free per month.

## Enter the Serverless Web Proxy

Here's what caught my attention: You can write code using your favorite language, framework, and libraries. Package it up as a container, run `gcloud run deploy`, and your app will be live, provided with everything it needs to run in production.

Building a container is completely optional too. If you're using Go, Node.js, Python, Java, .NET Core, or Ruby, you can use the source-based deployment option that builds the container for you.

So I tested running a web proxy with Cloud Run. And it works. But here's the amazing part: the website viewing speed felt faster with Cloud Run than with a traditional VPN.

## The Technical Setup

I put all the necessary code on GitHub: [https://github.com/e-tang/web-proxy-with-google-cloud-run](https://github.com/e-tang/web-proxy-with-google-cloud-run)

You can just deploy and use it. If you have issues running it, just ask an AI agent to help: Gemini, Codex, Claude, they've all got your back.

### The Catch Nobody Warns You About

Here's where it gets interesting. My first instinct was to run Squid, a classic, battle-tested forward proxy, inside a Cloud Run container. Simple, right? Wrong.

Cloud Run sits behind Google's Front End (GFE), a global load balancer that terminates all TLS connections before traffic reaches your container. And GFE is strict: it does not forward standard proxy protocols to your container.

Specifically:
- **HTTP forward proxy requests** use an absolute URL in the request line (e.g. `GET http://example.com/ HTTP/1.1`). GFE sees these and returns 404 before Squid ever gets a look in.
- **HTTPS tunneling** requires a `CONNECT` method. GFE also blocks `CONNECT` entirely.

So a traditional proxy container on Cloud Run is dead on arrival. The GFE is doing its job; it's just not the job we needed.

### The Workaround: A Fetch Service

The solution is to stop pretending Cloud Run is a proxy server, and instead treat it as a fetch service. Instead of sending proxy-style requests, the client sends a normal `POST /` with a custom header:

```
X-Proxy-Url: https://the-actual-destination.com/path
```

GFE happily forwards this to the container. The container fetches the real URL using its own outbound connection and streams the response back. Simple, and it actually works.

### Two-Part Architecture

This means you need two pieces: the Cloud Run service, and something local to translate your browser's normal proxy requests into those fetch-service calls.

That local piece is [mitmproxy](https://mitmproxy.org/). It runs on your machine, intercepts browser traffic, decrypts HTTPS, and redirects each request to Cloud Run, all transparently. Your browser just thinks it's talking to a normal HTTP proxy on `localhost:8082`.

### Quick Deployment Steps

First, clone the repository:

```bash
git clone https://github.com/e-tang/web-proxy-with-google-cloud-run.git
cd web-proxy-with-google-cloud-run
```

Then deploy to Cloud Run (swap in your own project and region):

```bash
cd proxy

gcloud builds submit \
  --tag REGION-docker.pkg.dev/PROJECT_ID/REPO/IMAGE:latest \
  --gcs-source-staging-dir gs://YOUR_BUILD_BUCKET/source .

gcloud run deploy web-proxy \
  --image REGION-docker.pkg.dev/PROJECT_ID/REPO/IMAGE:latest \
  --region asia-southeast1 \
  --timeout 3600 \
  --concurrency 80
```

Start the local proxy:

```bash
pip install mitmproxy
mitmdump -p 8082 --set http2=false -s local/fetch_proxy_addon.py
```

That's it. Seriously.

## Why This Approach Wins

### Cost Efficiency
You're not paying for a server that's running 24/7. Cloud Run charges you only when requests are being processed. For occasional use, this is way more economical than keeping a VPS running.

### Speed
The performance was genuinely surprising. Google's infrastructure is optimized for this kind of workload. The cold start times are minimal, and once it's warm, it's lightning fast.

### Zero Maintenance
No server updates. No security patches. No monitoring disk space or memory usage. Google handles all of that infrastructure headache for you.

### Scalability
If you suddenly need to handle more traffic, Cloud Run scales automatically. Try doing that with your single VPS.

## Real-World Use Cases

### Bypassing Geo-restrictions
Deploy your proxy in different Cloud Run regions to access content from various geographical locations. Much simpler than managing multiple VPS instances.

### Development Testing
Need to test how your app behaves from different locations? Spin up a proxy in seconds rather than configuring a full VPN setup.

### Privacy-Conscious Browsing
For occasional private browsing needs, this serverless approach gives you the privacy benefits without the overhead of a full VPN infrastructure.

## The Code Behind the Magic

The Cloud Run service is a small Python/Flask app. It reads the `X-Proxy-Url` header, fetches the target, and streams the response back:

```python
# proxy/main.py (Cloud Run)
import os, requests
from flask import Flask, request, Response, stream_with_context

app = Flask(__name__)

# Strip these to avoid encoding and connection issues
SKIP_REQ  = frozenset(['host', 'x-proxy-url', 'accept-encoding', 'connection', ...])
SKIP_RESP = frozenset(['transfer-encoding', 'connection', 'content-encoding'])

@app.route('/', defaults={'path': ''}, methods=['GET','POST','PUT','DELETE','HEAD','OPTIONS','PATCH'])
@app.route('/<path:path>', methods=['GET','POST','PUT','DELETE','HEAD','OPTIONS','PATCH'])
def proxy(path=''):
    target = request.headers.get('X-Proxy-Url')
    if not target:
        return 'Missing X-Proxy-Url header', 400

    headers = {k: v for k, v in request.headers.items() if k.lower() not in SKIP_REQ}
    up = requests.request(request.method, target, headers=headers,
                          data=request.get_data(), stream=True, timeout=60)

    resp_headers = {k: v for k, v in up.headers.items() if k.lower() not in SKIP_RESP}
    return Response(stream_with_context(up.iter_content(chunk_size=65536)),
                    status=up.status_code, headers=resp_headers)
```

The local mitmproxy addon intercepts browser requests and redirects them to Cloud Run. Critically, it sets `flow.response.stream = True` so responses pipe directly to the browser with no intermediate buffering:

```python
# local/fetch_proxy_addon.py (runs on your machine)
from mitmproxy import http

CLOUD_RUN_HOST = "your-service.asia-southeast1.run.app"

class FetchProxy:
    def request(self, flow: http.HTTPFlow):
        original_url = flow.request.pretty_url   # save before we mutate

        flow.request.headers["X-Proxy-Url"] = original_url
        flow.request.headers["Host"] = CLOUD_RUN_HOST
        flow.request.host   = CLOUD_RUN_HOST
        flow.request.port   = 443
        flow.request.scheme = "https"
        flow.request.path   = "/"

    def responseheaders(self, flow: http.HTTPFlow):
        if flow.response:
            flow.response.stream = True   # no buffering — vital for video

addons = [FetchProxy()]
```

One non-obvious thing: `Accept-Encoding` must be stripped from outgoing requests. If you leave it in, servers may respond with Brotli-compressed content (`br`). Python's `requests` library only auto-decompresses gzip, so Brotli bytes pass through raw, and since we also strip the `Content-Encoding` response header, the browser receives binary garbage with no idea it needs decompressing. Stripping `Accept-Encoding` sidesteps the whole mess by asking servers to respond uncompressed.

## How Does It Handle Video?

This was my biggest concern. Browsing static pages is one thing; video is a different beast. Streaming video makes continuous byte-range requests, and any buffering or latency compounds badly.

The first version of the addon buffered every response completely before sending anything to the browser. For a page that returns 50 KB, that's imperceptible. For a video segment that might be several megabytes, that means a blank player until the entire segment has been downloaded to Cloud Run *and* transferred to your machine. Unacceptable.

The fix is the `flow.response.stream = True` line in the mitmproxy addon above. Once that's in place, mitmproxy stops collecting the response and starts piping bytes as they arrive. The browser sees a steady stream of data from the moment Cloud Run starts receiving it from the video server.

**Measured throughput routing through Singapore (asia-southeast1):**

```
File size : 10 MB
Transfer  : 1.85 MB/s  (≈ 15 Mbps)
Time      : 5.7 seconds
```

For context, common video bitrates:
- 720p streaming: ~2.5 Mbps
- 1080p streaming: ~5–8 Mbps
- 4K streaming: ~15–25 Mbps

So 15 Mbps comfortably handles 1080p, and sits right at the threshold for 4K. In practice, video sites also use adaptive bitrate streaming, where the player starts at a lower quality and ramps up as it builds a buffer, so the experience is smooth even if your connection varies.

## Limitations to Consider

Don't get me wrong: this isn't a silver bullet. There are some trade-offs:

- **Cold starts**: Cloud Run scales to zero when idle. The first request after a period of inactivity takes an extra second or two while the container starts up. Subsequent requests are fast.
- **HTTP/HTTPS only**: This handles web traffic beautifully. It won't tunnel arbitrary protocols the way a VPN does: no SMTP, no game servers, no BitTorrent.
- **Video site API calls**: Some video platforms make signed POST requests from JavaScript (login state, recommendations, view tracking). These can return 403 because the request appears to originate from a Cloud Run IP rather than a residential browser. The actual video segments, which carry URL tokens, load fine. This is a minor annoyance rather than a showstopper.
- **mitmproxy must be running locally**: Unlike a VPN that runs at the OS level and captures all traffic, this requires mitmproxy to be active. It also requires trusting its CA certificate so it can decrypt HTTPS, a reasonable trade-off for what you get.
- **Session persistence**: You're not maintaining a persistent tunnel. Each request is independent, which is actually a feature for performance but means this doesn't behave like a VPN at the network layer.

## When to Choose What

Use a traditional VPN when:
- You need persistent connection for all traffic
- You're doing heavy, continuous browsing
- You need support for non-HTTP protocols

Use the serverless proxy when:
- You need occasional access
- Cost is a primary concern
- You want zero maintenance overhead
- Speed and reliability are priorities

The serverless web proxy approach isn't trying to replace VPNs entirely. It's offering a different solution for a specific set of needs. And for those needs, it works brilliantly.

Sometimes the best solution isn't the most comprehensive one. It's the one that solves your actual problem with the least friction. For lightweight privacy and access needs, Cloud Run delivers exactly that.

d869598cdb7d75a5c2f85a95de090eea8433007bf3d4ff629981ac6cad333242

Learn how to build a faster, cheaper alternative to traditional VPNs using Google Cloud Run's serverless architecture for web proxy deployment.

Ditch complex VPN setups for a lightweight serverless web proxy using Google Cloud Run

Tag: Serverless

Tag: Serverless

Cloudflare's Developer Platform: Services, Use Cases, and Real Pricing

Serverless Web Proxy on Cloud Run: A Better VPN?