{/* banner prompt: A bright, slightly surreal editorial illustration of a cheerful robot hand confidently stacking a tower of building blocks on a table, unaware that the tower has quietly grown through the ceiling into the clouds above, with a single warning light blinking at the very top, clean flat-illustration style, warm cream and amber palette, soft shadows, 16:9. */}
Vibe coding is the trend of the moment, and for good reason. AI has knocked down the barrier that used to separate "has an idea" from "can ship software," and people who have never written a line of code are deploying working services. And it isn't only beginners: plenty of experienced developers have largely stopped hand-writing code altogether, because the frontier models are simply good enough that describing the change is faster than typing it.

The barrier that came down, though, wasn't only a barrier to *writing* code. It was also the thing that used to force you to understand what you were writing. Vibe coding collapses the distance between "I have an idea" and "it's running," and the part it quietly removes is where you'd normally stop and ask *how often does this run, and what does each run cost?* An AI model writing your polling loop or your alarm handler has no idea what pricing plan you're on. It optimizes for "this satisfies the prompt," not "this is cheap to operate at scale."

What follows is three real stories of AI-written code that shipped with a correctness bug which was also, quietly, a cost bug, and nobody noticed until the invoice did the noticing for them. Our [companion post](/blog/2026/10/09-cloudflares-developer-platform-services-use-cases-and-real-pricing/) covers what Cloudflare's D1, Durable Objects, Workers, Email Sending, and Containers actually cost; this one is about what happens when the code driving those meters is wrong.

## Lesson 1: the alarm that never stopped alarming

A Cloudflare user, [@shmily7](https://x.com/shmily7/status/2107481028726251762), described it bluntly in a post that's since been seen nearly half a million times: *"遭遇Cloudflare帐单刺客，爆了一万刀的帐单，原因是一个项目 Durable Object alarm 死循环，读写了6万亿次，Vibe Coding误我"*. Translated: hit by a Cloudflare "billing assassin," a $10,000 bill, caused by a Durable Object alarm stuck in a dead loop that read and wrote **6 trillion times**. Their own verdict: vibe coding did them wrong.

![@shmily7's post reporting a $10,000 Cloudflare bill caused by a Durable Object alarm stuck in a dead loop](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/10/the-vibe-coding-trap-how-ai-written-code-turns-into-a-five-figure-cloud-bill/durable-object-alarm-10k-bill.png)

*(X's automatic translation renders 6万亿 as "60 trillion"; the Chinese figure is 6 trillion. Either way, the point stands.)*

[Durable Object alarms](https://developers.cloudflare.com/durable-objects/api/alarms/) are a single callback, `alarm()`, that Cloudflare invokes once at a time you set with `setAlarm()`. The pattern for a recurring job is to call `setAlarm()` *again* at the end of your own handler to schedule the next run. That's also exactly where the bug lives: if the rescheduling math is wrong (a delay of `0`, a timestamp computed in the past, an error path that retries immediately instead of backing off) the alarm fires again the instant it finishes, forever, and each firing bills as a request plus duration plus whatever it reads or writes. At six trillion operations, even the included free quota's rounding error is a five-figure invoice. The logic a careful engineer would write defensively (minimum delay, a sanity check on the computed next-run time, an exponential backoff on error) is exactly the kind of unglamorous edge-case handling that a quick vibe-coded prompt tends to skip, because the happy path, "alarm fires, does work, schedules next one," looks completely correct in a two-minute test.

## Lesson 2: the poller that never waited

[@keking99](https://x.com/keking99/status/2106687001810677911) built a DeepSeek voting station with [GPT-6 Astra](https://openai.com/index/gpt-6-astra/), OpenAI's frontier model, released barely a month earlier, "in just a few sentences," and got a $1,000 Cloudflare bill for the month. The description of the bug is the most useful part, so here it is in X's own translation:

> I wanted you to display the vote count in real time, and you give me this thing that polls api/result every 3 seconds as long as the webpage is open, infinite querying, right? The request volume alone hit 2.6 billion times, you can make such a basic mistake? Now you see the consequences of blindly vibing without looking at the code, huh. Boomerang to the back of the head.

![@keking99's post describing a $1,000 Cloudflare bill after an AI-generated page polled an API every three seconds, reaching 2.6 billion requests](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/10/the-vibe-coding-trap-how-ai-written-code-turns-into-a-five-figure-cloud-bill/astra-polling-1k-bill.png)

It's worth sitting with the fact that this was not some budget model cutting corners. Astra was the most capable thing OpenAI had shipped, posting near-perfect scores on reasoning benchmarks, and it still produced this. That's the uncomfortable part: **capability and cost-awareness are different properties**, and no amount of the former delivers the latter. The model wasn't asked what the code would cost to run, so it didn't consider it. Nor will it, however good it gets, because "correct" and "cheap to operate at scale" are separate questions and only one of them was in the prompt.

Note too that what it produced isn't stupid. It's *reasonable-looking*. Asked for a live-updating vote count, it reached for the most obvious implementation: poll the result endpoint every three seconds. On one open tab that's 1,200 requests an hour, which is fine. The part nobody costed is that it runs *per open page, for as long as that page is open*, across every visitor, and a voting page is precisely the kind of thing people leave open. Multiply a reasonable-looking interval by an audience and a duration and you arrive at 2.6 billion requests without any single decision ever looking wrong.

That's the second, more common shape of this failure: not an infinite loop, just an interval nobody multiplied out. A `setInterval`, a `while (true)` with a `fetch()` and an undersized `sleep`, a retry with no backoff. Each looks like working code, and none look dangerous in a two-minute test, because a human tester doesn't leave the tab open for a week. The AI that wrote it never ran it at all.

## Lesson 3: when the "fully managed" database costs more than the server you didn't want to run

This one's ours, and it's not a Cloudflare story, which is the point. We used Google App Engine with Datastore to log machine/operation records: every command execution, every status check, written as a document. It felt like the right call: fully managed, no server to patch, scales automatically. The bill for database *operations alone* came to roughly **$300**, comfortably more than it would have cost to run our own MySQL or Postgres instance and handle the same write volume ourselves.

The mechanism is the same shape as the other two, just slower-burning: a pay-per-operation managed store (Datastore, Firestore, DynamoDB, D1, Durable Objects storage; the specific product doesn't matter) charges per read and per write, while a self-hosted relational database on a flat-rate VM charges the same whether you run a thousand queries a day or a hundred million. Below some volume, managed-and-metered wins easily. Above it, the per-operation meter quietly overtakes a box you could have rented for $20/month. Nobody sat down and did that napkin math before wiring up the logging. It just seemed like the "serverless-native" choice, which is exactly the trap: convenience at prototype time doesn't come with a label telling you where the crossover point is.

## The pattern underneath all three

Different clouds, different products, same shape of mistake:

- Code that is **functionally correct**, in that it does the thing it's supposed to do, while being **economically unbounded**, because nothing in the code or the review caps how many times, how fast, or how expensively it can run.
- A happy-path test that looks fine, because happy-path tests don't run for a month unattended or process a table that's grown 100x since launch.
- A review step that used to happen almost for free, as a side effect of how slow writing code by hand used to be, that vibe coding genuinely removes. You can now ship in the time it used to take to *plan*, which is great, except planning was also when "how often does this run?" used to get asked.

None of this is an argument against AI-assisted coding. It's an argument for putting the review back in deliberately, since it no longer happens automatically as a side effect of friction.

## Where it bites, service by service

Staying with Cloudflare for a moment, since it's the platform in two of the three stories: each of its metered services has a characteristic way of turning a small coding mistake into a large number. The [companion post](/blog/2026/10/09-cloudflares-developer-platform-services-use-cases-and-real-pricing/) has the full price sheet; this is what goes wrong against it.

- **D1** bills per *row*, not per query, and writes cost roughly 1,000x what reads cost. An `UPDATE` that touches every row in a growing table, run on every request, scales its cost with table size. It's cheap in testing against 50 rows and ruinous at a million. This is the one that cost the thread's author over a thousand dollars.
- **Durable Objects** run three meters at once: requests, duration in GB-seconds, and D1-rate storage for anything persisted. An alarm handler that both reschedules itself and writes state on every tick is spinning all three, which is why a bad reschedule compounds so fast.
- **Workers** bill CPU time separately from requests. A tight loop, an unbounded recursive parse, or synchronous crypto on a large payload can burn seconds of CPU per call instead of milliseconds. The guard here is cheap and almost always skipped: set `limits.cpu_ms` in `wrangler.toml` and a runaway request gets killed rather than billed to completion.
- **Email Sending** isn't a runaway-loop risk so much as an **abuse** surface. A magic-link or signup endpoint with no rate limiting is a free way for bots to make you pay per attempt. The thread's author was seeing several dollars a day from bots hammering a signup form, which is a rounding error right up until it isn't.
- **Containers** meter on wall-clock time whether or not they're doing anything. The trap is assuming the $5/month Workers Paid plan covers it; a small always-on container runs to roughly $30/month having served no traffic at all. Several people got caught by this after a Cloudflare demo made it look like a $5 add-on.

## What to check before you ship vibe-coded infrastructure code

- **Every loop, retry, reschedule, or alarm:** what's the exit condition, and what happens on the path where that condition is never met? Walk the failure branch, not just the success branch.
- **Every poller:** is there a minimum interval, a backoff on failure, and a cache so a quiet period doesn't mean a constant stream of identical calls?
- **Every write inside a request handler or a loop:** does its cost scale with table size, request volume, or iteration count? If yes, what's the worst case, not the typical case?
- **Usage alerts configured before the first deploy**, not after the first scary invoice. On Cloudflare that's the Usage Based Billing Alert (Pro plan and above, pay-as-you-go accounts); most providers have an equivalent. Turn it on before you need it.
- **`limits.cpu_ms` set in `wrangler.toml`** if you're on Workers. Cloudflare's own docs pitch it exactly this way, to prevent "accidental runaway bills or denial-of-wallet attacks."
- **A back-of-envelope cost estimate** for anything that talks to a pay-per-operation service: expected operations per day times the unit price, compared honestly against what a flat-rate self-hosted alternative would cost at the same volume.

## The other half: platforms could meet us halfway

Everything above is the developer's job, and none of these were exotic bugs. An alarm that reschedules itself too eagerly and a poller with no throttle are rookie mistakes, and owning them is part of shipping software. But "don't write bugs" has never been a workable safety strategy, because *all* code has bugs. That's precisely why we have type checkers, linters, circuit breakers, and rate limits: we assume the mistake will happen and build something that catches it.

Cloud billing is conspicuously missing that layer. The controls that exist are weak in a specific way:

- **Alerts notify; they don't stop anything.** A usage alert tells you the meter is spinning. If it fires at 2am on a Saturday, the meter keeps spinning until you wake up and act. The one mechanism that actually *stops* work, `limits.cpu_ms`, caps a single invocation, and every incident described above was unbounded *invocation count*, not one expensive call. Nothing capped that.
- **There's no hard spend ceiling.** You cannot tell Cloudflare "whatever happens, never bill me more than $100 this month, and shut it down if we get there." For a hobby project or a small business site, that's the single control that would matter most, and the inability to set it is why a weekend project can generate a mortgage payment.

And this is plainly solvable, because other providers already solve it. **Vercel** has Spend Management: you set an on-demand budget, and with *Pause Production Deployments* enabled it automatically pauses every project on the team when you hit it, so visitors get a 503 rather than you getting a surprise invoice. **Google Cloud** documents a budget-triggered function that removes the billing account from a project outright, shutting the whole thing down. Neither is elegant, and both ship with honest caveats: Vercel checks spend "every few minutes," so pausing isn't instantaneous, and Google states flatly that its approach "doesn't guarantee that you won't spend more than your budget."

Those caveats are usually where the argument against spend limits starts: metering is distributed, usage data arrives late, an exact cap is genuinely hard. All true, and all beside the point. A cap that overshoots by a few minutes turns a $10,000 incident into a $20 one. Nobody asking for a spend limit expects it to be accurate to the cent; they want the runaway to stop while it's still a rounding error. "We can't make it exact" is not a reason to offer nothing, and the existence of imperfect-but-real implementations elsewhere makes it a product decision rather than a technical impossibility.

And the anomaly here was not subtle. A site with a handful of users does not legitimately generate six trillion database operations, or 2.6 billion API calls. Against its own baseline, that traffic is self-evidently broken, and the platform is in a far better position to see it than the developer is, because the platform is the thing counting. It has the traffic history, it knows the account's normal range, and it is already doing real-time analysis on every request for security purposes. A provider that can detect and mitigate a DDoS in seconds can notice that a free-tier-sized project has started writing a billion rows an hour.

None of this excuses shipping the bug. But there's a reasonable expectation that the party holding the meter, watching the traffic, and writing the invoice should be the one to say "this looks wrong, we've paused it," rather than quietly counting to six trillion and sending a bill. Until that exists, the burden sits entirely on the developer, which is exactly the wrong place for it when the tooling has made it so easy for non-specialists to deploy code they don't fully understand.

## References

- [@shmily7 on X](https://x.com/shmily7/status/2107481028726251762), the $10,000 Durable Objects alarm bill
- [@keking99 on X](https://x.com/keking99/status/2106687001810677911), the $1,000 bill from a three-second polling loop
- [GPT-6 Astra](https://openai.com/index/gpt-6-astra/), OpenAI, the model that wrote the polling loop
- [@mcwangcn on X](https://x.com/mcwangcn/status/2107106092509696292), a thread cataloguing Cloudflare billing traps, including a passing mention of @keking99's requests-driven bill
- [Durable Objects alarms API](https://developers.cloudflare.com/durable-objects/api/alarms/), Cloudflare Developer Docs
- [Workers pricing](https://developers.cloudflare.com/workers/platform/pricing/), Cloudflare Developer Docs, source of the `limits.cpu_ms` guidance on runaway bills
- [Available notifications](https://developers.cloudflare.com/notifications/notification-available/), Cloudflare Developer Docs, covering the Usage Based Billing Alert and its plan restrictions
- [Spend Management](https://vercel.com/docs/spend-management), Vercel Docs, on budget-triggered pausing of production deployments
- [Disable billing with notifications](https://cloud.google.com/billing/docs/how-to/disable-billing-with-notifications), Google Cloud Docs, on budget-triggered shutdown and its limitations

*Want the actual price sheet behind why these bugs got so expensive? See the [companion post](/blog/2026/10/09-cloudflares-developer-platform-services-use-cases-and-real-pricing/) on what Cloudflare's developer platform costs, service by service.*


5a1a27e516d5fb3e25bf20c0975580197c06da0100e4211d7d2bcf4593e2f6c0

Three real-world stories of AI-generated code causing runaway cloud bills (a Durable Objects alarm loop, an unthrottled polling plugin, and an over-logged Datastore), plus what to check before you ship vibe-coded infrastructure.

Vibe coding makes it trivially easy to ship something that works, and just as easy to skip the review that would have caught a runaway loop, an unthrottled poller, or a chatty logging table. Three real bills, three different clouds, one lesson.

The Vibe-Coding Trap: How AI-Written Code Turns Into a Five-Figure Cloud Bill

{/* 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 minimal Scandinavian-style office scene with soft, natural light from a window; on a clean light oak desk, an elegant metal padlock and a small white block with a Google Cloud logo are physically separated by a translucent orange glass cube, creating a sense of a clear, frustrating obstacle.

Additional instructions: an unitree style robot as a runner */}

# From App Engine to Cloud Run: A New Chapter

For a long time, Google App Engine (GAE) has been my go-to for hosting web applications. It’s reliable and handles the heavy lifting of infrastructure. However, Google’s **Cloud Run** has emerged as a compelling successor that promises even better cost efficiency and flexibility.

## What is Cloud Run?

Cloud Run is a fully managed compute platform that automatically scales your stateless containers. Unlike App Engine, which has specific language runtimes, Cloud Run allows you to run **any** language, library, or binary because it is built on the **Knative** (Kubernetes-based) standard.

### Benefits vs. App Engine

1.  **Scale to Zero:** Cloud Run is truly "pay-as-you-go." If no one is using your app, it scales to zero instances, and you pay $0. App Engine's standard environment does this too, but Cloud Run's pricing model is often more granular and cheaper for low-to-medium traffic.
2.  **Containerization:** Since it uses Docker containers, the "it works on my machine" guarantee is much stronger. No more worrying about App Engine-specific constraints or proprietary APIs.
3.  **Concurrency:** A single Cloud Run instance can handle up to 250 requests simultaneously, whereas App Engine instances are often more restricted in how they handle concurrent loads.

## Why the "Trading Journal" Project?

For a project like a **Trading Journal**, Cloud Run is a perfect fit:
*   **Cost Efficiency:** This trading tool is built for a small audience and may get very few visitors, if any. Cloud Run is a good fit because it can scale to zero when nobody is using it, keeping the monthly cost minimal.
*   **Fast Iteration:** If this tool ever evolves, the container-based workflow will make it easier to roll out new calculation logic or UI improvements.
*   **Portability:** If we ever need to move to a full Kubernetes cluster or another cloud provider, the Docker image is already built and ready.

---

# The "Gotcha": Domain Mapping & The 24-Hour Wait

After successfully deploying the Trading Journal to Cloud Run, I hit a major roadblock: **Domain Mapping.** 

I mapped [`sprolo.tyosis.com`](sprolo.tyosis.com) to the service, and then... nothing. I waited 24 hours, and the status remained stuck on **"Waiting for certificate provisioning."**

### How it works under the hood
Cloud Run uses a Kubernetes-based technology stack. The domain mapping service behaves similarly to a **Certbot** container. To provide you with a managed SSL certificate, Google must prove to the Certificate Authority (CA) that it controls your domain. It does this via an ACME challenge: the CA looks for a specific token at your domain's IP address.

### Why the mapping failed
The issue was **Cloudflare**. My domain was using Cloudflare's "Proxy" mode (the Orange Cloud). 

When Google's verification bot tried to check the domain, it didn't see the Google servers; it saw **Cloudflare's edge nodes**. Because Cloudflare was hiding the actual IP from the internet, the authentication and validation process could never finish. Google was effectively shouting into a void, waiting for a challenge response that Cloudflare was intercepting.

### The Fix: The "Grey Cloud" Strategy

To solve this, you have to temporarily "step out of the way" of the SSL handshake:

1.  **Grey Cloud the Record:** In Cloudflare DNS, change the `sprolo` CNAME record from "Proxied" to **"DNS Only"** (Grey Cloud). This exposes the `ghs.googlehosted.com` target directly to the public internet.
2.  **Wait for Google:** Once the proxy is off, Google's verification bot can see the challenge data. In my case, the "Ready" status appeared within about 20 minutes after being stuck for a day.
3.  **Re-enable Proxy:** After the Cloud Run domain status shows a green checkmark and "Ready," you can flip the Orange Cloud back on in Cloudflare to regain your CDN and security benefits.

### Summary
If you are moving to Cloud Run and use Cloudflare, don't wait 24 hours like I did. **Turn off the proxy until the certificate is issued.** Once Google has that initial validation, the routing works perfectly even when you turn the proxy back on.


ecfeee512d771830333c602faaecf4077cedfcb0c744b3d89aca01031ae9a0c1

A practical note on fixing a Cloud Run custom domain that stays stuck on 'Waiting for certificate provisioning' behind Cloudflare. Explains why orange-cloud proxying breaks validation and how switching the record to DNS-only lets the SSL certificate complete.

Cloud Run domain mapping can stay stuck on certificate provisioning when Cloudflare proxying blocks Google's SSL validation.

Tag: Cloudflare

Tag: Cloudflare

The Vibe-Coding Trap: How AI-Written Code Turns Into a Five-Figure Cloud Bill

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

Cloud Run Domain Mappings with Cloudflare: Why Your SSL is Stuck