Cloudflare Workers .NET samples
Eight worker samples written in C# and compiled to WebAssembly, from a single JSON response to a full telemetry pipeline that uses cron, D1, queues, a Durable Object and the Cache API. Every sample has a matching page here, and all of them talk to the worker that Aspire starts locally on port 8787.
Cloudflare.Workers.Hosting 0.4.0.NET 10Blazor WASMwrangler dev
What is running
The C# worker in src/HelloWorker is compiled to WebAssembly (NativeAOT) and executed by
workerd through Wrangler — there is no .NET server process. This Blazor WebAssembly app
calls that WASM worker over HTTP. Locally, KV, R2 and D1 are simulated by Wrangler, so nothing is
uploaded to Cloudflare.
Worker API
http://127.0.0.1:5050 (same origin)
KV namespace
dotnet_test
R2 bucket
dotnettest
Queue
dotnet-queue
Request basics
JSON responses, a proxied fetch, a 302 redirect and a validated JSON POST — the starting point of the worker.
/api/json/api/proxy/api/policy
Cache API
Worker-side caching through caches.default: the first request is a miss, the next ones are hits, and a purge makes it a miss again.
caches.default
KV storage
Write up to 64 characters into one of three fixed keys and read the values straight back.
env.KVdotnet_test
R2 bucket
Upload a file of at most 1 KB, download it again and delete it. Every upload lands on the same key.
env.R2dotnettestsample_file.txt
Queues
A producer puts short messages on dotnet-queue, a consumer picks them up and stores the result in KV.
env.QUEUEcode-queue handler
Scheduled task
An hourly cron writes a run record to KV; the page shows the latest value and the run history.
triggers.cronscode-scheduled handler
D1 database
Full CRUD against the items table of the dotnet database: create, list, edit and delete rows.
env.DBdotnetitems
Weather sensors
The end-to-end pipeline: cron and D1 pick the due sensors, a queue drives the consumer, a Durable Object rate gate serialises the weather API calls, and the reading lands back in D1.
triggers.cronsenv.DBdotnet-telemetryRATE_GATE
Running it locally
dotnet run --project AppHoststarts this frontend and Wrangler together.- The worker listens on
http://localhost:8787; the frontend reads that URL fromwwwroot/appsettings.Development.json. - State lives in
.wrangler/state/v3(KV, R2, queues and the cache), so results survive restarts. - The scheduled sample is registered as an hourly cron;
wrangler dev --test-scheduledalso exposes/__scheduledso the cron can be triggered on demand from the Scheduled task page.