Also Cloudflare: let's send normal humans who are trying to go about their daily lives into endless Turnstile spinner loops with absolutely zero recourse, grievance, or support infrastructure.
I want to set a cap of $100/month and know, for sure, that if something untoward happens my apps will all stop serving traffic rather than me getting hit with a bill for $1000s.
The safest way to use Workers is on the free tier, which will shut off after 100,000 requests/day: https://developers.cloudflare.com/workers/platform/pricing/#...
https://snail-game.solstice-barometer.workers.dev/
pretty cool.
The article worded it perfectly; friction-less "efforts"
> Any agent can now run wrangler deploy --temporary and deploy a Worker to Cloudflare. This temporary deployment stays live for 60 minutes, during which time you can claim the temporary account, making it permanently your own. If you don't, it expires on its own.
Forget about agents, Cloudflare just provided free scratch deployments - ephemeral for 60 minutes - for anyone.
This is going to be amazing for things like PR previews and code review. Being able to deploy a preview to a working URL for free is a huge reduction in friction.
I hope it doesn't get abused so much that they turn it off again.
- simply expose containers to the world directly - without having to go via workers.
- You have other amazing parts of the stack anyway (D1, durable objects, a great object store). These aren't considered "lockin".
- workers is "lockin" - not similar enough to lambda/cloud functions and so becomes CF specific.
Not having a simple container based compute piece has made me hesitate in taking up CF. (Fly or firebase won out)
This would only work if they would provision docker image deployment, similar to google cloud run, but the still, everything serveless has its own caveats…
[1] https://developers.cloudflare.com/workers/platform/claim-dep...
This could lead to people having a large amount of separate accounts.
They prefer waiving the occasional DDoS / misconfiguration over giving their customers to cause outages with something so trivially forgotten about and so disconnected from the tech and actual platform.
If your company is on an enterprise plan, at least for us all of the limits are pre-negotiated and prepaid, and you aren’t billed for overages (although if you consistently overage, sales will start badgering you to negotiate a limit increase, but my experience is you can simply ignore their demands and they eventually go away)
It does drive me crazy that their enterprise tier “caps” bandwidth. Our company overaged on one of our domains, so we moved the domain out of our enterprise license onto a self-serve plan, and like magic, back to unlimited bandwidth.
A “create account” button accessible to me would be so much better. Then, I create the account and invite the client to join as owner.
The limits are 100 workers on free and 500 on paid.
And if need more then you can always go their platform which supports tenancy.
As long as you have a cronjob or similar to clean up the cost of having per PR preview is pretty much zero.
% npx wrangler deploy --temporary
wrangler 4.103.0
────────────────────
You must accept Cloudflare's Terms of Service (https://www.cloudflare.com/terms/) and Privacy Policy (https://www.cloudflare.com/privacypolicy/) in order to continue. By typing "yes", you agree to these terms. Type "yes" to continue. … yes
Solving proof-of-work challenge…
Temporary account ready:
Account: Educated Celery (created)
Claim within: 60 minutes
Claim URL: https://dash.cloudflare.com/claim-preview?claimToken=CAVe7LzWiGad-redacted
Total Upload: 13.79 KiB / gzip: 4.12 KiB
Uploaded cloudflare-redirect-resolver (2.27 sec)
Deployed cloudflare-redirect-resolver triggers (0.50 sec)
https://cloudflare-redirect-resolver.educated-celery.workers.dev
Current Version ID: 5c12da7f-2749-4ccc-a8f6-79b85da98d10
I'm amused that it made me accept the terms and conditions without any indication of who I am, but it did work - https://cloudflare-redirect-resolver.educated-celery.workers... will be live for the next 59 minutes.If it helps laugh DDoS attacks they would be incentivized to do the exact opposite. They can charge more for “protection” then.
It says to claim you can either sign up or sign in.
Agreed. I wish CF had something like Azure's new fast-starting Express containers.
On the other hand, we already use regular CF builds for frontend previews, but that doesnt solve a fullstack PR preview much
as far as i’m aware, that’s fully binding and often an accepted practise - take Minecraft’s server software, where you must accept the EULA with a text flag before running
I run workers and containers and am curious what you mean. Do you have specific use cases in mind outside of the worker invocation model? If so, I'm curious what you'd want to run on Cloudflare. Otherwise, workers don't have to be much of a "lockin" if treated as a thin layer, more like configuration.
> You have other amazing parts of the stack anyway (D1, durable objects, a great object store).
Instead, if you mean accessing these resources from containers, it's a bit clunky [0] but it's there - you should be able to access worker bindings from containers through those outbound handlers.
[0] https://developers.cloudflare.com/containers/platform-detail...
[1] https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...
The latest models appear to know CF Workers inside out and are very capable of doing that if you ask them to.
Here's my GPT-5.5 xhigh + Codex Desktop transcript building one just now: https://gist.github.com/simonw/264bd6b8a39fc34c91c9c867454c6... - code here: https://github.com/simonw/cloudflare-redirect-resolver
It's almost always better to use Durable Objects storage, rather than D1. Even if you only want a single global database, it's better to implement that as a singleton Durable Object, than by using D1. Because that's all D1 itself actually is: a singleton Durable Object that exposes an API to its SQLite database. It's just a wrapper.
With raw Durable Objects, you get to bring your code to run on the same machine as the database itself. Your queries run on a local file, synchronously, rather than going over a network. There is essentially zero latency when using sqlite storage in a Durable Object.
If your app does no more than one DB query per request, then D1 is fine: the Worker runs near the end user, and talks over the long-haul network to D1 just once. Whereas with Durable Objects, your Worker would talk over the long-haul network to the Durable Object. No difference.
But if your app ever does two or more queries in series for a single request, then Durable Objects becomes vastly better, because you get to move that query-chaining code to happen directly where the database lives, rather than have multiple round trips.
Really, though, the only reason D1 exists is for comfort. Once you know how to use Durable Objects, there's no reason to use D1. We offer D1 because a lot of people don't want to learn a new model. (Which is fair. People are busy and may have better things to do.)
One caveat: D1's read replica support still isn't exposed in a way that you can use it in raw Durable Objects, so if you are using that, it's a legitimate advantage to D1. But we do plan to bring this functionality to raw Durable Objects at some point.
2026-06-19
4 min read

Everyone's writing code with AI agents today. But the moment an agent needs to deploy something — and needs to sign up and create an account — it slams face-first into a wall built for humans: a browser-based OAuth flow, a dashboard to click through, an API token to copy-paste, a multi-factor authentication prompt to satisfy. For an interactive copilot sitting next to a developer, that's annoying. For a background agent, it's a hard stop.
Today we're rolling out Temporary Cloudflare Accounts for Agents.
Agents can now deploy websites, APIs, and agents right away, without first needing to sign up for an account.

Any agent can now run wrangler deploy --temporary and deploy a Worker to Cloudflare. This temporary deployment stays live for 60 minutes, during which time you can claim the temporary account, making it permanently your own. If you don't, it expires on its own.

Our goal? Let your agent code and ship.
Frictionless temporary accounts matter more than it might first seem:
Background AI sessions have no human in the loop, and are becoming the norm. Any auth step that needs a browser, a copy-paste, or "click here in 60 seconds" means an agent gets stuck and may choose to deploy elsewhere.
Trial-and-error is the agent's superpower. Agents need a tight write → deploy → verify loop. They need cheap, throwaway deployment targets, so they can curl their own output and decide whether they got it right.
Agent platforms are building their own ways for deploying code to "just work" without extra steps or credentials. People are starting to expect that this process just works, without the need to sign up for other services that they've not used before or heard of.
Temporary accounts are built around Wrangler, our Developer Platform command-line interface (CLI) tool that lets developers bootstrap new projects, manage their configurations and resources, and deploy and update them.
Wrangler usage is widely documented online and agents know how to use it very well. But if you hadn’t yet signed in and granted Wrangler permission to your Cloudflare account, when the agent tried to deploy, it would get stuck at the sign-up and authentication step. And you might rightly ask: How do agents and LLMs know that this new --temporary flag in Wrangler exists, so that they actually use it without a human explicitly telling them to do so?
To solve this, we updated Wrangler to prompt the agent with a message that tells it about the --temporary flag:

When the agent discovers this, and then runs **wrangler deploy** again with the --temporary flag, Cloudflare provisions a temporary account for the agent to use, gives Wrangler an API token to work with, and provides a claim URL that the agent can give back to the human.
Make sure you’re using the latest Wrangler release, fire up your favorite coding agent, and write a prompt to deploy a "hello world" app in build mode:
Make a very simple hello world Cloudflare Worker in TypeScript and deploy it using wrangler, don't ask me questions, do the best you can
The agent will run wrangler, pick up the --temporary flag from the output messages, build your script, and deploy it instantly, no human in the loop required:

As you can see, the agent wrote the script, deployed it using the --temporary flag, curled the preview link it got from the output, and verified that the result matches the code.
This is great, but agentic coding is often not about one single deployment. A session can go through a cycle of multiple code changes. This is not a problem: the agent can iterate on the Worker script and redeploy the changes as many times as it wants (within the 60-minute claim window). Type this prompt:
Now change hello world to "hello cloudflare" and redeploy
Look at the agent changing the source code, reusing the previously created temporary account, redeploying a new version and rechecking the result:

At any point, you can claim the temporary account and make it yours permanently. When you click the claim link you will be taken to a page where you can either sign up for or sign in to Cloudflare, and then claim the temporary account that your Worker was deployed to. This includes claiming not just Workers, but resources like databases and other bindings, too.

If you do not claim these temporary accounts within 60 minutes, they will be automatically deleted.
This is just one way we’re eliminating the signup barrier for agents. We recently announced a partnership with Stripe and a new protocol we co-designed that lets agents provision Cloudflare on behalf of their users — creating an account, starting a subscription, registering a domain, and getting an API token to deploy code, with no copy-pasting tokens or entering credit card details. Last month, we collaborated with WorkOS on the launch of auth.md, which anyone can adopt, to let agents provision new accounts using well-established, existing OAuth standards.
There’s a ton going on in this space, and we’re excited to keep making it easier for agents to use Cloudflare, and for developers to make their own apps agent-ready. Temporary accounts are one more step toward frictionless agentic deployments — stay tuned for more.
Temporary accounts have some limitations, and their capabilities may change over time; check the developer documentation for more information and then go build something. Point your agent at Cloudflare, see how far it gets, and tell us what we can improve or what delights you — share what you’ve built on X or hop into the Cloudflare Community.
...and the top 10% by wealth own 90% of the stock market.
So even among the half that do have retirement savings in 401ks and the like it is on average very little compared to how much the truly wealthy have invested.