Cloudflare Drop is live. We tested it at launch.

What we saw deploying through it

We dropped a zip through cloudflare.com/drop within hours of launch. The flow, exactly as observed: the dropzone ("Drop a folder. Or a zip. Summon your site - HTML, CSS, JS.") takes a folder or zip with no login; a terms dialog appears ("By deploying, you agree to Cloudflare's Terms of Service"); accept, and seconds later the screen reads "Your site is live" with the site on a public URL shaped like drop-{id}.{words}.workers.dev, which places Drop on Workers static assets rather than Pages. A countdown starts immediately: "Claim (59:38)", alongside "Copy claim link" and "Deploy another." So the leak's one-hour figure is confirmed: sixty minutes to claim an anonymous deployment before it expires, and the claim link is portable, so the person who drops does not have to be the account that keeps it.

The served page itself is public, edge-cached, and carries no access gating of any kind. Two playful details: the dropzone is multiplayer, showing other visitors' live cursors ("Matt", "Priya", "Riley" were dropping files alongside us), and the success screen boasts your site "is reachable within ~32ms of 95% of the world's Internet-connected population." Credit where due: it is the lowest-friction deploy Cloudflare has ever shipped, and a claimed site graduates into the full Workers platform, DNS, HTTPS and DDoS protection included.

The pre-release screenshots showed four post-claim setup cards in the dashboard: add a domain, control access (Worker policies), observability, and "Markdown for Agents." Those live behind the claim step, not in the anonymous flow we tested.

Anonymous-first is the notable part

Netlify Drop and Vercel Drop both require an account before anything goes live. Drop inverts that: the site is live before Cloudflare knows who you are, and the account only enters when you want to keep it. Publish first, identify later. That ordering is the whole trick, because the person (or agent) holding a folder of HTML wants to see it on a URL now, not after a signup form.

We know that pattern well, because it is exactly how Stacktree works: anonymous publish first, a claim step to keep it. Cloudflare arriving at the same funnel independently is the strongest validation the no-ceremony model has had yet. It also makes Drop the sixth major entrant in twelve months to converge on "AI makes HTML, it needs a URL, ceremony is the enemy": Shopify's internal Quick, OpenAI's Codex Sites, here.now, Vercel Drop, Notion's HTML block, and now the company that runs a fifth of the web.

Markdown for Agents: AEO goes native

The most interesting card in the flow is not the dropzone. "Markdown for Agents: make your site easy to explore for agents, showing up more in AI conversations," with an enable button. Cloudflare is shipping agent legibility as a one-click hosting feature: a Markdown rendition of your site for AI crawlers and assistants, in the same checklist as DNS and HTTPS.

That confirms something we have bet on for a while: how a page reads to an agent is becoming a property of hosting, not an SEO afterthought. Note the mechanism Cloudflare chose, though: content negotiation (serve the agent a Markdown rendition of the real page), not another static manifest file. That matches what our own crawler logs show, where AI bots overwhelmingly fetch regular pages rather than the llms.txt-style files the industry spent a year adding. Stacktree ships Markdown content negotiation and WebMCP for the same reason. When Cloudflare puts "showing up more in AI conversations" on a setup card, answer-engine visibility has officially gone mainstream, and it is converging on the page itself being legible, not sidecar files.

What is still unknown

• Documentation. There are no official docs yet; everything here is verified by use, not by reference. Docs may change limits and behavior.
• Limits and pricing. File size caps, site counts, free-tier boundaries: all unknown.
• What "control access" really offers. Worker access policies read like team access control (authenticate viewers against a policy), not a private-by-default share link. Whether Drop grows a lighter-weight gate for sending a deliverable to a client is unknown.
• Any agent-facing path. The flow shown is browser drag-and-drop. No API, CLI, or MCP surface is visible for Drop itself.
• Update semantics. Whether a claimed Drop site can be replaced in place at the same URL, or each drop is a new deployment, is not observable from the screenshots.

Drop or a publish primitive

The boundary that sorted the first five entrants sorts this one too: apps and pages are different shapes. If the folder you are holding is a site that belongs on your Cloudflare account, behind your domain, with observability and access policies, Drop looks like it will be a lovely on-ramp, and the anonymous first hour removes the last excuse not to try it.

If the thing you are holding is an artifact (a report for a client, a dashboard your agent regenerates nightly, a prototype that needs feedback rather than infrastructure), the trade flips. An artifact wants a private, unguessable URL by default because agent output routinely embeds real data. It wants replace-in-place so thirty revisions do not mean thirty URLs. It wants gates a recipient can pass without an account, and it increasingly wants to be published by the agent itself, over MCP or an API, with a read on how it landed afterwards. That half of the category is still the half the platform drops leave on the table, and it is the half Stacktree is built for.