🐏 mogoz

Search

SearchSearch

tailscale & cloudflare

May 25, 2025, 4 min read

tags : WireGuard, Selfhosting, VPN, DNS

Interesting CF products

CF redirect rules cheat sheet (namecheap)

CF workers

Some notes about workers

  • Why v8? workers is primarily a JS serverless runtime, not wasm so we kind of just get wasm support as a bonus. (See WebAssembly)

WebAssembly & Golang in CF workers

Other resources

Cloudflare Workflows

  • cf workflows let you wait on particular event for human input:
    • POST: /accounts/{account_id}/workflows/{workflow_name}/instances/{instance_id}/events/{eventName}
  • cloudflare workflows are built on top of workers, they are written inside an worker only, but they need to be BINDED.
  • We can bind multiple workflows to the same worker

Relationship between Cloudflare workers <> CF workflows

  • We need a worker binded to a workflow so that we can trigger the workflow
  • There’s no other way to create a workflow other than to declare it via a worker
  • The workflow step instances are probably individual workers which are abstracted away from the end user
  • One worker can be binded to multiple workflows.
  • When defining the workflow in the binded worker we do define parameters (in Params) but these are not specific to any workflow. These are in-code worker specific construct/convention. Which is why, currently in workflows web UI, you’d not see any “typed” way to provide parameters. It would accept just about any JSON you provide.
  • You’d usually trigger the workflow via the REST API or via the binded Worker. Trigger via the binded Worker is more preferable to me as it allows for better error handling and any other processing. Also the Workflows REST API endpoint is not very well documented.
  • You’d want to store the state of the workflow somewhere, for simpler setups, you’d probably trigger the workflow directly from your application code and either wait or let the workflow steps themselves update the state back in your database. But for slightly more complex usescases you might want to consider using a queue which in turn triggers the workflows.

Feedbacks

I would personally say workflows (and queues) are not ready for that kind of volume, they simply cant scale right now. Funnily enough workflows when they were in their BETA period were a pretty flawless platform, but since last week, only around 20% of our workflows ever actually run, around 50% get stuck, and then the other 30% don’t even trigger (if you are using dead-letter-queues they end up getting filled up).

You will also never manage 4,500 instances running at the same time, we got up to say 350ish running at the same time, the rest just queued.

Until they fix the issues of scale, maybe consider another platform. Our company has basically had to turn some features off, that we built entirely on workflows and queues, and we are now considering something like temporal.

From my screenshot you can see we have over 5K stuck workflows, and we have around 3K+ messages in dead letter queues because workflows failed to even be instantiated. Before last week we ran nearly 1 million workflows in a month.

If they can get the issues sorted out, its probably the best workflow and queue platform l have used.

Tailscale

How it works

  • Tailscale works on Linux systems using a device driver called /dev/net/tun
    • tun allows us to instantiate the VPN tunnel as though it were any other network interface like Ethernet or Wi-Fi

Tailscale resources

Tailscale vs OpenZiti

Graph View

tailscale & cloudflareWireGuardSelfhostingVPNDNSHTTPWebAssemblyGolang

Backlinks

  • No backlinks found