Seemed like the perfect use for a worker, in particular for a static site.
Seemed like the perfect use for a worker, in particular for a static site.
Cyou still can, there's guides by CF for Resend (100 emails day, 3k/mo for free), https://developers.cloudflare.com/workers/tutorials/send-emails-with-resend/ and Postmark which is 100 emails month/free https://developers.cloudflare.com/workers/tutorials/send-emails-with-postmark/
Cloudflare Docs
In this tutorial, you will learn how to send transactional emails from Workers using Resend . At the end of this tutorial, you’ll be able to:
EI use mailgun elsewhere. I am going to assume it is as simple as using that instead.
Cthere's guides for using mailgun and workers out there yea, they've got an http api so anything is possible
CIs anyone aware of a mechanism for "CNAME flattening" to be done by other domain providers in a way that is compatible with workers?
I.e. if you want to host a worker at myroute.com, you have to define a "CNAME" for myroute.com. That's not wise (all subdomains / records get borked)... so Cloudflare has a mechanism called "CNAME flattening" that reconciles this problem by turning the "CNAME" at the root into A records on demand.
However, Workers require "recognizing" this domain as being CNAME'd to the worker route in question. They recognize Cloudflare "CNAME flattening," but not similar mechanisms by other providers (i.e. Namecheap provides ALIAS records that do much the same).
Is anyone aware of a way to get this to work? i.e. host a domain on Namecheap and CNAME the root to Cloudflare workers in a way that makes Cloudflare workers happy? (They just see an A record).
I.e. if you want to host a worker at myroute.com, you have to define a "CNAME" for myroute.com. That's not wise (all subdomains / records get borked)... so Cloudflare has a mechanism called "CNAME flattening" that reconciles this problem by turning the "CNAME" at the root into A records on demand.
However, Workers require "recognizing" this domain as being CNAME'd to the worker route in question. They recognize Cloudflare "CNAME flattening," but not similar mechanisms by other providers (i.e. Namecheap provides ALIAS records that do much the same).
Is anyone aware of a way to get this to work? i.e. host a domain on Namecheap and CNAME the root to Cloudflare workers in a way that makes Cloudflare workers happy? (They just see an A record).
Cit's more that you can't just point cnames to cloudflare zones or workers, it just doesn't work
Cworkers don't have unique ips or anything, you're just pointing to the edge, a shared ip from a pool
Con your own zones you have worker routes/custom domains which allow that specific hostname to execute
CRight. So I have that set up, but I'm using the SaaS worker stuff, so the other domains have to CNAME to my route
CRight, CF For SaaS enables that. You can't get apex proxying outside of Enterprise so you need to rely on alias records, but it should just work if you go through the prevalidation and such
Ɽwhat is AE, And how worker will know amount of data downloaded?
LCan I call multiple user workers from a dynamic dispatch worker in a single request? And if so, how would that be billed?
Kany one using twitter snowflake to generate distributed ID with worker? use what info to set machine bits ?
HDynamic import should be faster, though there is of course a limit on the number/size of files you could serve that way
VHThey should be stable, though iirc they are a little weird to get working via your Wrangler config...
NDoes someone know what should be here normally?
HThat's the console for your Worker
Medge browser problem
Nwell i tried to report it and show it but it did not work...
IIt there any more details available about
https://developers.cloudflare.com/workers/runtime-apis/web-standards/#navigatorsendbeaconurl-data
navigator.sendBeaconhttps://developers.cloudflare.com/workers/runtime-apis/web-standards/#navigatorsendbeaconurl-data
Cloudflare Docs
Standardized APIs for use by Workers running on Cloudflare's global network.
Clooks like it just waitUntils it https://github.com/cloudflare/workerd/blob/9108c4a723edf9d58d8693e27323bd8d84bc6ad0/src/workerd/api/global-scope.c%2B%2B#L852
GitHub
The JavaScript / Wasm runtime that powers Cloudflare Workers - cloudflare/workerd
IThat is actually pretty cool, that also means that if you need to do a simple POST request you can just use 
sendBeacon
BDoes anyone know if we can force outbound Worker requests having an IPv4 address?
We are using an external service (so not hosted on Cloudflare), that can't handle incoming requests since they are coming from an IPv6 address. They can only handle IPv4. Is there something like "Pseudo IPv4" but for outbound requests?
We are using an external service (so not hosted on Cloudflare), that can't handle incoming requests since they are coming from an IPv6 address. They can only handle IPv4. Is there something like "Pseudo IPv4" but for outbound requests?
CIf the external service doesn't have AAAA records/IPv6, Worker's Fetch will go over IPv4
BI see. Only with "Pseudo IPv4" enabled, or will Worker's Fetch always do this? The external service doesn't have AAAA records configured (just checked), but claims we're still coming in over IPv6
CIf the external service doesn't have AAAA records/support IPv6, how would you be connecting to them over IPv6? Workers are cool but not magical lol
Cfetch uses the normal cdn pipeline too which prefers IPv4 over IPv6
CIf they do use Cloudflare though, they'd see the cf-connecting-ip as the Cloudflare's cross-cf worker's IP, which is
2a06:98c0:3600::103That's a very good point actually, didn't think of that
BThat's exactly what they are seeing according to their support:
If I understand correctly, would they need to enable "Pseudo IPv4" on their Cloudflare account then?
. It's a decently big international service though, so not sure why we are the only ones hitting it with our Workers
Invalid IP address: >2a06:98c0:3600::103If I understand correctly, would they need to enable "Pseudo IPv4" on their Cloudflare account then?
. It's a decently big international service though, so not sure why we are the only ones hitting it with our WorkersCohhh ok I thought they weren't on Cloudflare since you said "so not hosted on Cloudflare"
BYeah it's not hosted on my Cloudflare account I meant indeed, was unaware they were on Cloudflare
CIf I understand correctly, would they need to enable "Pseudo IPv4" on their Cloudflare account then?
Edit: Psuedo IPv4 on their zone would, your settings don't effect anything though
Cif you wanted docs to refer them to: https://developers.cloudflare.com/fundamentals/reference/http-request-headers/#cf-connecting-ip-in-worker-subrequests
In cross-zone subrequests from one Cloudflare zone to another Cloudflare zone, the CF-Connecting-IP value will be set to the Worker client IP address '2a06:98c0:3600::103' for security reasons.
Cloudflare Docs
Cloudflare passes all HTTP request headers to your origin web server and adds additional headers as specified below.
BI see, that's very helpful! So this is an edge case, since we are both using Cloudflare Workers (I'm assuming they are), but they are on a different zone, they get the internal worker IPv6 address in
If I understand correctly, there is no easy fix for this on both our sides right?
CF-Connecting-IPIf I understand correctly, there is no easy fix for this on both our sides right?
BIn any case, extremely helpful already, so thanks a lot!
CI see, that's very helpful! So this is an edge case, since we are both using Cloudflare Workers (I'm assuming they are), but they are on a different zone, they get the internal worker IPv6 address in CF-Connecting-IP, even though they don't have IPv6 set up.Yep
If I understand correctly, there is no easy fix for this on both our sides right?I thought about it again and tested it, and Psuedo IPv4 does convert the Worker's IPv6 into a Class-E IPv4, but it's not an easy fix and has a lot of drawbacks of its own. Some legacy systems require IPv4 for fraud reasons or do GeoIP lookups, both of which would fail. Having non-real IPv4s in logging/analytics systems is messy as well if trying to understand/piece together logs or build reports.
In a perfect world they would tell your traffic apart from the CF-Worker header when it's a worker, otherwise enough people using CF Workers will run into other rate limits/issues. If they were a partner you were closely tied to, you could pass the actual user's IP in a seperate header too depending on the purpose of your integration.
CYou always have the cumbersome but feasible option of using a proxy that your worker sends requests through as well
C(this got buried, you might want to ask this in #workers-ai btw)
BThanks so much @Chaika, this really was incredibly helpful. I passed the info (and suggested solutions) on the other service. Definitely an error they'll be running into again if more and more people start using Cloudflare Workers!
CI want to check on whether I am missing something obvious...
I have a worker bound to a domain like
Unfortunately, that means I cannot also have another SaaS worker at
A way to make this work would be to write specific routes for SaaS (instead of
I have a worker bound to a domain like
api.something.com*/*Unfortunately, that means I cannot also have another SaaS worker at
other-api.something.com*/*A way to make this work would be to write specific routes for SaaS (instead of
*/**/*
Bwhen specifying build configuration there are a ton of frameworks to choose from. However, I you none of those and just have a bash script for deployment - I assume this is fine?
Cof course, build config presets are just meant to help guide, you can do whatever your app needs to get built
Bperfect, thank you
CWhat are you looking for exactly, how would two SaaS workers help you? Routes are matched on the incoming hostname which is their custom hostname, they couldn't CNAME at a specific subdomain and get a specific worker for example. You could use a worker or a snippet as a gateway though alongside custom hostname metadata and then use service binding and such to direct to the right one
Lquick question about workers, if I use all 100,000 requests of the free plan, the worker will just stop working until the daily reset, right?
Cit can take a bit for it to stop working/fail espec if they all come in at once, and the exact behavior depends on the worker route settings (can make it fail open -> requests straight to origin) or fail closed (worker custom domains just do this). If the question is just about billing you won't get charged for more or forced to upgrade or anything, it'll just eventually stop working
LOk thanks
