Planet Cloudflare

Aggregated posts from Cloudflare employees and community

July 13, 2026

July 12, 2026

Cloudflare Workers Tech Talks in Kyoto #2

Blog - Yusuke Wada ·

We held "Workers Tech Talks in Kyoto #2" on July 8, 2026. It was the second Workers Tech Talks in Kyoto, one year after the first one. About 30 people joined, and we had five great talks. But this time, something unusual happened: I, the organizer, couldn't attend! I came down with a fever on the morning of the event. Thanks to rokuosan_dev, who stepped up as the MC, and all the speakers and attendees, the event went on wonderfully without me. This is the report of an event that I hosted but didn't attend, written from the posts and blogs of the participants.

What is Cloudflare Workers Tech Talks?

Cloudflare Workers Tech Talks is an event where developers who are developing using Cloudflare Workers talk about Cloudflare Workers. It has been held multiple times in Tokyo, Osaka, Kyoto, Niigata, Hokkaido, and Fukuoka, and once in Austin, Texas. The feature of this event is that the speakers are free to talk about whatever they want. I often tell the speakers, "Please don't give introductions like 'What is Cloudflare Workers?'". I ask them to talk about whatever they want to talk about.

Venue

The venue was Hatena's Kyoto office, the same host as the first Kyoto event. Hatena is a well-known company that provides many web services, such as blogs and social bookmarks. Special thanks to onk, who not only gave a talk but also took care of everything on the Hatena side. Thank you, Hatena, for supporting the Kyoto events again!

Attendees

We gathered participants through the event page on connpass.

https://workers-tech.connpass.com/event/397441/

We had 33 registrations for 30 seats, and about 30 people joined on the event day. The Kyoto community showed up again!

The Organizer Couldn't Make It

On the morning of the event, I woke up with a fever. I really didn't want to, but I had to announce that I couldn't attend. I asked rokuosan_dev, one of the speakers, to take over as the MC — he replied, "Leave it to me!" and did a fantastic job hosting the whole event while also giving his own talk. I heard the speakers had fun teasing the absent organizer who had invited them. Sorry, and thank you all! This event made me realize that the Workers Tech Talks community can run itself now, which made me a little sad but mostly very happy.

Talks

Five speakers gave talks, and I heard there were lots of live demos. (Photos by rokuosan_dev and luccafort.)

Hono x Inertia.js x Cloudflare Workers

Takafumi ONAKA, an engineer at Hatena, talked about combining Hono with Inertia.js, a framework from the Laravel ecosystem that lets you build a frontend with a server-side mindset. He showed how Inertia works with Hono middleware — the server returns HTML or JSON depending on the X-Inertia header, and the Link component gives you SPA-like navigation. With server-side validation, you can build an app without client-side patterns like useEffect(). It seemed to resonate with the audience as a nice way to build lightweight admin panels.

Exposing a Local LLM Securely with Cloudflare's Beta Services

rokuosan_dev — the MC of the day — talked about exposing a local LLM to the internet securely using Workers VPC and AI Gateway. He demonstrated token-based authentication for accessing local models and layered AI Gateway on top for access control and metrics, so that tools like Claude Code can use the local LLM. He also shared the AI Gateway OpenTelemetry integration he wanted to show but couldn't fit in. Thank you again for MCing!

Introduction to Oxfmt

Yuji Sugiura (りぃ), who develops oxfmt as part of the Oxc project, gave a talk about Oxfmt, the Rust-based formatter that aims to replace Prettier. He explained why formatting speed matters — when it's fast enough, you can format on every edit — and shared the story behind its development. The timeline was full of posts like "I use oxlint and oxfmt every day, thank you!" It's amazing that a tool used worldwide is developed by someone in this community.

The slides: https://leaysgur.github.io/slides/cloudflare_workers_tech_talks_in_kyoto-2/

Harder Stronger Better Faster Agentic Coding

windymelt, who also spoke at Kyoto #1, talked about making AI coding agents safe using static typing and sandboxing. He discussed Scala 3's Capture Checking to enforce what an agent can touch, and showed how Cloudflare Containers and Dynamic Workers can be used as sandboxes for agents. His demo — an app that generates Scala code with AI, compiles it in a Container, and runs it on a Dynamic Worker — didn't quite finish on stage, but he proudly posted right after: "It actually ran!"

The notes: https://scrapbox.io/windymelt/Harder_Stronger_Better_Faster_Agentic_Coding

Distributing NixOS Binary Cache with the Cloudflare Ecosystem

T4ko0522, an 18-year-old Mitou Junior creator whom I invited to speak, presented cf-edgeNix, a NixOS binary cache distribution built on Workers Cache and R2. Serving the cache through Cloudflare reduced his build time from 12 minutes to a little over 3 minutes. It was his first talk at a tech event, and the audience loved it — "The level of the talks is seriously high," someone posted.

Feedback

I asked the attendees to post on X with the hashtag #workers_tech. You can see their feedback here:

https://x.com/search?q=%23workers_tech

Some attendees also wrote about the event:

Janken and Networking

The event wrapped up with a rock-paper-scissors tournament, and the winners got Cloudflare T-shirts and a polo shirt.

After the talks, we had a social gathering with drinks provided by Hatena. Yasuhiro Onishi of Hatena gave an impromptu lightning talk, and at some point a real-time live coding session started — I really wish I could have seen that!

Summary

This was the strangest Workers Tech Talks for me: the first one I organized but couldn't attend. Reading the timeline from my bed, I was moved by how the community carried the event — rokuosan_dev MCing while giving his own talk, five speakers delivering high-level talks with lots of demos, and Hatena supporting everything on site. Thank you to everyone who joined, and sorry again for my absence!

The next event is already scheduled: Cloudflare Workers Tech Talks in Osaka #3 on August 7. This time, I promise to be there!

Here's the group photo, taken by pastak. Everyone is smiling — I'm the only one missing!

July 11, 2026

Terraloop

coey.dev ·

Two tools that run long tasks on Cloudflare without babysitting them: a heartbeat (loops-yaml) that re-prompts the agent, and terrarium running each job and handing back a receipt. Everything else is one markdown file.

July 10, 2026

Jilles started building World Cup Signal

jillesme ·

A source-grounded World Cup research assistant deployed on Cloudflare Workers. It turns current reporting into concise briefings with links to the supporting sources.

Built with Workers, D1, Workers AI, and Agents.

GitHub

July 09, 2026

July 08, 2026

July 07, 2026

July 02, 2026

July 01, 2026

June 29, 2026

Zeke started building Personal Agent

zeke ·

A deliberately minimal AI agent on Cloudflare Workers, built on Think (Agents SDK) and reachable from Telegram.

Built with Workers, Durable Objects, Workers AI, Browser Run, Sandboxes, and Agents.

GitHub

June 26, 2026

June 25, 2026

Craig started building Promptly

craigsdennis ·

Promptly is a Cloudflare Workers app for storing educational AI prompts by slug and presenting them one sentence at a time. It is designed for talks, workshops, and demos where you want to teach a prompt sentence-by-sentence and let the audience take the prompt away.

Built with Workers and KV.

GitHub

Craig started building Pickled

craigsdennis ·

A real-time multiplayer pickleball game built on Cloudflare Workers. Players use their phones as motion controllers to volley a virtual pickleball back and forth on a shared screen.

Built with Workers and Durable Objects.

GitHub

June 24, 2026

June 23, 2026

June 22, 2026

June 21, 2026

If You're Here, Who's Driving?

coey.dev ·

Google and Cloudflare are aiming at 2029 for post-quantum migration. A short note about agents, cryptography, and checking who still has the wheel.

June 20, 2026

Harshil started building Think With Apify

harshil1712 ·

An personal chat agent built on Cloudflare Think. It uses Apify Actors via the Apify MCP server to fetch real web data on demand — the agent pays for web data to get things done.

Built with Workers, Durable Objects, Workers AI, Sandboxes, and Agents.

GitHub

June 19, 2026

June 18, 2026

June 17, 2026

June 16, 2026

Mermaid diagrams, rendered by tldraw

code.charliegleason.com ·

Diagrams are one of those things where the gap between "I want a diagram here" and "there is a diagram here" is just annoying enough to make me skip it entirely. Mermaid solves the authoring side — write plain text, get a chart — but the default SVG output is serviceable rather than beautiful. And I'd been using tldraw for whiteboarding anyway, so I kept wondering if I could pull the two together.

It turns out you can — and the credit for figuring out how goes to Sunil Pai, who shipped a plugin for his blog that does exactly this, complete with light and dark variants. He even pointed at the commit where it all lives. What follows is me retracing his steps for this site, with a few detours of my own along the way.

The version running here works like this: you write a plain mermaid fence in an MDX post, and at build time a Playwright harness renders it through tldraw, writes light and dark SVG variants to public/diagrams/, and embeds them via a manifest the runtime looks up. The worker bundle ships zero bytes of mermaid or tldraw code. Here's what the whole thing looks like:

flowchart TD
  A[Write a diagram in MDX] --> B{Build runs}
  B -->|New or stale| C[Playwright + tldraw renders SVG]
  B -->|Up to date| D[Skip render]
  C --> E[Save light + dark SVG to /diagrams]
  D --> E
  E --> F[Runtime swaps variant via .dark class]

The architecture

There are four moving parts:

  1. The harness — a Vite dev server that serves a page mounting <Tldraw> and exposing window.renderMermaid(source, opts).
  2. The render script — a Node script that walks posts/**/*.mdx, extracts mermaid blocks, decides what's stale, then drives the harness via Playwright to get SVG strings back.
  3. The manifest — app/mdx/mermaid-manifest.json, a flat {normalizedSource: hash} map the SSR runtime can import.
  4. The runtime hook — app/mdx/mdx-hooks.tsx, a renderNode override that intercepts mermaid code nodes and emits a <figure> with two <img> tags.

A Vite plugin (lib/mermaid-plugin.ts) wires it into the dev loop: post edits trigger an in-process re-render and a full browser reload; harness or style config edits trigger a full server restart so the bundled render code actually reloads.

Hashing for stable URLs

Each diagram's output filename is a content hash, so URLs are stable across re-renders and external links don't 404. But there's a wrinkle: when you change your styling code, the hash doesn't change, so cached SVGs won't be re-rendered even though they'd look different.

The fix is a render marker embedded inside each SVG as an HTML comment:

export const RENDER_REVISION = `tldraw-5.1.1-r6`
export const renderVersion = (style: string) => `${RENDER_REVISION}-${style}`
// → <!-- tldraw-mermaid render:tldraw-5.1.1-r6-sleek -->

The renderer checks the marker in any existing file before deciding to skip it. The version string combines the tldraw package version, a manual revision counter, and the diagram's style name. Bumping the revision (r6 → r7) invalidates everything without changing any filenames. External links stay valid. The revision is cheap to bump and free to ignore when nothing style-related has changed.

One gotcha I hit: I bumped the version mid-iteration but cached SVGs still showed the previous value, because I'd changed the style name earlier and the marker already said "indigo." The renderer thought everything was current. Lesson learned — bump before you start tuning, not after.

The harness

scripts/mermaid/harness.tsx mounts a full <Tldraw> instance in a blank page and hangs a function off window:

window.renderMermaid = async (source: string, opts: RenderOpts) => {
  const { shapes } = await createMermaidDiagram(source)
  editor.createShapes(shapes)
  // … select all, export SVG, clean up
  return { light: lightSvg, dark: darkSvg }
}

@tldraw/mermaid's createMermaidDiagram converts a mermaid string into tldraw shape descriptors — geo nodes for boxes and diamonds, arrow shapes for edges. For diagram types it doesn't model natively (sequence diagrams, Gantt charts), it calls an onUnsupportedDiagram callback that falls back to mermaid's own SVG renderer.

The render script launches a Playwright page, navigates it to http://localhost:<port>/harness.html, waits for a window.__harnessReady flag, then calls window.renderMermaid for each pending block:

const { light, dark } = await page.evaluate(
  ([src, opts]) => window.renderMermaid(src, opts),
  [source, opts] as const
)

The manifest as a source→hash bridge

node:crypto doesn't run in Cloudflare Workers, and SubtleCrypto is async and adds overhead to every request. So we can't recompute hashes at SSR time. Instead, the build emits app/mdx/mermaid-manifest.json keyed by normalized source string — the same content that was hashed, normalized to trim whitespace and unify line endings:

{
  "flowchart TD\n  A[Write...] --> B{Build...}": "a3f8c2d1",
  "sequenceDiagram\n  participant Author...": "b9e4a771"
}

The runtime hook imports this JSON and looks up the hash:

import manifest from '~/mdx/mermaid-manifest.json'

const hash = manifest[normalizeSource(node.value)]
if (!hash) return null // fall back to plain code block

return (
  <figure className="mermaid-diagram">
    <img src={`/diagrams/${hash}-light.svg`} className="mermaid-light" alt="" />
    <img src={`/diagrams/${hash}-dark.svg`} className="mermaid-dark" alt="" />
  </figure>
)

Styling

tldraw defaults give you the hand-drawn look with draw font and sketchy strokes. That's tldraw's whole thing and it's lovely, but it didn't feel right for technical diagrams. First real pass: font: "mono", dash: "solid", fill: "none", size: "m" on every shape.

That was better. Then I noticed arrows exported thinner than shape outlines at the same size: "m". Turned out the size token maps to different stroke widths depending on shape type — arrows came out at roughly 3.5 wide, geo shapes at 4.5. I bumped arrows to size: "l" to compensate, which gave stroke-width 5. Too thick.

tldraw's size tokens are fixed — s, m, l, xl, no half-steps. So I added an SVG post-processing step: after export, swap the 5 for a 4. It sits between the two and the outlines feel balanced:

const svg = rawSvg.replaceAll('stroke-width="5"', 'stroke-width="4"')

For color, I wanted the diagrams to match the site's indigo palette — #4f46e5 in light mode, #a5b4fc in dark mode, same as the prose link colors in app/global.css. Another post-processing pass replaces tldraw's default colors. The tricky part was hierarchy: I wanted arrows and text to read clearly, but shape outlines slightly softer. My first attempt used a second, lighter indigo for outlines. Cleaner answer: same hex, lower stroke-opacity. Automatically lighter without maintaining a second color:

transformSvg: (svg: string) => svg
  .replaceAll(TLDRAW_DEFAULT_STROKE, INDIGO)
  .replaceAll('stroke-opacity="1"', 'stroke-opacity="0.7"')

All of this lives in a STYLES map in harness.tsx with a shapeProps, arrowProps, and transformSvg per style. Switching styles means changing one line in scripts/mermaid/style-config.ts:

export const ACTIVE_STYLE = "indigo"

That string flows through to the version marker via template literal, so a style swap automatically invalidates the cache. It's isomorphic, too — you can import it from both the Node render script and the browser harness without issues.

The dev loop

Post edits re-render just the changed diagrams in-process and trigger a full browser reload. Fast enough that it doesn't feel like a build step.

Harness edits or style config edits are a different story. The render script gets bundled into the Vite config chain at startup — it's not re-evaluated on the fly. The only clean way to reload it is server.restart(). The plugin watches scripts/mermaid/** and scripts/render-mermaid.ts and calls server.restart() when they change. Slightly slower, but you're not touching those files during normal writing anyway.

The await import("../scripts/render-mermaid") in the plugin is a dynamic import deliberately. If it were static, esbuild would inline Playwright, Vite, and @vitejs/plugin-react into the compiled vite.config.ts, and the Cloudflare Vite plugin would chase that dependency graph and throw on node:worker_threads. Dynamic import keeps the bundle clean.

Sequence diagrams and the fallback path

@tldraw/mermaid supports flowcharts and a handful of other types, but not sequence diagrams. Here's what one looks like — this one falls through to mermaid's own SVG renderer via onUnsupportedDiagram:

sequenceDiagram
  participant Author
  participant Vite
  participant Tldraw
  Author->>Vite: save post.mdx
  Vite->>Tldraw: render pending diagrams
  Tldraw-->>Vite: light + dark svg
  Vite-->>Author: full-reload

Even though it takes the fallback path, the output still gets imported into tldraw and exported through the same style pass — so it comes out looking consistent with the native diagrams, same mono font and indigo palette. The boundary is structural rather than visual: tldraw doesn't model sequence diagrams as shapes, but you wouldn't know it from the result.

Per-fence meta options

Fences carry meta options after the language tag. Two are wired up: width caps the display size, and style picks a different preset from the STYLES map. The diagram below sets both — it's capped narrow and rendered with the sleek preset (tldraw's default ink instead of the site's indigo), so you can see it sitting next to the indigo diagrams above:

flowchart TD
  Idea --> Sketch --> Build --> Ship

width and style travel through the pipeline by different routes, because they change different things. width is purely presentational, so parseMetaString in app/mdx/mdx-hooks.tsx reads it at runtime and sets an inline max-width on the figure — the SVG itself is identical. style changes the pixels, so it has to be resolved at render time: extractMermaidBlocks reads it off each fence, the render script hands it to window.renderMermaid(source, opts, style), and the harness looks it up in STYLES. The runtime never needs to know — it still maps source → hash → SVG, and the styled output is already baked into the file.

The one subtlety is cache invalidation. The filename hash is source-only (for stable URLs), so swapping a fence's style wouldn't change the filename. Instead the active style is baked into each SVG's render marker (…-r6-sleek vs …-r6-indigo), so changing style="..." makes the marker mismatch and that one diagram re-renders in place — everything else stays cached.

What the CSS looks like

The display swap is just CSS. Two images, default hidden, one shown per theme:

.mermaid-diagram {
  max-width: 36rem;
}

.mermaid-light { display: block; }
.mermaid-dark  { display: none;  }

.dark .mermaid-light { display: none;  }
.dark .mermaid-dark  { display: block; }

The .dark class on the <html> element is already managed by the site's theme system, so this just works.

What to play with next

The STYLES map is the obvious place to start experimenting — different fonts, fill styles, different brand colors. Each style entry is self-contained with its own shapeProps, arrowProps, and transformSvg, so you can add a new one without touching anything else. Once it's in the map, any fence can opt into it with style="yourstyle" (see the per-fence meta options above).

And if you want finer control over the fallback path, onUnsupportedDiagram gets the raw mermaid source and can do anything with it — custom renderers, a placeholder, a hard error. Currently it just calls back into mermaid's own library, which is fine.

The part I like most is that the author experience stays completely boring. Write mermaid, save the file, see a diagram. The pipeline is only visible when something goes wrong, which is exactly where you want complexity to live.

June 15, 2026

never waste a token

Solving the decision problem ·

durable inference: resumable streams, crash recovery, and why the LLM request shouldn't die with your process.

June 14, 2026

Yusuke started building Memo2task

yusukebe ·

Write a memo, an AI turns it into a task, and you get notified when its time comes.

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

Confidence started building Think Starter

megaconfidence ·

A starter for building AI chat agents on Cloudflare with the Think framework: a stateful chat agent (streaming, persistent memory, tool calls) served with a minimal React UI, built and deployed with Vite.

Built with Workers, Durable Objects, Workers AI, Sandboxes, and Agents.

GitHub

June 12, 2026

Jilles started building Super Images

jillesme ·

A small demo app for Cloudflare Images, built with TanStack Start on Cloudflare Workers and D1. Upload a large product photo, optionally apply background removal, and serve multiple responsive product-card variants from one stored image.

Built with Workers, D1, and Cloudflare Images.

GitHub

June 10, 2026

Confidence started building Personal Agent

megaconfidence ·

A deliberately minimal AI agent on Cloudflare Workers, built on Think (Agents SDK) and reachable from Telegram.

Built with Workers, Durable Objects, Workers AI, Browser Run, Sandboxes, and Agents.

GitHub

June 08, 2026

Zeke started building Login With Cloudflare

zeke ·

This is a demo and reference implementation for Cloudflare self-managed OAuth clients, introduced in the self-managed OAuth clients announcement and documented in the Cloudflare OAuth docs.

Built with Workers and KV.

GitHub

June 06, 2026

June 05, 2026

June 04, 2026

June 02, 2026

Zeke started building Free Retro

zeke ·

Free Retro is a real-time retrospective board. Create an unlisted retro, share the link with your team, and delete it when you are done.

Built with Workers and Durable Objects.

GitHub

Cloudflare Workers Tech Talks in Hokkaido #2

Blog - Yusuke Wada ·

I hosted "Workers Tech Talks in Hokkaido #2" on June 3, 2026. It was the second Workers Tech Talks held in Hokkaido, Japan's northernmost region known for its beautiful nature and delicious food. Following the success of the first event last September, we came back to Sapporo for another evening of Cloudflare Workers talks. More than 40 people joined, and the atmosphere was just as warm and enthusiastic as the first time. We had four talks covering a wide range of topics, from feature flags to GIS and AI agents.

What is Cloudflare Workers Tech Talks?

Cloudflare Workers Tech Talks is an event where developers who are developing using Cloudflare Workers talk about Cloudflare Workers. It has been held multiple times in Tokyo, Osaka, Kyoto, Niigata, Hokkaido, and Fukuoka. At the end of last year, we also held the first event in Austin, Texas! The feature of this event is that the speakers are free to talk about whatever they want. I often tell the speakers, "Please don't give introductions like 'What is Cloudflare Workers?'". I ask them to talk about whatever they want to talk about.

Venue

The venue was again F-60 (エフロクマル) 9F, located in the heart of Sapporo — the same place where we held the first Hokkaido event. The 9th floor offers a great view of the city, and it's a comfortable space that fits our group perfectly. Thanks again to MIERUNE for their support in making this event happen!

Attendees

We gathered participants through the event page on connpass.

https://workers-tech.connpass.com/event/393524/

We had 41 registrations, and many of them joined us on the event day, including several people from MIERUNE. For a second event in Hokkaido, it was great to see such strong continued interest in Cloudflare Workers.

Talks

Four speakers gave talks covering a wide range of topics, from Flagship to GIS, AI agents, and databases with Hyperdrive.

Flagship Story

ねこや, a software engineer at ReMotive LLC. and MIERUNE Inc., talked about Flagship, Cloudflare's feature flag service that recently entered public beta. He started by explaining what feature flags are and the different types of them. Then, he configured Flagship live while showing the Cloudflare dashboard, and finally demoed a simple app built with Hono to show the flags working in action. He has also written a detailed article about it.

Cloudflare GIS × AI Agent Development

西尾 悟 (Satoru Nishio) presented about building a GIS (Geographic Information System) agent powered by AI on Cloudflare. He showed how Workers, Workers AI, Durable Objects, and Containers can be combined to let users interact with geospatial data through conversation — searching satellite imagery, running analysis like NDVI, and visualizing results on a map. At the end, he gave a demo that really wowed the audience: while chatting, the agent retrieved GIS information for a specified location and rendered it on the spot. It was fascinating to see GIS and AI agents come together on the Cloudflare stack.

The slides: https://speakerdeck.com/nokonoko1203/cloudflaretegis-x-aiesientokai-fa

Self-hosted DB with Hyperdrive

すばる (Subaru) talked about connecting a self-hosted PostgreSQL database to Cloudflare Workers using Hyperdrive. Working on a university timetable app, she migrated the backend to Hono and Workers while keeping her own PostgreSQL — chosen for flexible SQL-based search, with Japanese full-text search as something she wants to do in the future. She walked through the setup, from TLS encryption to binding the database with Hyperdrive for persistent connections and query caching. It was an ideal use case for Hyperdrive, which made it especially memorable.

The slides: https://slides.su8ru.dev/260603-workers/

Dynamic Workers

Yusuke Wada (me), gave a talk about Dynamic Workers. I introduced what Dynamic Workers is and some use cases including Code Mode. At the end, I demoed hono-eval and introduced Kakera, both built using Dynamic Workers.

The slides: https://speakerdeck.com/yusukebe/dynamic-workersnituite

Feedback

I asked the attendees to post on X with the hashtag #workers_tech. You can see their feedback here:

https://x.com/search?q=%23workers_tech

Some attendees also wrote about the event:

Networking

After the talks, we had a social gathering where attendees enjoyed great conversations. This time, Tenshoku Draft, a service run by Livesense, kindly sponsored the drinks, providing two kinds of their original craft beer. Thank you to Tenshoku Draft! The networking session was a wonderful chance for everyone to connect and share their experiences with Cloudflare Workers.

Summary

The second Workers Tech Talks in Hokkaido was another great success! It was impressive to see more than 40 people join, and all four talks were a lot of fun. Originally, six speakers were scheduled to talk, but a typhoon on the day prevented two of them from making it, so we ended up with four. I hope the two speakers will get a chance to talk at another occasion! Even so, it was a thoroughly enjoyable event. Hokkaido has a vibrant tech scene, and events like this help spread Cloudflare adoption further in the region. Thank you to MIERUNE for supporting the venue, to all the speakers for sharing their knowledge, and to everyone who joined us. We look forward to the next one!

May 31, 2026

Yusuke started building Generative Ui Playground

yusukebe ·

CopilotKit が提唱する Generative UI Spectrum の 3 バンド (Controlled / Declarative / Open-Ended) を、同一題材「レストラン提案」で並べて見せるデモ。

Built with Workers, D1, Workers AI, and Agents.

GitHub

May 29, 2026

Harshil started building Swarmflare

harshil1712 ·

Swarmflare is a Cloudflare-native demo of an AI chat agent that can split broad goals into a bounded swarm of specialist workers, run those workers in parallel, track progress live in the browser, and synthesize a final answer.

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

May 28, 2026

Craig started building Constituent Bridge

craigsdennis ·

Constituent Bridge is a multilingual smart inbox demo for Members of the European Parliament.

Built with Workers, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

May 27, 2026

Kristian started building Screendrop Worker

kristianfreeman ·

The cloud backend for Screendrop, an open-source native macOS screenshot tool. This worker handles uploading, storing, and sharing screenshots and screen recordings via shareable links.

Built with Workers, D1, and R2.

GitHub

Browsers in the Cloud

Zeke Sikelianos ·

Let your AI agents drive real web browsers locally and in the cloud.

May 23, 2026

Cursing Agents

coey.dev ·

An experiment comparing direct, hostile, and verification-focused instructions across 36 coding-agent runs with executable checks.

May 22, 2026

May 21, 2026

Ade started building Lempicka

adewale ·

Lempicka is a Cloudflare Worker that turns uploaded photos into portraits inspired by Tamara de Lempicka. It serves a small web app, sends images to Replicate for image-to-image generation, and keeps a short-lived gallery of recent results in Cloudflare KV.

Built with Workers and KV.

GitHub

May 20, 2026

Yusuke started building skills.yusuke.run

yusukebe ·

A personal, curated collection of skills — small, focused Markdown documents that describe how to do specific things with specific tools. Designed to be consumed by coding agents (Claude Code, Cursor, etc.) and by humans.

Built with Workers.

GitHub

May 19, 2026

May 18, 2026

May 15, 2026

desk and living-artifact

coey.dev ·

Two tiny Cloudflare-backed devices. desk installs apps with git push. living-artifact updates its own firmware over Wi-Fi with signed releases and A/B OTA rollback.

May 14, 2026

May 13, 2026

May 12, 2026

May 08, 2026

May 07, 2026

James started building Quickglance

jamesqquick ·

See your landing page through a first-time visitor's eyes. Paste a URL, describe what visitors should walk away knowing, and get an honest AI-generated read on whether the page actually delivers that message.

Built with Workers, KV, Workers AI, and Browser Run.

GitHub

Fayaz started building Screendrop Worker

fayazara ·

The cloud backend for Screendrop, an open-source native macOS screenshot tool. This worker handles uploading, storing, and sharing screenshots and screen recordings via shareable links.

Built with Workers, D1, and R2.

GitHub

May 06, 2026

Ade started building Python By Example

adewale ·

Python By Example is a Go By Example-inspired learning site for Python 3.13. It presents small literate examples with prose, source fragments, expected output, official Python documentation links, and an editable runner.

Built with Workers.

GitHub

May 05, 2026

Confidence started building Agent Starter

megaconfidence ·

A starter template for building AI chat agents on Cloudflare, powered by the Agents SDK.

Built with Workers, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

May 04, 2026

Craig started building MSPaintify

craigsdennis ·

A Cloudflare Python Worker that turns photos into delightfully terrible MS Paint-style drawings using OpenAI's GPT-Image-2 via AI Gateway.

Built with Workers, KV, R2, Workflows, and Workers AI.

GitHub

May 01, 2026

April 29, 2026

April 28, 2026

April 26, 2026

Confidence started building Deep Research Agent

megaconfidence ·

A deep-research agent for Cloudflare Workers. Email a question or open the chat — it searches the web in a real headless Chrome, reads promising sources, captures structured data or screenshots, and replies with a cited Markdown / HTML report.

Built with Workers, Durable Objects, Workers AI, Browser Run, Email Workers, and Agents.

GitHub

April 25, 2026

James started building Quickcut

jamesqquick ·

Collaborative video review, built on Cloudflare. Upload up to 5GB, stack new versions, share a link, and collect timestamped feedback from your team or clients — no account required for reviewers.

Built with Workers, D1, Durable Objects, Workflows, Workers AI, and Email Workers.

GitHub

Email is crazy

Sam Khawase ·

A recap of all the failed projects I attempted.

Email is crazy

Sam Khawase ·

A deep dive into how email actually works — SMTP, MTAs, SPF/DKIM/DMARC authentication, spam filtering and TLS — traced step by step from Alice to Bob.

April 24, 2026

April 23, 2026

April 22, 2026

April 21, 2026

Fayaz started building Cloudflare Voice Agent Workshop Demo

fayazara ·

A voice-powered customer support agent built on Cloudflare Workers using the experimental @cloudflare/voice SDK. Users speak to the agent in the browser and it responds with natural speech, backed by Workers AI for STT, LLM, and TTS.

Built with Workers, Durable Objects, Workers AI, Voice, and Agents.

GitHub

Fayaz started building Cloudflare for Startups

fayazara ·

Internal tool for managing the Cloudflare for Startups credit program. Startups apply for Cloudflare credits through a multi-step wizard, and an automated verification pipeline scores and triages applications for the team.

Built with Workers, D1, Workers AI, and Email Workers.

GitHub

Fayaz started building React + Vite + Hono + Cloudflare Workers

fayazara ·

This template provides a minimal setup for building a React application with TypeScript and Vite, designed to run on Cloudflare Workers. It features hot module replacement, ESLint integration, and the flexibility of Workers deployments.

Built with Workers and D1.

GitHub

April 20, 2026

Ade started building Demoscene

adewale ·

demoscene is a Cloudflare Worker that scans a curated set of GitHub accounts and publishes a reverse-chronological feed of public Cloudflare projects from the Cloudflare DevRel team.

Built with Workers, D1, and Queues.

GitHub

Jilles started building Cloudflare Queue + Anthropic Batch API demo

jillesme ·

A tiny Cloudflare Worker that takes user feedback over HTTP, drops it on a Cloudflare Queue, and uses the consumer batch to create a single Anthropic Message Batch job. A cron trigger polls Anthropic for results and writes them back to D1.

Built with Workers, D1, and Queues.

GitHub

April 19, 2026

Harshil started building Agentic Inbox

harshil1712 ·

A self-hosted email client with an AI agent, running entirely on Cloudflare Workers

Built with Workers, R2, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

April 18, 2026

Craig started building Booth Duty

craigsdennis ·

Cloudflare booth demo built around the Agents Never Sleep sticker robot.

Built with Workers, D1, R2, Durable Objects, Workers AI, Voice, and Agents.

GitHub