Expose public URLs for wrangler dev

[NAlexPear]

💡 Feature request

Enable public access of wrangler dev workloads.

Describe the feature

This feature request is the opposite of cloudflare/wrangler-legacy#1820 (and any other "run workers locally" requests): I love that wrangler dev runs workloads on edge servers, but it's unclear if accessing those workloads publicly is possible. Being able to use those workers at an auto-generated, public URL would be ideal.

The specific use-case: most/all of my development work is not done locally, so exposing dev workloads on localhost is incompatible with the way I work across distributed services in the cloud and across providers. Even more specifically, I'd really like to be able to more easily work on workers that are themselves webhook endpoints for other services (like e.g. Stripe).

Describe the alternatives

My current workaround is to either publish the thing to a specific subdomain and then tail the logs or, more often, to spin up something like localtunnel to use as a temporary webhooks endpoint. The first solution is much slower than I expect an equivalent wrangler dev would be. The second solution is both cumbersome and somewhat silly conceptually, since wrangler dev is already tunneling from the edge to localhost and my tunnel is sending that data right back into the public realm through yet-another-network.

Skipping that extra hop altogether and enabling publicly-accessible workloads during dev would improve my Workers workflow considerably!

It's also entirely possible that I'm mis-reading the documentation. If it's already possible to access dev workloads publicly, then consider this a feature request for updated and clarified docs.

[Electroid]

This is possible for us to build. I'd be curious to get your input on how we could do it:

1. As you mentioned, we could generate a random URL: <random>.example.com, but then how could you test a specific route or subdomain? Would you be ok with this being publicly accessible?
2. We could generate a cookie, that allows you to visit the exact URL, <route>.example.com, and run it against the dev Worker. You would need to use this cookie, likely in browser, but we could output it so it can be used by curl or something else.

[NAlexPear]

Thanks for the response!

Would you be ok with this being publicly accessible?

For many of my needs (i.e. dynamically-configured webhooks for third-party services), the endpoint would have to be public. And that's perfectly fine with me, as long as that public state is both clear and optional. wrangler dev --public or some equivalent would probably be the best so that I could opt for a public endpoint at a time of my choosing without needing to modify a static configuration file.

We could generate a cookie, that allows you to visit the exact URL, .example.com, and run it against the dev Worker. You would need to use this cookie, likely in browser, but we could output it so it can be used by curl or something else.

I don't think it's possible to configure any major webhook-based service to also send along a cookie, so that solution wouldn't really serve my needs.

As you mentioned, we could generate a random URL: .example.com, but then how could you test a specific route or subdomain?

For the URL itself: randomly generating subdomains at a workers.dev domain would be fine as long as it's easy to automate using that URL after wrangler dev starts, whether that means injecting the generated URL into a file or spitting the resulting URL out in an awk-able way.

To avoid that ☝️ song-and-dance, though, it would also be nice to request a subdomain up-front, e.g. wrangler dev --subdomain my-feature-branch --public. This is similar to what localtunnel does, where requests for subdomains that are already-in-use are rejected or default to a randomly-generated URL. Thinking about this further, it would also make sense to me that one could specify a subdomain and a host, as long as that host is already configured with a Cloudflare DNS record that would permit that sort of thing, e.g. wrangler dev --host my-feature-branch.my-cloudflare-site.com --public (or what-have-you). It's unclear to me how those commands would work with routes, specifically, but that's due my unfamiliarity with wrangler's route configurations (versus a single worker with its own self-contained router).

Let me know if there's any additional clarity I can give on this feature request (or if there's anything wrangler-side that I could help with).

[threepointone]

It can get extremely complicated to expose a sub domain directly on cloudflare's end for this usecase (the localhost proxy isn't a plain proxy, it also adds headers and such, and it's going to get more advanced layers soon-ish. Further, for non-zone usecases, the workers dev sub domains are effectively random/based on a hash) So I don't think that's what we should do. It feels like exposing an external tunnel is the bullet proof way forward.

What would make it better is if we use Cloudflare tunnel for this, since we can then tap into your existing account if you want to use sub domains on your own zone/site, and stable ones otherwise.

Here's documentation for using tunnel with Cloudflare pages https://developers.cloudflare.com/pages/how-to/preview-with-cloudflare-tunnel but it should work with wrangler dev as well. In the future, we should integrate this directly into wrangler, so the experience is seamless.

This, I think, would satisfy your usecase cleanly, does that sound right?

[NAlexPear]

Using a tunnel solution integrated with Cloudflare makes a lot of sense. And that's very similar to what I'm doing already for wrangler dev (although I've been using ngrok rather than Cloudflare Tunnel, mostly out of ignorance). Being able to use subdomains on the same Cloudflare-managed host as production would also be a win for me (although perhaps not as much for those not using Cloudflare to manage their DNS, etc).

My biggest concern would be that dev workloads that are already running on the edge would be forwarded to the local machine and then tunneled back out to Cloudflare network again.

So it depends on what "integrate this directly into wrangler" means: if you're talking about using Cloudflare Tunnel to forward traffic from the edge network in one zone to another, that seems fine (although it would be even better if wrangler were able to, optionally, run those workloads directly in the target zone in the first place, right?). If you're talking about using Cloudflare Tunnel built into the wrangler CLI to route localhost back out to Cloudflare, then that seems less ideal, and not much of an improvement (if any) to my current ngrok workflow.

Apologies in advance if I'm misunderstanding or getting some terms of art incorrect here.

[irvinebroque]

+1, I also use ngrok as a workaround. It's essential not just for webhooks, but for developing embedded Shopify apps - I need to provide Shopify with a static URL in development in order to preview any changes in dev.

The guide for Cloudflared + Pages almost addresses this perfectly - but needs some way to reserve a static subdomain, akin to how workers.dev already works.

$ cloudflared tunnel --url http://localhost:8787 --namespace workername

...could serve requests at https://workername.accountname.trycloudflare.com instead of a randomly assigned subdomain like https://creativity-calls-perry-manor.trycloudflare.com. (I recognize it's possible to configure this using my own domain + cloudflared, but right now it's far more complex than using ngrok)

As an end user of wrangler, integrate cloudflared tunnels with wrangler seems like it would nicely mirror the behavior of workers.dev, where a worker gets assigned the domain workername.accountname.workers.dev. Ex: something like this in wrangler.toml:

wrangler dev --public-dev-subdomain brendan

=> https://brendan.workername.accountname.workers.dev

This would allow each person working on a workers-based project to setup their own publicly accessible static dev domain. Most apps I've worked on with webhooks or that integrate with more complex 3rd party APIs end up needing something like this. It'd be ideal to keep it out of wrangler.toml since people would likely use an environment variable here.

[ptim]

Cross-linking cloudflare/wrangler-legacy#1529, which discusses wrangler being currently broken for subdomains

[threepointone]

Assigning this to myself, I want to work on this.

[threepointone]

Moving this to wrangler2 repo, we'll probably tackle this in 2.X.

[isaac-mcfadyen]

A solution in the meantime for anyone who's looking for one is to use Cloudflare Tunnel. There's somewhat of a roundabout way to use a dashboard-managed Tunnel that can be activated on demand. Here's instructions (make sure you install cloudflared first):

• Run cloudflared tunnel create NAME on your local device that you are testing on. If you skip this step and create a Tunnel via the dash you cannot activate on-demand (it's always on), so make sure you create it this way. Pick a name and substitute NAME for your Tunnel name.
• Go to the Zero Trust dashboard, and find the Tunnel in the Tunnels menu on the right. Click Configure then Migrate (ignore all warnings, it doesn't matter that your config will be lost because you don't have any yet 😄).
• Add any hostnames you want under Public Hostnames, and point them to whatever local services you want (for example, laptop.example.com -> http://localhost:3000/)
• When you are ready to use your Tunnel, run cloudflare tunnel run NAME on your local device. Note that when this command is not running your Tunnel will not work: this helps protect against accidently leaving your Tunnel running and exposing a service by mistake.
• You can now access your local services on the Public Hostname you entered! 🎉

[jbergstroem]

I do this pretty much every time I set up a local dev project - would be very convenient for wrangler to expose a public url (with optional consistent naming, similar to tunnel create or tunnel --name).