Anthropic built its entire brand on being the responsible one. Founded by researchers who left OpenAI specifically to build a safer alternative, the company has spent years positioning itself as the AI lab that takes ethics seriously. So it's a little jarring to look at Cloudflare's traffic data and see Anthropic sitting at the very bottom of the pack when it comes to giving back to the web it depends on.Cloudflare sits in front of roughly a fifth of all internet traffic, which makes it one of the best vantage points anyone has for measuring how AI companies actually behave online. Its numbers tell a consistent story: Anthropic's bots crawl the web harder, relative to the traffic they send back, than almost anyone else building a major AI product.<h2>What the Crawl-to-Refer Ratio Actually Measures</h2>Cloudflare tracks something it calls the crawl-to-refer ratio. It's a simple idea. For every page a company's bots crawl, how many actual human visitors does that company send back to the site the content came from?A healthy ratio looks like traditional search. Google crawls a page, indexes it, and when someone searches for that topic, Google sends a real visitor to the site. That's roughly a 5:1 exchange right now, according to Cloudflare Radar. You let the crawler in, and it pays you back in clicks.<ad-spot></ad-spot>An AI answer engine works differently. It reads a page, absorbs what it needs, and then answers the user's question directly inside the chat window. The user gets what they came for and never clicks through. The site that supplied the answer gets a server bill and nothing else.<h2>Anthropic's Numbers, and Why They Keep Moving</h2>For the week of July 1 to 7, 2026, Cloudflare's data puts Anthropic's crawl-to-refer ratio at roughly 2,800:1. That means for every visitor Claude sends back to a publisher, its bots, ClaudeBot for training and Claude-SearchBot for live search, have already crawled around 2,800 pages.That 2,800:1 figure looks almost reassuring next to where Anthropic has been recently. In early April 2026, Cloudflare pegged the ratio at about 8,800:1. By the first week of May, it had spiked to roughly 24,700:1. Other trackers using slightly different methodology and time windows have put Anthropic's ratio anywhere from around 2,900:1 to over 11,000:1 in various weeks this spring and summer. The number swings wildly depending on the exact week you measure, largely because Anthropic's training crawler and its newer search crawler behave very differently, and the mix between them shifts constantly.A year ago, in January 2025, Anthropic's ratio reportedly sat above 280,000:1. It has come down by more than an order of magnitude since then, mostly because Claude's web search feature now adds clickable citations that occasionally send someone back to the source. But even on its best recent weeks, Anthropic remains the most extractive of the major AI labs by a wide margin.Here's the full picture, pulled directly from Cloudflare's AI Insights dashboard, for both a single week and a full month:<img src="https://cdn.calebms.com/articles/971abb81-2612-49ef-9ea0-faaaa6e09dbd.png" alt="91132.png" data-caption=""><img src="https://cdn.calebms.com/articles/9f02e5ad-4ad1-4e67-8b73-ea919b41049d.png" alt="91133.png" data-caption="">Anthropic isn't just worse than the field, it's in a different category entirely. Its closest competitor on this list, OpenAI, still refers traffic roughly eight to ten times more often than Anthropic does, and OpenAI itself sits well above everyone else beneath it. Perplexity, despite building its entire business around live web retrieval, refers at a rate over ten times better than Anthropic in both windows.<ad-spot></ad-spot>Microsoft, Yandex, and Baidu all sit in a fairly stable middle band, month to month, in the 10:1 to 35:1 range. These are companies running traditional search products (Bing, Yandex Search, Baidu Search) alongside AI features, and their ratios barely moved between June and July. That stability is itself informative: it suggests these ratios are not inherently volatile by nature. They move when the underlying business model is AI-answer-first rather than search-first, which is exactly what's driving Anthropic's swings.Google and DuckDuckGo anchor the bottom of the table, both holding close to the traditional search bargain: crawl a page, and reliably send a visitor back for it.<h2>Why the "Ethical" Company Crawls the Hardest</h2>Anthropic rolled out real-time web search for Claude to compete with ChatGPT and Perplexity. Building that feature without leaning entirely on a licensed index like Bing's means Claude's bots have to fetch fresh pages constantly to answer questions accurately. That drives crawl volume up sharply. At the same time, more than half of Anthropic's crawling, and AI crawling industry-wide, is still dedicated to training rather than live search. Training crawls never send anyone anywhere. They just feed the model.Put those two things together and you get exactly the pattern Cloudflare is measuring: heavy, constant crawling with a comparatively small trickle of referral traffic flowing back out.<h2>Two Very Different Definitions of "Ethical"</h2>When Anthropic describes itself as a safety-focused, ethical company, it means something specific by that. In AI alignment circles, ethics is about the model's behavior: not giving out bioweapon instructions, not generating hateful content, not confidently making up dangerous medical advice, and building in safeguards against a future system going rogue.But that framework has almost nothing to say about how the model got built in the first place. To a publisher, a freelance writer, or a small site owner, ethics means something closer to consent, credit, and some form of compensation. Those two definitions of "ethical AI" don't just fail to overlap much. In Anthropic's case, they can point in opposite directions at once. A company can build genuinely careful safety systems into its model while running one of the most extractive crawlers on the internet, and both of those things can be true simultaneously.<h2>The Old Deal Is Broken, and Everyone Knows It</h2>For three decades, the web ran on an implicit trade. You let search engines crawl your content, and in exchange, they sent you readers you could monetize through ads, subscriptions, or sales. It wasn't perfect, but it worked well enough to fund an entire industry of independent publishing.<ad-spot></ad-spot>Cloudflare's own research has found that over half of all AI crawler requests are purely for training, meaning the content gets absorbed permanently with no expectation of ever sending a visitor back. That's a fundamentally different relationship than the one search engines built with the web. The publisher still pays the hosting costs for every one of those crawl requests. They just don't get anything in return.Anthropic's usual defenses here are the same ones the rest of the industry leans on: training a model is comparable to a person reading widely and building expertise, the company respects robots.txt and doesn't hide its bots, and high-quality training data is genuinely necessary to keep the model from being useless or dangerous. Those arguments have some legal and technical merit, and courts are still actively working through how much of it holds up. But none of them really answer the publisher's actual complaint, which isn't about legality. It's about whether taking someone's work at scale, without payment or meaningful attribution, and then never sending them a reader again, counts as fair dealing.<h2>The Double Standard Gets Sharper With the Distillation Fight</h2>Anthropic has spent much of 2026 publicly accusing Chinese AI labs of stealing its work. In February, the company said it had caught DeepSeek, Moonshot AI, and MiniMax running coordinated campaigns, collectively generating more than 16 million exchanges with Claude through roughly 24,000 fake accounts, in an apparent effort to distill Claude's capabilities into cheaper competing models. In June, Anthropic escalated further, telling the Senate Banking Committee that operators linked to Alibaba's Qwen lab had run nearly 28.8 million exchanges through about 25,000 fraudulent accounts over a six-week period, using proxy services to get around geographic restrictions. Anthropic called it the largest distillation campaign it had ever detected, larger than the three prior campaigns combined, and framed it not just as IP theft but as a national security issue, warning that it lets foreign competitors strip away the safety guardrails Anthropic spent heavily to build.These are Anthropic's own figures and Anthropic's own attribution. Alibaba has not addressed the specifics publicly, and outside parties have not independently verified the numbers or confirmed the accounts are actually linked to Alibaba rather than some other operator. Distillation is genuinely hard to prove from outside a company's own logs, since the evidence is a pattern of API usage rather than anything more concrete.Even granting Anthropic's version of events at face value, the logic underneath it is nearly identical to the complaint publishers have about Anthropic itself. Both are, in essence, the same sentence: you used my expensive, hard-won output to build something that competes with me. A publisher spends years building an audience and a body of work, and ClaudeBot crawls it at scale to train a product that answers questions without ever sending a reader back. A Chinese lab allegedly runs millions of queries against Claude to build a cheaper model that competes with Claude. Anthropic calls the second one industrial-scale theft and takes it to the Senate. It calls the first one fair use.The legal distinction Anthropic draws is that its consumer terms of service explicitly prohibit using Claude's outputs to train competing models, while most publishers never had a contract with Anthropic at all, just an open website and, at best, a robots.txt file. That's a real legal difference. But it's a thin one to lean on when the underlying grievance, in both directions, is about who gets to profit from work they didn't do the hard part of creating.<ad-spot></ad-spot>I don't think Anthropic is uniquely villainous here. Every major AI lab is extracting value from the open web faster than it's returning any, and the industry-wide numbers make that plain. Google, the one company that has historically paid the web back through referral traffic, is itself under pressure as <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/google-broke-the-web-it-built-now-its-selling-you-the-pieces">AI Overviews</a> start keeping searchers on Google's own results pages instead of sending them onward.But I do think Anthropic's specific position deserves more scrutiny than it usually gets, precisely because the company has built so much of its public identity around being the safety-conscious, values-driven alternative to everyone else. Safety and fairness are not the same thing. A model can be carefully aligned against generating harmful content and still be built on a crawling strategy that most publishers would recognize as taking without asking. Anthropic gets to define which of those problems counts as "ethics" when it talks about its own product, and it has consistently chosen the framing that doesn't require paying anyone.The company has pushed back on Cloudflare's methodology, saying it can't independently verify how the ratios are calculated and that its newer search features are already sending more traffic back than the numbers suggest. That's a fair point to raise, and it's worth watching whether Anthropic's ratio keeps trending down as Claude's search product matures. Worth watching, but not yet resolved. As of the most recent data, Anthropic is still taking far more than it gives back, and it's still the loudest voice in Washington arguing that taking from Claude is a national security threat.

The "Ethical" AI Company Is the Internet's Biggest Taker: Inside Anthropic's Crawl-to-Refer Problem

A year ago, Cloudflare declared what it called Content Independence Day. The pitch was simple: website owners should get to decide whether AI companies could crawl their content, and if they said yes, they should get paid for it. It was a good idea that landed at a moment when publishers everywhere were watching AI chatbots quietly absorb their work with nothing coming back.On July 1, 2026, Cloudflare returned with<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.cloudflare.com/press/press-releases/2026/cloudflare-allows-the-agentic-internet-to-flourish-with-a-simple-philosophy-your-content-your-rules/"> year two of that pus</a>h. The announcement introduced a new classification system for web crawlers, a dashboard that shows publishers exactly how AI bots are using their content, and an evolution of last year's Pay Per Crawl feature into something called Pay Per Use. The headline change is a September 15, 2026 deadline for so called "mixed use" crawlers, bots that blend search indexing, AI training, and AI agent activity into a single pass. After that date, any crawler that refuses to separate those three purposes will be blocked by default on every page that carries ads, for new customers and for existing free tier customers who haven't changed their settings.<ad-spot></ad-spot>On paper, this looks like real progress. Cloudflare is naming a problem that publishers have complained about for two years: Google's crawler, in particular, mixes search indexing with the data collection that powers AI Overviews and Gemini, and site owners have had no clean way to accept one without accepting the other. Cloudflare's own numbers make the imbalance concrete. According to its published data, Google's ratio of pages crawled to human visitors referred back sits at roughly 14 to 1. OpenAI's sits at roughly 1,700 to 1. Anthropic's sits at roughly 73,000 to 1. Whatever bargain used to exist between crawler and website, it broke down for AI a long time ago, and Cloudflare is right to say so.But look closer at how Pay Per Use actually works, and a less flattering pattern shows up. This isn't a fix for the small publisher. It's a system that, as currently built, mostly works for the publisher who was already big enough to matter.<h2>How Pay Per Use Actually Creates Winners</h2>The mechanics matter here, so it's worth being precise about what changes and what doesn't.Blocking a mixed use crawler does not automatically generate income. It removes the free option. Whether a publisher then gets paid depends entirely on whether the AI company crawling their site has signed up to a Pay Per Use partnership with Cloudflare. As of this announcement, exactly two such partners exist: Ceramic.ai and You.com. Both are AI search products looking to build content relationships, and both are considerably smaller than the AI companies most publishers actually worry about. Neither OpenAI, Google, Anthropic, nor Perplexity has committed to this payment model yet.That gap matters more than it sounds like it should. A publisher who blocks mixed crawlers today is betting that the AI companies actually driving traffic and training value will eventually join a scheme that pays them. Until that happens, blocking a mixed crawler mostly means one thing: the publisher disappears from that crawler's index, gets no payment, and loses whatever search visibility that crawler used to provide.<ad-spot></ad-spot>Compare that to what's already happened in the licensing market that predates this announcement. Cloudflare notes that publishers have signed more than 50 major content licensing agreements over the past year. The names that keep coming up in coverage of these deals are the Associated Press, Time, The Atlantic, Reddit, and Getty Images. These are organizations with either enormous archives, legal departments built for negotiation, or both. When an AI company wants training data or citation rights badly enough to pay for it, it goes to the publisher whose content is irreplaceable or whose lawyers are expensive to ignore. It does not go looking for the mid sized regional tech blog with a loyal but modest readership, no matter how good that blog's reporting is.Cloudflare has built genuine infrastructure here: a marketplace, a classification system, an attribution dashboard. What it hasn't built is a reason for AI companies to seek out small publishers within that marketplace. Infrastructure without a redistribution mechanism just formalizes whatever leverage already existed before the infrastructure was built.<h2>The Small Publisher's Actual Dilemma</h2>This is where the announcement's real cost lands, and it's worth stating plainly because Cloudflare's press language never quite does.A smaller publisher now faces two doors, and neither one is good.Door one: allow mixed crawlers. Stay discoverable in search and in AI Overviews. Keep whatever referral traffic still trickles back. Continue getting scraped for AI training and agent use with no compensation, exactly as before this announcement, because "allow" was always the default that cost publishers nothing to accept and everything to enforce against.Door two: block mixed crawlers. Lose inclusion in Google Search and AI Overviews as a package deal, since Googlebot, Applebot, and Bing's crawler are all mixed use and will be treated according to the most restrictive rule a site sets. Wait, with no guarantee, for an AI company to decide your content is worth a direct licensing conversation. For most publishers outside the handful of major outlets already naming names in the coverage, that wait has no clear end date.A publisher like ours sits squarely in that second, harder position. We don't have AP's thirty year archive or Reddit's user generated data trove to negotiate with. What we have is original reporting on Kenyan and African tech, written by people who know the space. That's valuable to readers. Whether it's valuable enough to earn a bespoke Pay Per Use deal with an AI company that has never named a partner our size is a genuinely open question, and right now, Cloudflare's own framework doesn't answer it.This is the trade most coverage of the announcement has missed. The story isn't just "Google versus everyone else." It's "publishers with leverage versus publishers without it," and Cloudflare's new rules, however well intentioned, sit on top of that divide rather than closing it.<h2>This Isn't Necessarily Malicious, Just Structurally Biased</h2>It's worth being fair to Cloudflare here, because the alternative reading, that this is a deliberate scheme to help media giants at everyone else's expense, isn't quite right either.Cloudflare didn't choose which publishers get licensing deals. The AI companies did. Cloudflare built a marketplace and a set of controls; it's the AI companies deciding who to approach with money on the table. That's not unusual. Every licensing market in every industry defaults toward whoever has leverage first, whether that's music labels negotiating streaming rates or film studios negotiating with theater chains. Scale and legal weight have always bought better terms than a good product alone.<ad-spot></ad-spot>What's different here is the stakes. Publishers aren't just losing negotiating leverage in an established market. They're watching the terms of a brand new market get set before most of them even have a seat at the table, and the September 15 deadline compresses that timeline further. Cloudflare says it will spend the next two months gathering feedback before finalizing the defaults, which is the right instinct. Whether that feedback period actually changes anything for smaller publishers, or just refines the rules that already favor whoever showed up with a licensing deal in hand, is the thing worth watching over the next ten weeks.<h2>What Would Actually Fix This</h2>If the goal is genuinely a fairer web, and not just a better negotiating position for outlets that already had one, a few things would need to exist that don't yet.Collective bargaining for smaller publishers. Something closer to a syndication pool, where publishers below a certain scale can pool their content and negotiate as a bloc rather than individually. Getty built exactly this kind of leverage for photographers over decades. Nothing similar exists yet for independent digital publishers, though the demand clearly does.A mandatory minimum rate rather than pure negotiation. If Pay Per Use payments are set entirely by one on one deals between AI companies and individual publishers, small publishers will always lose that negotiation before it starts. A baseline per citation rate, set either by Cloudflare or by regulation, would give every publisher something rather than nothing while bigger deals still exist above that floor for outlets with genuine leverage.Regulatory pressure that doesn't wait for the market to sort itself out. The UK's move to force Google to let publishers opt out of AI search results without losing their regular search ranking is a useful precedent. It says, in effect, that publishers shouldn't have to accept a package deal just to stay visible. A similar principle applied to payment, some baseline compensation for citation regardless of publisher size, would do more for small publishers than any voluntary marketplace Cloudflare builds on its own.None of these exist today. Cloudflare has built the pipes. Nobody has yet built the part that makes sure water reaches every house on the street, not just the ones closest to the source.<h2>The Lock Without the Key</h2>Cloudflare gave every publisher, big or small, a lock for their front door. That's real, and it's more than existed before. But a lock only matters if there's something on the other side worth protecting, and a system that pays out only where an AI company has already decided to show up with a signed deal isn't compensation. It's a waiting room.For AP, Time, Reddit, and Getty, that waiting room has a door that opens. For most publishers, including outlets like ours, it's still just a room.The real test of whether this announcement changes anything won't be how many crawlers get blocked on September 15. It will be how many AI companies sign Pay Per Use deals with publishers nobody's heard of, not just the ones everybody already has.

Cloudflare Says It's Fixing the AI Web. Is It Just Rewarding the Publishers Who Already Won?

If you have ever set up transactional email for a web application, you know the ritual. Pick a provider — Mailgun, Postmark, SendGrid, Brevo. Create an account. Verify your domain by adding SPF, DKIM, and DMARC records one by one. Wait for DNS propagation. Submit your sending domain for review. Wait again. Hope your first emails do not land in spam while your sender reputation is building. Pay a monthly fee that scales uncomfortably with your user base.It is the most reliably tedious part of launching any application that sends email which is every application.Cloudflare wants to make the whole process as simple as adding a binding to a Worker and calling <code>send</code>.<h2>What Cloudflare Email Service Is</h2>Announced in September 2025 and currently in private beta, Cloudflare Email Service is a native transactional email capability built directly into Cloudflare Workers. No third-party SMTP relay. No separate API keys. No manual DNS record configuration. You declare an email binding in your Worker configuration, call <code>send</code>, and Cloudflare handles the rest including automatically configuring the SPF, DKIM, and DMARC records that tell receiving mail servers your emails are legitimate.<ad-spot></ad-spot>The code to send a transactional email from a Worker looks like this:<pre><code class="language-javascript">export default {
 async fetch(request, env, ctx) {
 await env.SEND_EMAIL.send({
 to: [{ email: "[email protected]" }],
 from: { email: "[email protected]", name: "Your App" },
 subject: "Welcome to Your App",
 text: "Thanks for signing up. Here is your confirmation link.",
 });

 return new Response("Email sent successfully");
 },
};
</code></pre>That is the entire implementation for a basic transactional email. No initialising an SDK, no managing API credentials, no handling SMTP connection errors. The binding is declared once in your <code>wrangler.jsonc</code>:<pre><code class="language-json">{
 "send_email": [
 {
 "name": "SEND_EMAIL"
 }
 ]
}
</code></pre>And from that point, <code>env.SEND_EMAIL.send()</code> is available anywhere in your Worker.<h2>This Is Different From What Workers Could Already Do</h2>It is worth being precise here because Cloudflare already had an email-related Workers feature, and the two are easily confused.What existed before: The <code>send_email</code> binding in Email Routing allowed a Worker to send emails to verified destination addresses — addresses you had already confirmed in your Cloudflare Email Routing setup. This was useful for internal notifications and alerts but had a hard limitation: you could only send to pre-verified addresses you controlled. You could not send a welcome email to a new user signing up to your app, because their address is not pre-verified in your Cloudflare dashboard.<ad-spot></ad-spot>What Cloudflare Email Service adds: The new Email Sending capability removes that restriction entirely. You can send to any email address — customers, users, anyone — making it a genuine transactional email service rather than just an internal notification tool. This is what replaces the need for Brevo, Mailgun, or Postmark.The screenshot below ( taken from the Cloudflare dashboard ) confirms the feature is now appearing for accounts, with a "Join the Waiting List" prompt under Email Sending (Beta). The button text "Already joined to the waiting list!" confirms waitlist access has been secured.<img src="https://cdn.calebms.com/articles/495f4479-9328-4fdd-8e14-5b50646ac937.jpg" alt="58287.jpg"><h2>React Email Works With It Out of the Box</h2>For developers already using React Email to build HTML email templates, the integration is straightforward. Cloudflare explicitly supports it:<pre><code class="language-javascript">import { render, pretty, toPlainText } from '@react-email/render';
import { WelcomeEmail } from './templates/WelcomeEmail';

export default {
 async fetch(request, env, ctx) {
 const html = await pretty(
 await render(&lt;WelcomeEmail userName="Wanjiru" /&gt;)
 );

 await env.SEND_EMAIL.send({
 to: [{ email: "[email protected]" }],
 from: { email: "[email protected]", name: "MyApp" },
 subject: "Welcome to MyApp",
 html,
 text: toPlainText(html),
 });

 return new Response("Welcome email sent");
 },
};
</code></pre>Your existing React Email templates (the ones you may have been rendering and passing to Brevo or Resend ) port directly. No template rewriting required.<h2>The Full Picture: Inbound and Outbound Together</h2>What makes Cloudflare's approach genuinely different from a standalone email API is the combination of inbound and outbound in a single platform.Email Routing ( Cloudflare's existing free inbound email product ) lets you receive emails at custom addresses on your domain and process them in a Worker. Email Sending now closes the loop on the outbound side. Together, they enable workflows that previously required stitching together multiple services:Support ticket automation: A user emails <code>[email protected]</code>. A Worker receives it via Email Routing, parses the content, creates a ticket in your system, and uses Email Sending to reply with a ticket confirmation, all within one Worker, with no external services involved.Order notifications: A payment webhook triggers a Worker, which sends an order confirmation email via Email Sending and simultaneously logs the transaction to R2. No Brevo integration, no SendGrid webhook, no third-party dependency.<ad-spot></ad-spot>AI-powered email processing: A Worker receives an email, runs it through Workers AI for classification or summarisation, then uses Email Sending to route the response or trigger follow-up actions. Cloudflare's own blog gives the example of flagging security events, summarising support requests, and generating automatic responses, all within the same Worker.The ability to handle both directions in a single codebase, with a single platform's observability tools, is a meaningful simplification compared to the current multi-service setup most developers manage.<h2>SMTP and REST API Support for Non-Workers Integrations</h2>Not every application is built on Workers. Cloudflare has confirmed that Email Service will support both REST API and SMTP access for external applications meaning you can use it as a drop-in replacement for your current email provider even in applications that are not on the Cloudflare stack.If you are running a Next.js app on Vercel, a Laravel API on a VPS, or a Python backend anywhere, you will be able to point your SMTP configuration at Cloudflare Email Service instead of Mailgun or Postmark and send from your domain the same way you do today, just without the separate account, separate billing, and separate DNS configuration.<h2>What We Do Not Know Yet: Pricing</h2>Cloudflare has been deliberately vague on pricing, saying only that Email Sending will require a paid Workers subscription and will be charged based on messages sent, with final pricing to be announced before billing begins.The Workers Paid plan is $5 per month, that is the baseline. Per-message pricing beyond that is unconfirmed.Given Cloudflare's established pattern, R2 storage undercut AWS S3 significantly, Pages undercut Vercel on bandwidth costs, Workers undercut AWS Lambda on execution pricing, the expectation is competitive pricing. For context, current market rates for transactional email are roughly:<table style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1">Provider</th><th colspan="1" rowspan="1">Free Tier</th><th colspan="1" rowspan="1">Paid Entry</th></tr><tr><td colspan="1" rowspan="1">Brevo</td><td colspan="1" rowspan="1">300 emails/day</td><td colspan="1" rowspan="1">~$9/month for 5,000/month</td></tr><tr><td colspan="1" rowspan="1">Mailgun</td><td colspan="1" rowspan="1">100 emails/day (trial)</td><td colspan="1" rowspan="1">$35/month for 50,000</td></tr><tr><td colspan="1" rowspan="1">Postmark</td><td colspan="1" rowspan="1">100 emails/month</td><td colspan="1" rowspan="1">$15/month for 10,000</td></tr><tr><td colspan="1" rowspan="1">Resend</td><td colspan="1" rowspan="1">3,000 emails/month</td><td colspan="1" rowspan="1">$20/month for 50,000</td></tr><tr><td colspan="1" rowspan="1">Cloudflare</td><td colspan="1" rowspan="1">Unknown — waitlist</td><td colspan="1" rowspan="1">Unknown — per message</td></tr></tbody></table>If Cloudflare prices Email Service at or below Resend's rates ( which itself undercut the market when it launched ) the combination of native Workers integration, automatic DNS configuration, and competitive pricing makes a strong case for switching once GA drops.<h2>Current Status and What to Do Right Now</h2>Cloudflare Email Service is in private beta. The waitlist is open through the Cloudflare dashboard, navigate to Email in the left sidebar and look for Email Sending (Beta). If you see the "Join the Waiting list" prompt, just click it. There is no announced general availability date yet.For your current projects that need transactional email today, the practical solution remains the Cloudflare + Brevo + Gmail setup. Our guide — <a target="_blank" rel="noopener noreferrer nofollow" href="/articles/how-to-send-and-receive-professional-emails-via-gmail-for-free">How to Send and Receive Professional Emails via Gmail for Free</a> — walks through the complete setup: Cloudflare Email Routing handles inbound email to your domain, Brevo provides the free SMTP layer for sending, and Gmail becomes your interface. Brevo's free tier allows 300 emails per day, more than sufficient for most small applications and personal projects.When Cloudflare Email Service reaches general availability and pricing is confirmed, that guide will be updated with the native Cloudflare path as the primary recommendation. Until then, the Brevo route is tested, free, and works today.<h2>Why This Matters for Developers in Kenya</h2>The transactional email problem is not just a technical inconvenience, it is a friction point that affects whether small applications and startups can afford to operate professionally.Mailgun and Postmark charge in USD. At current exchange rates, Mailgun's entry plan at $35 per month is approximately Ksh 4,500, a meaningful monthly expense for a solo developer or early-stage startup. Brevo's free tier is generous but has limitations that push growing projects toward paid plans sooner than expected.<ad-spot></ad-spot>A Cloudflare-native solution billed through the same account that already manages your DNS, CDN, and Workers removes a billing relationship, a credential management headache, and a DNS configuration exercise from every new project. For developers building on the Cloudflare stack ( and as we have covered extensively, that stack is increasingly the default for African developers ) this is the email piece that has been missing.The waitlist is open. GA is coming. The pricing will determine how quickly it becomes the default recommendation but the direction is clear.Join the Cloudflare Email Service waitlist through your Cloudflare dashboard under Email → Email Sending (Beta). For sending transactional emails today, follow our <a target="_blank" rel="noopener noreferrer nofollow" href="/articles/how-to-send-and-receive-professional-emails-via-gmail-for-free">Cloudflare + Brevo + Gmail guide</a>.

Cloudflare Is Building a Transactional Email Service — And It Could Replace Brevo, Mailgun, and Postmark

If you have ever built a serious web application with Next.js, you know the moment. Everything is working beautifully in development. You are ready to deploy. And then you look at Vercel's pricing page.For small projects and side hustles, Vercel's free tier is generous enough. But the moment your application gets real traffic, needs proper team collaboration, or requires advanced features like ISR caching and edge functions at scale, the bills climb fast. Vercel's Pro plan starts at $20 per month per team member. Enterprise pricing is custom, meaning expensive. And because Next.js was built by Vercel, deploying it anywhere else has always involved a painful compatibility dance with tools like OpenNext that require constant maintenance as Next.js versions change.For years, developers have wanted a clean escape route. Last week, Cloudflare built one in seven days, with AI, for $1,100 in API tokens.<h2>What Is vinext?</h2>Vinext (pronounced "vee-next") is Cloudflare's open-source, drop-in replacement for Next.js. It implements the Next.js API surface that is routing, server rendering, React Server Components, server actions, caching, middleware but builds everything on top of Vite, the build tool that powers most of the modern frontend ecosystem outside of Next.js.The installation and migration is deliberately minimal:<pre><code class="language-bash">npm install vinext</code></pre>Replace <code>next</code> with <code>vinext</code> in your package.json scripts. Your existing <code>app/</code>, <code>pages/</code>, and <code>next.config.js</code> stay exactly as they are. Then:<pre><code class="language-bash">vinext dev # Development server with hot module replacement
vinext build # Production build
vinext deploy # Build and deploy directly to Cloudflare Workers</code></pre>That last command — <code>vinext deploy</code> — is the one that matters most. A single command takes your Next.js application and puts it on Cloudflare Workers, one of the cheapest and most globally distributed serverless platforms available. No adapter configuration. No reverse-engineering Turbopack output. No OpenNext whack-a-mole every time Next.js ships a new version.This is not a wrapper around Next.js. It is a full reimplementation of what Next.js does, built from scratch on different foundations.<ad-spot></ad-spot><h2>The Vercel Problem, Explained</h2>To understand why this matters, you need to understand the lock-in that has built up around Next.js over the past several years.Next.js is the most popular React framework by a significant margin. It introduced features like server-side rendering, static site generation, API routes, and most recently React Server Components, features that fundamentally changed how React applications are built. Millions of developers have learned these patterns. Millions of production applications are built on them.The problem is that Next.js was built by Vercel, and its internal architecture has been deeply optimised for Vercel's own infrastructure. The build toolchain, Turbopack, is bespoke. The output format is proprietary. When you try to deploy a Next.js application anywhere other than Vercel, you are fighting against an architecture that was not designed for you.OpenNext has been the community's answer to this for the past two years. It reverse-engineers Next.js's build output and reshapes it for other platforms such as Cloudflare, AWS Lambda, Netlify. But reverse-engineering means fragility. Every Next.js version update potentially breaks the adapter. The teams maintaining OpenNext (including Cloudflare's own engineers ) have described the process as "whack-a-mole." Fix one thing, another breaks.Vercel's own first-class adapters API is in progress, and Cloudflare has been collaborating with the Next.js team on it. But even with adapters, the bespoke Turbopack toolchain remains. And during development, <code>next dev</code> runs exclusively in Node.js meaning if your application uses Cloudflare-specific APIs like Durable Objects, KV, or AI bindings, you cannot test that code in development without workarounds.Vinext eliminates all of these problems at the root.<ad-spot></ad-spot><h2>The Numbers Are Not Marketing</h2>Cloudflare published benchmark results comparing vinext against Next.js 16, using a shared 33-route App Router application. The methodology is transparent. Full details and historical results are public at <a target="_blank" rel="noopener noreferrer nofollow" href="https://benchmarks.vinext.workers.dev/">benchmarks.vinext.workers.dev</a>.Production build time:<table style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1">Framework</th><th colspan="1" rowspan="1">Mean build time</th><th colspan="1" rowspan="1">vs Next.js</th></tr><tr><td colspan="1" rowspan="1">Next.js 16.1.6 (Turbopack)</td><td colspan="1" rowspan="1">7.38 seconds</td><td colspan="1" rowspan="1">baseline</td></tr><tr><td colspan="1" rowspan="1">vinext (Vite 7 / Rollup)</td><td colspan="1" rowspan="1">4.64 seconds</td><td colspan="1" rowspan="1">1.6x faster</td></tr><tr><td colspan="1" rowspan="1">vinext (Vite 8 / Rolldown)</td><td colspan="1" rowspan="1">1.67 seconds</td><td colspan="1" rowspan="1">4.4x faster</td></tr></tbody></table>Client bundle size (gzipped):<table style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><th colspan="1" rowspan="1">Framework</th><th colspan="1" rowspan="1">Gzipped size</th><th colspan="1" rowspan="1">vs Next.js</th></tr><tr><td colspan="1" rowspan="1">Next.js 16.1.6</td><td colspan="1" rowspan="1">168.9 KB</td><td colspan="1" rowspan="1">baseline</td></tr><tr><td colspan="1" rowspan="1">vinext (Rollup)</td><td colspan="1" rowspan="1">74.0 KB</td><td colspan="1" rowspan="1">56% smaller</td></tr><tr><td colspan="1" rowspan="1">vinext (Rolldown)</td><td colspan="1" rowspan="1">72.9 KB</td><td colspan="1" rowspan="1">57% smaller</td></tr></tbody></table>Cloudflare is explicit that these benchmarks measure compilation and bundling speed, not production serving performance, and that the test fixture is a single app rather than a representative sample. The direction, however, is significant. Vite's architecture and especially Rolldown, the Rust-based bundler coming in Vite 8, has structural performance advantages over Turbopack that show up clearly in the numbers.For a developer running builds dozens of times a day, a 4x speed improvement is not a statistic. It is time back in your day.<h2>The Feature That Is Genuinely New</h2>ISR ( Incremental Static Regeneration ) and caching are already working in vinext via Cloudflare KV. App Router and Pages Router both work on Cloudflare Workers with full client hydration. But the feature that stands out as genuinely novel is something Cloudflare is calling Traffic-aware Pre-Rendering.In Next.js, if you want to pre-render pages at build time, which makes them load instantly for users because the HTML is already generated , you have to enumerate every page you want pre-rendered using <code>generateStaticParams()</code>. For a large e-commerce site with 100,000 product pages, this means your build touches every one of those pages. Builds scale linearly with page count. This is why large Next.js sites end up with 30-minute build times.Traffic-aware Pre-Rendering approaches this differently. Cloudflare is already the reverse proxy sitting in front of your website. It already knows which pages actually get traffic. So instead of pre-rendering everything, vinext queries Cloudflare's zone analytics at deploy time and pre-renders only the pages that actually get visited:<pre><code class="language-bash">vinext deploy --experimental-tpr</code></pre><code>Building... Build complete (4.2s)</code><code>TPR: Analyzing traffic for my-store.com (last 24h) TPR: 12,847 unique paths — 184 pages cover 90% of traffic TPR: Pre-rendering 184 pages... TPR: Pre-rendered 184 pages in 8.3s → KV cache</code><code>Deploying to Cloudflare Workers...</code>The power law of web traffic means that for most large sites, 90% of visits go to a small fraction of pages. Traffic-aware Pre-Rendering identifies that fraction automatically, pre-renders those pages in seconds, and lets everything else be served on-demand via ISR. Pages that suddenly go viral get picked up on the next deploy. No <code>generateStaticParams()</code>. No coupling your build to your production database. No 30-minute builds.It is experimental today but the concept is sound and it demonstrates what becomes possible when your build tool and your CDN are made by the same company.<ad-spot></ad-spot><h2>One Engineer. One Week. $1,100 in AI Tokens.</h2>Here is the part of this story that deserves its own conversation because it says something important about where software development is heading.A project like vinext would normally take a team of engineers months, if not years. Several teams have attempted to build a proper Next.js alternative. Cloudflare tried before and did not finish. The scope, two routers, 33+ module shims, server rendering pipelines, RSC streaming, file-system routing, middleware, caching , is genuinely enormous.This time, one engineering manager directing AI completed it in under a week.The first commit landed on February 13. By the end of that evening, both the Pages Router and App Router had basic SSR working. By the next afternoon, the App Router Playground was rendering 10 of 11 routes. By day three, <code>vinext deploy</code> was shipping apps to Cloudflare Workers with full client hydration. The rest of the week was hardening: edge cases, test coverage, API surface expansion.The entire codebase was written by AI. But it passes 1,700+ Vitest unit tests and 380 Playwright end-to-end tests. TypeScript type checking runs via tsgo. Linting runs via oxlint. CI runs all of it on every pull request. API surface coverage sits at 94% of Next.js 16.The total cost was approximately $1,100 in Claude API tokens.What made this possible where previous attempts failed? Steve Faulkner, the Cloudflare engineering manager who led the project, points to four things aligning simultaneously: Next.js is exceptionally well-documented, so the AI knew the target API inside out. Next.js has an elaborate test suite, giving a mechanical specification to verify against. Vite is an excellent foundation that handled the hard parts of frontend tooling. And current AI models can sustain coherence across a codebase this complex in a way that earlier models simply could not.Faulkner is also candid about what the human still had to do. Architecture decisions, prioritisation, recognising when the AI was headed down a dead end, that was all him. The AI did not steer. It executed under direction. But the gap between what a skilled human directing AI can produce in a week and what a team of engineers could produce in months has compressed dramatically. Vinext is a data point that the software industry will be processing for some time.<ad-spot></ad-spot><h2>What This Means for Developers in Kenya and Africa</h2>For developers building on Vercel in Kenya, the economics of vinext are worth sitting with directly.Cloudflare Workers' free tier includes 100,000 requests per day. The paid plan, Workers Paid, costs $5 per month for 10 million requests, then $0.30 per million after that. Cloudflare KV, R2, and Durable Objects ( the services that replace Vercel's edge caching and storage) are priced at fractions of what equivalent AWS or Vercel services cost. There are no egress fees on R2, as we covered in our piece on<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/cloudflare-just-made-r2-significantly-faster-for-african-developers-here-is"> Cloudflare's Local Uploads feature</a>.For a Kenyan startup or indie developer running a Next.js application on Vercel's Pro plan at $20 per seat per month, vinext is not just a technical alternative. It is a significant cost reduction on infrastructure that is already a meaningful line item when you are operating in a market where margins are thin and dollar-denominated bills are paid in shillings.There are caveats. Vinext is experimental. It does not yet support static pre-rendering at build time, though ISR covers most dynamic use cases. Some Next.js features are explicitly not supported and will not be, because they are tied to Vercel-specific infrastructure. If you are running a large production Next.js application with complex requirements, wait for more battle-testing before migrating. The README is honest about limitations, which is a good sign.For new projects, however, vinext is already a credible choice. <a target="_blank" rel="noopener noreferrer nofollow" href="https://cio.gov/">CIO.gov</a>, a US government website managed by National Design Studio, is already running vinext in production. The fact that a government web team considered it production-ready within a week of its public release says something about the quality of the test coverage.<h2>The Bigger Pattern</h2>We have written several pieces recently about Cloudflare's moves in the developer infrastructure space that is <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/cloudflare-just-made-r2-significantly-faster-for-african-developers-here-is">R2 Local Uploads</a> cutting cross-region write latency for African developers, <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/cloudflare-introduces-markdown-for-ai-agents-a-quiet-revolution-with-major">Markdown for Agents</a> enabling AI systems to read web content cleanly, <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/google-just-changed-how-ai-interacts-with-websites-here-is-what-every-kenya">WebMCP </a>enabling AI agents to take actions on websites. Vinext fits into a pattern that is becoming increasingly clear.Cloudflare is systematically building an alternative to every major proprietary piece of the web development stack. R2 instead of S3. Workers instead of Lambda. KV instead of DynamoDB for edge data. Pages instead of Netlify. And now vinext instead of Next.js on Vercel.Each individual piece is compelling on its own. Together, they represent a coherent vision of a web development platform that is open, portable, and priced for developers who are not operating at enterprise scale. For developers in Kenya and across Africa, where infrastructure costs are felt more acutely because they are paid in local currencies against dollar-denominated bills, that vision is not abstract. It has real economic implications.Vinext is experimental today. In six months, if the project matures at the pace it has already demonstrated, it could become the default deployment target for a significant portion of new Next.js projects. Not because it is better than Vercel in every dimension. Vercel's developer experience is genuinely excellent. But because for most applications, the Cloudflare alternative will be good enough and substantially cheaper.Good enough and substantially cheaper has a way of winning.

Cloudflare Just Built a Next.js Replacement in One Week With AI — And It Could Free Thousands of Developers From Vercel's Bills

If you are a Kenyan or African developer building on Cloudflare R2, there is a feature that quietly launched in open beta earlier this month that you should enable on your buckets right now. It is called Local Uploads, it costs nothing extra, and depending on where your users are relative to your bucket, it could cut your upload latency by up to 75%.That is not a marketing number. It is from Cloudflare's own synthetic benchmarks, and the underlying reason it matters so much for African developers specifically is worth understanding.<h2>The Problem: Your Bucket Is Far Away</h2>When you create an R2 bucket, it lives in a specific region — typically somewhere in the US or Europe, because those are where the primary storage locations are. Your Cloudflare Workers run at the edge, close to your users, which is why reads are already fast globally. R2 automatically caches reads across Cloudflare's network.But writes have always been a different story.When a user in Nairobi uploads a file to your app — a profile picture, a document, a video clip — that data has to travel all the way from their device to your bucket's physical location. If your bucket is in Eastern Europe, you are looking at a round trip that crosses oceans and multiple network hops. The result is slow, variable, and sometimes unreliable upload performance.<img src="https://cdn.calebms.com/articles/64284af2-9b99-4748-b401-54a6906941be.png" alt="49662.png">This is the "distance problem," and it has been the one area where R2's promise of global performance broke down. Until now.<h2>What Local Uploads Does</h2>Cloudflare's Local Uploads feature changes how R2 handles write requests when the client is in a different region from the bucket.Here is what happens with Local Uploads enabled:1. Your user in Nairobi initiates an upload.2. R2 receives the request at the nearest Cloudflare point of presence — in this case, likely the Nairobi or Mombasa data centre.3. The object data is written to storage infrastructure close to the user immediately.4. R2 returns a success response to the client right away. The upload is done from the user's perspective.5. In the background, Cloudflare replicates the data to your bucket's home region asynchronously.The critical detail is step 4. The object is immediately accessible and strongly consistent the moment the upload completes — there is no waiting for replication to finish before the file can be read. Cloudflare handles the background copying with automatic retries to ensure nothing is lost.<img src="https://cdn.calebms.com/articles/167b84e8-0b15-4f06-8b32-248d7f15fa4e.png" alt="49663.png">In Cloudflare's own benchmark tests — simulating a client in Western North America uploading to a bucket with an Asia-Pacific location hint — median upload time dropped from around 2 seconds to around 500 milliseconds after enabling Local Uploads. That is a 75% reduction in Time to Last Byte.<img src="https://cdn.calebms.com/articles/708d1177-2574-4dfb-8c75-d9663dbc6af8.png" alt="49661.png">For a user in Nairobi uploading to a US-based bucket, the distance and latency profile is even more extreme than that benchmark scenario. The gains are likely to be at least as significant, and possibly more.<h2>Why This Matters More for Africa Than Almost Anywhere Else</h2>Cloudflare has over 300 points of presence globally, including multiple locations across Africa — Nairobi, Lagos, Johannesburg, Cairo, and others. This means the "nearest PoP" for your Kenyan users is genuinely nearby, not a European proxy.But the primary R2 storage regions are concentrated in North America, Europe, and Asia-Pacific. There is no R2 storage region in Africa. This means every single upload from an African user to an R2 bucket — without Local Uploads — has been making a cross-continental journey.That gap matters in practical terms. If you are building:<ul class="tight" data-tight="true"><li>A file sharing or document management app with Kenyan users</li><li>A media platform where users upload photos or videos</li><li>A mobile app that syncs data or logs to R2</li><li>An e-commerce platform where sellers upload product images</li></ul>...every upload your users make has been traveling thousands of kilometres more than it needed to. Local Uploads eliminates that penalty.<h2>One Thing to Know Before You Enable It</h2>Local Uploads works best when your reads and writes come from the same region. There is a nuance worth understanding: when a file is uploaded locally and replication to the home bucket region is still in progress, a read request coming from near the bucket's home region — not from near the uploader — may experience some latency until replication completes.In practice, for most Kenyan and African developer use cases, this is not a concern. If your users are uploading and reading their own content from the same general region, the experience is fast in both directions. The edge case to watch is if you have a backend process in the US reading files immediately after an African user uploads them — there could be a brief window before replication completes.Also worth noting: Local Uploads is not available for buckets with jurisdictional restrictions enabled, such as EU-restricted or FedRAMP buckets, because the feature requires temporarily routing data through locations outside the bucket's designated region.<h2>How to Enable It</h2>Enabling Local Uploads takes about 30 seconds and requires no code changes. It works with the S3 API, Workers Bindings, and plain HTTP — whatever you are already using continues to work exactly as before, just faster.Via the Cloudflare Dashboard:1. Log in to the Cloudflare dashboard.2. Navigate to R2 Overview.3. Select the bucket you want to update.4. Go to the Settings tab.5. Find Local Uploads and select Enable.That is it. Existing uploads complete normally with no interruption to traffic.Via Wrangler (CLI):If you prefer the command line, a single command does the job:<pre><code>npx wrangler r2 bucket local-uploads enable [YOUR_BUCKET_NAME]</code></pre>Replace `[YOUR_BUCKET_NAME]` with the name of your bucket. You can also disable it at any time with:<pre><code>npx wrangler r2 bucket local-uploads disable [YOUR_BUCKET_NAME]</code></pre>Cost: There is no additional cost. Upload requests incur the standard Class A operation costs, exactly as they did before Local Uploads.<h2>How to Verify It Is Working</h2>Once enabled, you can monitor the impact through the R2 bucket metrics page in the Cloudflare dashboard. Navigate to your bucket, select Metrics, and look at the Request Distribution by Region chart. This shows you the geographic distribution of read and write requests and gives you a picture of where your traffic is coming from relative to your bucket location.<img src="https://cdn.calebms.com/articles/7f3ef8ae-0d75-406f-99ff-a4ab274e1c13.png" alt="49664.png">If you want to test it directly, Cloudflare has a public demo at <a target="_blank" rel="noopener noreferrer nofollow" href="https://local-uploads.r2-demo.workers.dev">`local-uploads.r2-demo.workers.dev`</a> that lets you simulate uploads from different geographic locations and see the latency difference with and without Local Uploads enabled.<h2>How Does This Compare to AWS S3 Transfer Acceleration?</h2>AWS offers a similar feature for S3 called Transfer Acceleration, which uses CloudFront edge locations to speed up uploads from distant clients. The approaches are architecturally different: S3 Transfer Acceleration optimises routing through the AWS network backbone, while R2 Local Uploads performs actual local writes with asynchronous replication.The practical difference for Kenyan developers is cost. S3 Transfer Acceleration carries an additional per-GB charge on top of standard S3 pricing. R2 Local Uploads is free, and R2 already has no egress fees — which is the reason many developers in Kenya and across Africa have been moving away from S3 to R2 in the first place.Google Cloud Storage and Azure Blob Storage currently have no equivalent feature that accepts local writes globally.<h2>The Bigger Picture</h2>This is the second significant developer-focused update from Cloudflare in recent weeks that has direct implications for African developers. We covered <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/cloudflare-introduces-markdown-for-ai-agents-a-quiet-revolution-with-major">Cloudflare's Markdown endpoint for AI agents </a>this month — a feature that changes how AI systems consume web content, with meaningful implications for publishers on the continent.Local Uploads is a more targeted, infrastructure-level improvement, but it addresses one of the most persistent friction points for developers building user-facing applications in markets far from where cloud storage infrastructure is concentrated. The fact that it costs nothing to enable makes the decision simple.If you are building on R2, turn it on today.Are you building on Cloudflare R2? Share what you are working on in the comments — we are always looking to feature interesting projects from Kenyan and African developers.

Cloudflare Just Made R2 Significantly Faster for African Developers — Here Is What Changed and Why It Matters

Cloudflare Introduces Markdown for AI Agents: A Quiet Revolution with Major Implications for Publishers

The world of AI agents is evolving rapidly, and the infrastructure needed to run them is changing just as fast. A new experimental project from Cloudflare called Moltworker is challenging the assumption that you need expensive local hardware to run AI agents 24/7. Here's what's happening and why it matters.<h2>What is OpenClaw?</h2>OpenClaw (formerly known as Moltbot and Clawdbot before that) is an open-source agentic AI system that can autonomously handle tasks for you around the clock. Think of it as a digital assistant that doesn't just answer questions, but actually takes action on your behalf.Unlike traditional chatbots that simply respond to queries, OpenClaw is "agentic" – meaning it can:<ul><li>Break down complex tasks into smaller steps</li><li>Make decisions about what to do next</li><li>Use tools like web browsers, terminals, and code execution environments</li><li>Remember context across multiple interactions</li><li>Work continuously on long-running tasks even when you're not watching</li></ul>For example, you could ask OpenClaw to monitor a website for price changes, compile research reports, manage data processing workflows, or automate repetitive coding tasks. The agent would work on these tasks persistently, making intelligent decisions along the way.<h2>The Traditional Setup: Running OpenClaw on Your Hardware</h2>Originally, running an AI agent like OpenClaw meant setting up significant infrastructure on your local machine. Here's what that looked like:<h3>Hardware Requirements</h3>Many early adopters found themselves purchasing Mac Minis or equivalent hardware specifically to run these agents. Why? Because you needed:<ul><li>Sufficient RAM and CPU: AI agents make frequent API calls, run code, process data, and maintain state – all of which require computing resources</li><li>Always-on availability: Your machine needs to run 24/7 if you want your agent working around the clock</li><li>Reliable internet: Constant connectivity is essential for API calls to AI providers like Anthropic or OpenAI</li><li>Storage: Database systems to maintain the agent's memory and task history</li></ul><h3>Software Stack</h3>Beyond hardware, you'd need to manage:<ul><li>Operating System: Keep it updated and secure</li><li>Database: Usually PostgreSQL or SQLite for storing the agent's memory and state</li><li>Runtime Environment: Node.js or Python environments with all dependencies</li><li>Security: Firewall configuration, SSL certificates if exposing services</li><li>Process Management: Systems to ensure the agent restarts if it crashes</li></ul><ad-spot></ad-spot><h3>The Security Problem</h3>Here's where things got genuinely scary: giving an AI agent access to a terminal on your local machine is inherently risky. If the agent is compromised through prompt injection (where malicious instructions are hidden in data the agent processes), an attacker could potentially:<ul><li>Access your file system</li><li>Steal credentials</li><li>Install malware</li><li>Use your machine as part of a botnet</li></ul>This security concern alone made many people hesitant to run agentic AI locally, despite the compelling use cases.<h2>Enter Cloudflare Moltworker: A Different Approach</h2>Cloudflare Moltworker reimagines this entire setup. Instead of running everything on your local hardware, it demonstrates how to deploy an AI agent entirely on Cloudflare's edge infrastructure. Here's how it works:<h3>The Architecture Shift</h3><img src="https://cdn.calebms.com/articles/4491d907-96cd-4b48-9eae-7d52ee727dba.png" alt="45313.png">Moltworker leverages several Cloudflare services working together:Cloudflare Workers: The agent's code runs on Cloudflare's serverless platform, distributed across 300+ data centers globally. You're not maintaining servers – you're running code on-demand.R2 Storage: Instead of a local PostgreSQL database, the agent's long-term memory and logs are stored in Cloudflare's object storage (similar to Amazon S3 but cheaper for egress).Sandbox SDK: This is the game-changer for security. Each time the agent needs to run code or execute commands, Cloudflare spins up an isolated micro-VM that exists only for that specific task, then destroys it immediately after. It's like giving the agent a clean room that disappears when the work is done.Browser Rendering API: When the agent needs to interact with websites, Cloudflare provides headless Chromium instances – no need to run browsers on your machine.AI Gateway: Routes API calls to AI providers (Anthropic, OpenAI, etc.) with centralized billing, caching, and observability.Zero Trust Access: Built-in authentication and access control without manually configuring firewalls or certificates.<h3>From wrangler deploy to Running Agent</h3>With Moltworker, deployment looks like this:<pre><code>wrangler deploy</code></pre>That's it. No operating system to patch, no database to configure, no SSL certificates to renew. Cloudflare handles the infrastructure while you focus on what your agent should do.<ad-spot></ad-spot><h2>Benefits of the Moltworker Approach</h2><h3>1. Dramatically Lower Barrier to Entry</h3>You no longer need to buy a Mac Mini or dedicate hardware. Starting costs can be as low as $5/month for the Workers Paid plan (though actual costs vary with usage). You can run an AI agent from a laptop, phone, or any device with internet access.<h3>2. Security Through Isolation</h3>The Sandbox SDK creates ephemeral micro-VMs for code execution. Even if an attacker successfully injects malicious commands through prompt injection, they gain access to a virtual environment that will be destroyed in seconds. Your actual system remains untouched.<h3>3. Zero Infrastructure Management</h3>No more:<ul><li>OS updates at 2 AM</li><li>Database backup strategies</li><li>Monitoring disk space</li><li>Configuring firewalls</li><li>Renewing SSL certificates</li><li>Debugging why the agent stopped running</li></ul>Cloudflare manages all of this at the platform level.<h3>4. Global Distribution</h3>Your agent runs on edge infrastructure close to users and data sources, potentially reducing latency for API calls and web interactions.<h3>5. Built-in Observability</h3>Through AI Gateway and Workers Analytics, you get visibility into:<ul><li>How many AI API calls you're making</li><li>Cost tracking across providers</li><li>Performance metrics</li><li>Error rates</li></ul><h3>6. Infinite Scale (Theoretically)</h3>Serverless infrastructure scales automatically. If your agent needs to spawn multiple parallel tasks, the platform handles it without you provisioning additional capacity.<h2>Challenges and Limitations of Moltworker</h2>Before you rush to migrate everything, here are important caveats:<h3>1. Not an Official Product</h3>Cloudflare explicitly states this is an experimental proof-of-concept, not a supported product. This means:<ul><li>No SLA guarantees</li><li>Could break with platform updates</li><li>Limited official documentation</li><li>You might need to maintain your own fork for production use</li></ul><h3>2. Cost Uncertainty at Scale</h3>While the starting cost is low, actual expenses depend heavily on:<ul><li>CPU time consumed (billed per millisecond of active execution)</li><li>Number of AI API calls</li><li>R2 storage and operations</li><li>Browser Rendering API usage</li></ul>For high-intensity agents running constantly, costs could climb significantly. You won't know until you monitor actual usage.<h3>3. Platform Lock-in</h3>Building on Cloudflare's specific APIs (Durable Objects, R2, Sandbox SDK) means your agent becomes tightly coupled to their platform. Migrating to AWS, Azure, or back to local infrastructure would require substantial rewriting.<h3>4. Execution Time Limits</h3>Cloudflare Workers have execution time constraints. For extremely long-running tasks, you need to architect around these limits using patterns like breaking work into chunks or using Durable Objects for state management.<h3>5. Node.js Compatibility Isn't 100%</h3>While Cloudflare claims 98.5% Node.js package compatibility, that missing 1.5% might include packages critical to your specific use case. Native modules and certain file system operations may not work.<h3>6. Debugging Complexity</h3>Troubleshooting distributed, serverless systems is inherently harder than debugging a local application where you can attach a debugger and inspect state directly.<h3>7. Data Residency and Privacy</h3>If you're working with sensitive data, running agents on Cloudflare's infrastructure means trusting their security model and potentially navigating data residency regulations (though Cloudflare does offer regional services).<ad-spot></ad-spot><h2>What This Means for the Future</h2>Moltworker, whether it succeeds as a project or not, represents an important signal: agent hosting is becoming commoditized infrastructure.Just as we moved from physical servers to virtual machines to containers to serverless functions, AI agents are following a similar trajectory. The question is shifting from "Can I afford the hardware to run an agent?" to "Which platform best supports my agent's needs?"For developers in Kenya and across Africa, this democratization is particularly significant. You no longer need expensive hardware or complex DevOps expertise to experiment with agentic AI. A student with a $5/month budget can deploy the same infrastructure that would have required thousands of dollars in hardware just a year ago.<h2>Should You Use Moltworker?</h2>Consider it if:<ul><li>You're experimenting with AI agents and want minimal setup</li><li>You value security isolation for code execution</li><li>You prefer infrastructure-as-code deployments</li><li>You're comfortable with bleeding-edge, experimental technology</li></ul>Stick with local or traditional cloud if:<ul><li>You need guaranteed uptime and support (this is experimental)</li><li>You're running production workloads that can't tolerate breaking changes</li><li>You need full control over execution environment and data</li><li>You require specific packages incompatible with Workers runtime</li></ul><h2>Conclusion</h2>Cloudflare's Moltworker isn't just about running OpenClaw in the cloud – it's a glimpse into how AI infrastructure is evolving. The combination of serverless computing, edge distribution, and micro-VM isolation creates a new paradigm for deploying autonomous agents safely and affordably.Whether Moltworker itself becomes the standard or simply inspires better solutions, one thing is clear: the barrier to running sophisticated AI agents is collapsing. That's good news for developers everywhere, especially in markets where expensive hardware has been a limiting factor.The age of accessible, always-on AI agents is here. The only question is what we'll build with them.Have you experimented with AI agents or Cloudflare Workers? Share your experience in the comments below.

From Local Hardware to the Cloud: How Cloudflare is Reimagining AI Agents with Moltworker

Are you tired of using a <code>@gmail.com</code> address for your business? While Google Workspace costs about $6/month, you can actually get a professional <code>@yourdomain.com</code> email address for free by leveraging Cloudflare and Brevo.In this guide, I will show you exactly how I set this up for <code>calebms.com</code> using my laptop.<h3>Prerequisites</h3><ol><li>A Cloudflare account (Domain DNS must be managed here).</li><li>A Brevo (formerly Sendinblue) free account.</li><li>A standard Gmail account.</li><li>Registered Custom Domain</li></ol>Tutorial Update: SMTP FlexibilityNote on Providers: While I used Brevo for this guide because of its generous free tier, this method works with almost any SMTP provider. If you prefer Mailgun, Amazon SES, or Postmark, the process is identical—simply swap the Brevo SMTP server, port, and credentials with the ones provided by your chosen service in Step<ad-spot></ad-spot><h2>Step 1: Authenticate Your Domain in Brevo</h2>First, we need to give Brevo permission to send emails on our behalf.<ol><li>Log into Brevo. Go to Settings &gt; Senders, Domains, and IPs &gt; Domains.</li><li>Click Add a Domain and enter your domain (e.g., <code>calebms.com</code>).</li><li>Select "Authenticate Domain Automatically." You will be prompted to log into Cloudflare. Simply authorize the request, and Brevo will automatically add the necessary DNS records.</li></ol><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/3e8bfad7-a879-4e3c-b57e-e34d23e938da.png" alt="image.png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/f319c57d-1395-4f25-a50f-5599e6be6aa9.png" alt="image (2).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/21940509-cf8f-46aa-a84c-9e3daa9b4707.png" alt="image (3).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/85410490-eea2-4310-a7e5-700eadc68f3c.png" alt="image (4).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/ac1617b1-2a8e-4f89-9468-2074cb0aef70.png" alt="image (5).png"><h2>Step 2: Set Up Email Receiving (Cloudflare Email Routing)</h2>While Brevo processes your domain, let’s configure how you will receive mail.<ol><li>In Cloudflare, select your domain and click Email &gt; Email Routing.</li><li>Cloudflare will show you the required MX records. Click Add records and enable.</li></ol><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/720a094f-2d40-4e78-bff7-d8eb16fef780.png" alt="image (6).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/7f349d82-9149-4373-90d9-a6f521267c7e.png" alt="image (7).png">3. Go to the Destination addresses tab. Add your Gmail address and verify it via the link sent to your inbox.<img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/2fd1e02b-3ae6-4601-b594-cef02e3a5a21.png" alt="image (8).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/7accc0da-bb92-4ae7-98ab-1b4650b020b6.png" alt="image (9).png">4. Go to Routing Rules and click Create custom address.<ul><li>Custom address: <code>caleb@calebms.com</code></li><li>Action: Send to email</li><li>Destination: Your verified Gmail address.</li></ul><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/f064dbbf-780e-4906-a1d7-bf354af2ab5c.png" alt="image (10).png">Pro Tip: Send a test email from a different account (like Yahoo) to your new custom address. It should arrive in your Gmail inbox instantly!<img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/ef2be038-612d-4318-8240-2a7b3469a992.jpeg" alt="29593.jpg"><ad-spot></ad-spot><h2>Step 3: Configure "Send Mail As" (The SMTP Setup)</h2>Now, let’s make it possible to reply using your professional address.<ol><li>In Brevo, go to Senders &gt; Add a Sender. Use your name and your new professional email (e.g., <code>caleb@calebms.com</code>).</li></ol><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/830936fa-7fbf-4874-88de-0136142a5bcb.png" alt="image (12).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/5a50c9f3-d8a4-406b-a71f-77feb60b24eb.png" alt="image (13).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/e6c08d46-7cdf-4d2a-a230-286028df5cfa.png" alt="image (14).png">2.Navigate to SMTP &amp; API in Brevo. Click Generate a new SMTP key.<ul><li>Name: "Access Gmail"</li><li>Important: Copy this key immediately and save it safely. You won't see it again!</li><li>Note your SMTP Server , Port (587), and Login (your Brevo email).</li></ul><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/3009d044-9099-4549-a1cb-d63f8d2930a5.png" alt="image (15).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/f43c93c4-010d-4888-a797-8ae72194ef2e.png" alt="image (16).png"><h2>Step 4: Final Integration with Gmail</h2><ad-spot></ad-spot><ol><li>Open Gmail in your web browser. Go to Settings &gt; See all settings &gt; Accounts and Import.</li><li>Under Send mail as, click Add another email address.</li><li>Name: Your Name | Email: <code>caleb@calebms.com</code>.</li><li>CRITICAL: Uncheck "Treat as an alias" and click Next.</li><li>Enter the SMTP details from Brevo:<ul><li>SMTP Server: <code>smtp-relay.brevo.com</code></li><li>Port: <code>587</code></li><li>Username: Your Brevo Login.</li><li>Password: Your generated SMTP Key.</li><li>Select Secured connection using TLS.</li></ul></li></ol><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/d862061e-dd44-4866-835c-0a1c23863667.png" alt="image (17).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/77d77c3e-800c-42b7-b3aa-091330fe800f.png" alt="image (18).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/65b4c34a-8ed7-4f55-8f5b-8a00782f5069.png" alt="image (19).png"><img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/3d067d3b-1f2b-413f-8a75-73cab1bd2e28.png" alt="image (20).png"><h2>Step 5: Verify and Start Sending</h2>Gmail will send a confirmation code to your professional email. Since you set up forwarding in Step 2, this code will arrive in your Gmail inbox.<ol><li>Copy the code, paste it into the verification box, and click Verify.</li></ol>Refresh Gmail. When you click "Compose," you can now select your professional email from the "From" dropdown!<img src="https://cdn.calebms.com/articles/Oz8E8i58M2S00jnvmz1k8663gGA3/cd21778c-dd7d-44fd-8c50-d999d2fb67de.png" alt="image (21).png"><h3>A Note on Deliverability</h3>When testing, avoid subject lines like "Test 123." Filters often flag these as spam. Use a real subject line and body text to ensure your professional email maintains a high sender reputation.<h3>Summary of Pros &amp; Cons</h3><ul><li>Pros: 100% Free, unlimited receiving, professional look, no "sent via" warnings.</li><li>Cons: Technical setup, 300-email daily sending limit (on Brevo Free).</li></ul>