yeah this would be really nice

Is it possible to use worker runtime in github actions without wrangler --experimental-json-config?

I think I can get service binding efficient pricing benefit only if I use worker unbundled model? https://blog.cloudflare.com/service-bindings-ga/

▲ [WARNING] We recommend keeping your script less than 1MiB (1024 KiB) after gzip. Exceeding past this can affect cold start time

is this true even on the paid plan? I thought it kept workers in every edge location permanently

You are sort of right. Scripts on the paid plan are stored in Quicksilver, Cloudflare’s Edge Database. The issue is that Quicksilver only supports a maximum payload size of 1 MB, so above that, scripts are stored offsite, like free tier scripts

Reasonable to expect https imports support at some point?

SSL happens before you even reach workers, I'd be surprised if it did ever happen

Is this not how staging routes work? [env.staging] routes = [ { zone_name = "ehc.workers.dev", pattern = "https://subroute-proxy-staging.ehc.workers.dev/route/" }, { zone_name = "ehc.workers.dev", pattern = "https://subroute-proxy-staging.ehc.workers.dev/route/*" } ] I get this error workers.api.error.route_not_allowed_on_subdomain [code: 10038] workers.api.error.route_not_allowed_on_subdomain [code: 10038]

I'm trying to avoid needing to make a staging subdomain on the prod zone

I don't think you can add new zones on

workers.dev

mis-pasted that. { zone_name = "ehc.workers.dev", pattern = "https://subroute-proxy-staging.ehc.workers.dev/route/" },

not trying to change the zone, just create staging routes on it

Yeah, I don't think you can configure anything on the

workers.dev

domain, other than your personal subdomain(

ech.workers.dev

), and the project name.

Yeah we make the workers.dev routes ^ You cannot configure that, use a custom domain to do that

Hello all, Cross-posting from #1052656806058528849, hoping to get guidance. Looking for clarification on the Workers on Custom Domains scenario documented in the second paragraph of https://developers.cloudflare.com/workers/platform/triggers/custom-domains/#fetch. From the phrasing, I'm taking it to mean that a subrequest fetch to https://api.example.com/ from worker A hosted on app.example.com (set up as a Cloudflare Custom domain) to worker B hosted on api.example.com (also set up as a Cloudflare Custom domain) should work. Is this correct? From my tests, a fetch from worker A to api.example.com returns an HTTP 522 code. Other possibly pertinent details: - I have other services running on example.com as well as it's other subdomains, all fronted by Cloudflare DNS. - Parent domain name itself was purchased elsewhere but its DNS is hosted on Cloudflare. Thoughts on above?

Can't you set routes/triggers on the *.workers.dev domain?

You can enable/disable the

*.*.workers.dev

domain, but you can't set routes explicitly

ok, thanks

Oh interesting. How does that work with multi-file workers? Is it stored as gzip and decompressed on every request, or is each file stored separately?

wrangler

bundles all the files(minus WebAssembly) into a single file on build

Including files under the

rules

section?

Yup. It uses the rules to determine how to inline them

Text files are escaped and then inserted as strings

As an example

That's weird

Why does it disable quick edit in the dashboard?

And how do you inline binary?

QuickEdit is pretty old, so a lot of stuff breaks when you use it.

so this is just a lie https://developers.cloudflare.com/workers/wrangler/bundling/#files-which-will-not-be-bundled