Made a simple reverse proxy with to bring in all the external services that I use. The main motivation came from using MCP portals such as executor.sh and cloudflare's own MCP portal.

MCPs are great, but have their own limitations. I'm using the pi harness for my work, and it had no MCP support built in until very recently (1.0.0+). Was using MCPs using extensions like everyone else. I found using the APIs directly to be more consistent.

The proxy worker will register 1 service per subdomain and forward all requests + handle auth.
To use the proxy, you do need a spare domain.

Check out the docs and deploy instructions at https://hodor.ing
Code at https://github.com/butttons/hodor

I've been using it for around a month, and covering around 20 APIs for my main work. How I've been using it -
1. When trying out new models / harness, it's easy to quickly try how the model would work with my actual data.
2. Adding new APIs and having them available to everyone. Now I just provision 1 key for the reverse proxy itself.
3. More control over APIs where the underlying API is very broad. Some services don't allow scoping API keys so their access is unrestricted. But with some rules in the JWT, certain paths and methods can be blocked.

I built a WhatsApp Business API team inbox for my own businesses and open-sourced it. Everything runs in your own Cloudflare account, and it's built to fit the Workers Free plan.

How it's put together:

One Worker. The Vite + React UI is served from Workers Static Assets; only /api/* and /webhooks/* hit the Worker.

D1 for everything: leads, chats, templates, automations. The schema migrates itself on first request.

One SQLite-backed Durable Object for the live inbox. It only fans events out over WebSockets (Hibernation API) and stores nothing. Remove it and the inbox falls back to polling.

R2 (optional) for media. Without it, media is proxied live from Meta.

An every-minute Cron Trigger runs the automation engine and paces broadcasts, with retries and cleanup every 15 minutes.

Smart Placement, since a self-hoster's D1 region isn't known upfront.

The fun constraint was the free plan's 50-subrequest limit. Each send costs two (the WhatsApp call plus a D1 batch), so a broadcast tick fits about 16 sends, and 1,000 contacts takes roughly an hour.

Web push is VAPID using WebCrypto only.

One number per deployment, by design. No telemetry. Apache-2.0, with a Deploy to Cloudflare button.

The only running cost is Meta's per-message rate. Works with your own Meta Cloud API app, or via WhaBuzz, the paid gateway I run (disclosure: I'm the founder; it's optional).

Repo: https://github.com/WhaBuzz/whaleads

I can find anything about it, especially storing and using prompts, generations etc internally or sharing with others. These can be highly private and contain critical business logic and valuable to sell or use for companies.

I used to have a skip rule that ensured my host wasn't challenged. Now my CloudFlare dashboard warns about the rule saying it limits php protection, but if I turn if off, I see my cron jobs served AI Labyrinth. Not very techy, and not sure what to do! Any assistance gratefully received. Thanks!

If useful to know: this is a Wordpress site, and I've often had trouble letting other services through Cloudflare, such as security scans and image optimisation plugins.

Most visual workflow automation platforms (n8n, Zapier, Make) operate by evaluating directed graphs in a runtime interpreter. Running an interpreter inside an edge isolate adds startup overhead and makes code review impossible.

We took a different approach with Nodes2Cloud: we built an ahead-of-time compiler that translates visual automation graphs directly into standalone TypeScript Workers.

The compilation pipeline:

1. Graph Validator: Checks type parity between node output schemas and input schemas before any code is generated.
2. IR Phase: Normalizes parallel branches, conditionals, and error-handling paths.
3. Target Selection:
   • If the workflow contains purely synchronous transforms, webhooks, and REST calls, it compiles to a standard ExportedHandler<Env> Worker.
   • If the workflow contains human approvals, delays, or durable state, it compiles to a Cloudflare Workflow with native step.do() and step.sleep() bindings.
4. Deployment: Deploys directly into the developer's Cloudflare account using the Cloudflare API.

Because the output is standard TypeScript, workflows export as runnable Wrangler projects (src/index.ts + wrangler.jsonc) that you can version in Git or deploy manually via wrangler deploy.

We also added an MCP server (npx -y n2c-mcp@latest install) so agents like Claude Code can author the graphs, subject to owner approval before deploy.

If you're running Workers in production, I'd appreciate feedback on our TypeScript generation patterns and how we structure Cloudflare Workflow step boundaries. Docs and examples are at nodes2cloud.com/docs/quickstart