"Over the past year, we’ve seen a shift in what Deno Deploy customers are building: platforms where users generate code with LLMs, and that code runs immediately without review. That code frequently calls LLMs itself, which means it needs API keys and network access.
This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding."
It's freely available to anyone - the data (after securely hashing IPs) is provided as a service for everyone in the open podcast system.
There is a bit about the data api in the privacy policy [1]. Feel free to engage over on the github repo if you are blocked on anything or to chat about it [2].
> We've been running smoothly since Sept 2022, now measuring over 15 million podcast downloads every month across more than 1600 shows
Knock wood, but OP3 podcast redirecting has never had an single outage since it launched in Sept 2022.
Turns out Cloudflare Workers do a great job at simple http redirecting via their hundreds of edge locations, even during extended outages of the other parts of their stack.
Podcasting is open in many ways, but RSS-based podcast apps have no idea what shows are "hot in cleveland" or have related listener bases, etc outside of their own app.
When shows start using OP3, they open up these (listener privacy-preserving) stats to _any_ app, and set themselves up for future discovery / inbound opportunities on this basis.
> But what is the source? Who is typically hosting these? Audio is easier to distribute than video, but aren’t most podcasts hosted on a handful of large services?
Denoflare now has experimental support (v0.6.0+) for deploying ESM-based Typescript workers (including Wasm) not only to Cloudflare Workers, but three other edge runtimes - without wrangler, deployctl, the supabase cli, or the aws sdk
I kicked the tires on this with a pure TS implementation of the protocol called kv-connect-kit that gives you the KV client api in any Javascript runtime (including Cloudflare workers, which does not have anything Deno namespace related)
firesky.tv dev here - do you have javascript enabled?
If so, you should see everything posted to Bluesky in one view, like a massive chatroom.
Use the filter button to monitor for keywords/accounts etc. To me, this is probably the more long-term useful and non-brain-destroying use of the site.
So much so that I wrote Denoflare (https://denoflare.dev/) to make writing Cloudflare Workers using standard Deno a breeze: no wrangler, toml, webpack, npm etc required
Cloudflare seems to be disciplined about releasing solid lower-level platform building blocks first (e.g. durable objects), and leaving the "developer go-to framework for their advanced Worker stuff" to be built on top later.
Seems like a smart approach to me, but I agree the space is moving fast and even though they release stuff at a pretty rapid pace, it never seems fast enough for early adopters
Correct - denoflare scripts are served in a permissionless Deno worker locally - even the Deno namespace is unavailable, just like on Cloudflare.
Developing the worker in Deno brings you the benefit of first-class support for typescript and ESM-modules in your worker, and no need for Node polyfills.
Once you deploy your worker, it runs like any other javascript worker on the magical Cloudflare V8 worker runtime.
Author here: yes this is exactly the goal of denoflare, I started it before miniflare existed, and Deno seemed much more aligned with the Cloudflare Worker model than Node, honestly.
With denoflare, you can serve your Cloudflare Worker script locally and deploy it to Cloudflare with a single tool, without the need for Wrangler, Node, NPM, or a separate bundler.
Also makes writing/deploying ESM-module-based workers trivial - can even deploy a CF Worker to your own account from a URL, e.g. [1]
This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding."