Cloudflare registrar was announced (and released) nearly two years ago, allowing people to transfer their domains to Cloudflare. It was declared then that registering new domains would be coming soon. But here we are nearly two years later and there’s no sign that this is coming this year either. Meanwhile, the company even went public through an IPO. What’s the holdup and why the radio silence? I’d actually prefer a blog post about this on the official site than a “what should we tell and what shouldn’t we tell” response here.
https://www.cloudflare.com/tld-policies/ says
Cloudflare is committed to supporting all available TLDs, with a focus on expanding country-code TLDs, and are working to expand this list. Check back soon for updates.
However, it has been saying this since the beginning, and comparing the current list to the October 2018 version (https://web.archive.org/web/20181025085340/https://www.cloud...), there are only 13 new TLDs:
bet Afilias
black Afilias
blue Afilias
green Afilias
io NIC.io
kim Afilias
lgbt Afilias
mobi Dotmobi (Afilias subsidiary)
pet Afilias
pink Afilias
pro Afilias
promo Get (Afilias subsidiary)
red Afilias
I wonder if you would be kind enough to shed some light on this situation?
I feel as if I'm totally oblivious to what differentiates offering domain transfers from new domain purchases, considering that millions (or more) domains are already registered and squatted on now. A 60-day delay in transferring new domains isn't going to deter a squatter from buying new domains elsewhere and transferring it over to Cloudflare.
Could you please clarify if you see this comment? Thanks.
totally get that something that enables my silly personal domain purchases more smoothly could be abused by squatters and that their use patterns could create unwanted support/engineering load you wouldn't want to deal with though, i think that's reasonable. the one thing i'd wish for is maybe being able to transfer a domain i've recently purchased elsewhere more quickly--as-is i think there's a waiting period before you can move a domain onto the Cloudflare registrar
I can only imagine transferring in more domains, or when they start to renew. All these individual charges will freeze any linked CC and the renewals for subsequent domains will fail. So there is a chance you might lose your domain if you experience this and don't check your account.
There are many people who have experienced the same and written on their cloudflare community forum, some posts dating back years, and still nothing has been done about it.
Just letting HN know about the billing side of things when using cloudflare as a domain registrar.
We moved to Cloudflare from a larger CDN and used workers to duplicate the functionality otherwise not provided by Cloudflare. The initial results were great. As our workers became more complicated, especially when interacting with CloudFlares internal stack, the cracks started to show. Specifically, when you run into a problem, the documentation being too light to resolve corner case issues yourself, and support draws a big zero when it comes to Workers. Even as an Enterprise customer, it can take months to get a clear answer/resolution, and that's if you nag them.
As a platform, workers have great promise, and Cloudflare is making strides. As with most things CloudFlare, they could spend more time improving documentation, and exposing details on their internal stacks so you can self-service and resolve your issues. What I find is that Cloudflare is on to the next thing before fully completing, polishing, documenting, the previous three things they started.
For Workers, I'd like to see a trace tool built for Workers where you can debug what happened in a Live environment. Currently, they recommend outputting debug as JSON in a header.
The linked article is worthless. See the blog post, as this poster mentioned:
That is a general problem I have had with Cloudflare over the years. It's hard to know exactly what happened when things fail or even the fact that things failed!
They always branded themselves as that super scalable and stable CDN or DDoS shield that will keep your service up when it would normally break down. And those absolutely horrible "You <-> Cloudflare OK, host down" error pages that suggest it's the host that has the problem and at the same time advertise Cloudflare to your visitors. Well turns out the vast majority of issues that clients reported (automated or not) were caused by Cloudflare themselves. And what really makes it painful is that it's 1. sometimes hard to debug 2. they wont make this visible to you unless I guess you pay for the highest Enterprise plan which offers raw logs. They just don't tell you even how many requests failed. There's no simple error.log. An example: at some point Cloudflare started blocking a lot of requests from Turkey to an API. The only way to solve it was to whitelist Turkey as a country.
We've moved off of Cloudflare and had a lot fewer issues.
PS: every feature since the simple CDN stuff seems to be now about lock-in. It's all Cloudflare specific. This is a dangerous path that moves away from the commoditization of "hosting" where people can easy move from one hoster to another. I hope it does not succeed. For the sake of the open web.
I'm a product manager working on Workers — didn't come across hater-y to me at all.
We will actually be rolling out a new version of our docs soon — hopefully make them easier to navigate, and expose deeper information. If there are any specific subjects or corner cases you've run into that you'd like to see better documented — our docs are open source (so issues are welcome!). We definitely want to make it as easy as possible for you to self-service.
Observability and debugging is also a heavy area of investment for us (and I think we've made significant progress here since the launch of Workers). As Kenton mentioned below, wrangler tail is a great way to get a lot of information out of the Worker (and its subrequests) — you can basically log anything. We'd also like to make it easier to log to existing logging platforms from a Worker. If there's any missing information you'd like to see, please do sent me a note ^
Mainly I’m thinking that a major use case for using CF is stuff like DDoS protection, but workers have a per request cost and according to [1] CF’s DDoS protection won’t automatically protect against a layer 7 attack. It seems the options are to either use CF’s rate limiting product (which charges per good request 10x the price of a worker request. Maybe that’s worth it, but it sure makes workers look less affordable than at first), or set firewall rules to block the traffic. For that second option, it would be great if it could be done from inside the worker (although I’m not sure yet how the worker would actually go about detecting that a request aught to be blocked. [1] suggested running fail2ban on the origin and using the firewall API to dynamically update rules — I guess I’m windering if there is a simpler way). Rate limiting seems ideal, I’m just not sold on paying 10x when I don’t know if I’ll even ever need it: maybe simply being able to set optional limits for worker requests after which further requests don’t get serviced, rather than getting billed for an attack? Is that possible? I guess I could count requests somehow myself. and disable the worker. At least then I can make a call between whether uptime is worth the cost of rate limiting or if I can just accept some downtime.
[1] https://community.cloudflare.com/t/how-to-protect-cloudflare... and https://community.cloudflare.com/t/workers-have-a-critical-i...
I don’t have an answer to that but it’s worth considering if the cost of using the value created by CloudFlare _is_ the lack of polish when features are launched.
GitLab is a good example of this phenomenon because it can be compared to GitHub: GitHub is high quality slowly whereas GitLab is lower quality faster... maybe CloudFlare is the GitLab to Akamai’s GitHub, both with their valuable place in the market.
There's diminishing returns from 80% to 100% done, plus there's the human condition--it's a lot more fun to solve the hard problems than do the polishing at the end. I think that teams can get too enamored of the features they create, it's hard to get perspective when you've been staring at something for a while.
I've often wondered if the answer is to have multiple teams (pods) so that one team can get a feature to MVP, then hand it over. You're then not invested in "your" product, there's space to be objective and revisit the path from MVP onward.
Does `wrangler tail` help with this?
https://developers.cloudflare.com/workers/about/tips/debuggi...
From the docs:
"If your Workers application is returning an 1101 error code, your code is throwing an exception. You can catch the exception in your code using a try/catch block:"
That's great, but you end up just returning those details in a header or sending them somewhere else. We have to catch errors and send them to our backend for logging so we can debug them at a later point.
This doesn't help you debug things like sub-requests from the Worker or how they interact with other Cloudflare features like Cache.
You sowed the seeds for future crops, literally.
When they expect dedicated CPUs and memory, they're suddenly going to price shop across cloud providers and won't pay enough to make those same margins.
Agree it's stealth protectionism and security overreach. But do data sovereignty laws really form the basis of an inevitable future federated internet? Trade agreements like CPPTPA and USAMCA seem to prohibit. Or restrict sensitive finance or health data. And most users of consumer internet apps like TikTok aren't too concerned. They just want fresh memes ;)
Just signed up to Cloudflare Unbounded private beta (feel free to fast track). And thanks for all your hard work. $NET has been a stand out performer!
The idea that the Internet is universally global and where your data is doesn't matter is idealistic fiction, not reality.
1) The CPU limit.
2) Not being able to use Node modules.
3) Not being able to add domains other than adding those to our CF account. SSL for SaaS solves this but, so far, it's only available to enterprise customers.
The CPU limit was not so bad when considering Workers were not intended as a general use-case for serverless functions. Now that this has been lifted I feel the Workers environment limitations are going to be much more important.
You can't, for example, use many Node packages in Workers since these are running in a custom V8 environment which resembles browser service workers. I say "resembles" because the API is not 100% identical. For example, you can use streams, but you don't get the full API.
Not only is this an interface you adhere to to use their service (incoming event, outgoing response), that type of coupling is fair and expected, but the underlying runtime is custom without full support for standard APIs?! What's the upgrade path? Can they port things over in a reasonable amount of time? Is it well documented what's supported and what isn't? Imagine developing against this and resolving these issues as they come up. Oof.
I'll use Azure or AWS.
No, not really. For example, I experimented a bit with streaming HTML but then hit a roadblock because ByteLengthQueuingStrategy wasn't available.
Now it's even better with deploy to all PoPs and no cold starts.
A few questions, if anyone from Cloudflare is here:
0. Can we expect in Workers Unbound support for Websockets, WebRTC, HTTP Connect, and Server Sent Events?
1. Would there be support for protocols other than HTTP? Say, a raw TCP / UDP connection that is handed off by Spectrum to a Worker [1] (Spectrum here is redundant?)?
2. Inability to rate limit Workers in a cost effective way gives me sleepless nights [2]. The current rate limiting plans are too expensive when compared to Workers, almost 10x if expected good requests are to the tune of 10 million [3] (in my case good requests have potential to be much much higher). Any announcements due in this space?
3. Will the same isolate (Unbounded Worker), if kept running for long, be able to handle multiple connections/requests concurrently, or would each HTTP connection create a new isolate (that is, a new Unbounded Worker instance)?
Thanks.
[0] https://news.ycombinator.com/item?id=20791660
[1] https://news.ycombinator.com/item?id=21921821
[2] https://community.cloudflare.com/t/how-to-protect-cloudflare...
[3] https://support.cloudflare.com/hc/en-us/articles/11500027224...
Definitely yes on WebSocket. In fact, the only reason we haven't rolled out WebSocket support already is because it's not very useful without long-running CPU. Workers Unbound fixes that so I'll be dusting off my old WebSocket implementation PR soon.
I think Server Sent Events are just streaming HTTP? That should work today (but with the same caveat that CPU limits may cause trouble).
WebRTC is a peer-to-peer (browser-to-browser) protocol. We don't currently have plans to implement it directly in Workers, though that's an interesting idea.
By "HTTP connect", I assume you mean the CONNECT HTTP method, usually used to tunnel TLS connections through forward proxies? That's a request I haven't heard before, but it's interesting. I guess what you'd get, basically, is the ability to establish TCP-like connections that are addressed to HTTP URLs and connect over port 80/443? Is this commonly used for things other than forward proxies?
> Would there be support for protocols other than HTTP? Say, a raw TCP / UDP connection that is handed off by Spectrum to a Worker [1]?
Not part of the current plan but definitely something we'd like to do eventually.
> Inability to rate limit Workers in a cost effective way gives me sleepless nights
Yeah, our rate limiting product is not really intended to be used to rate-limit the whole site to control costs. It is more intended to, say, rate-limit your login form to prevent brute-force password guessing.
That said, we do have layer 7 DDoS protections, and those run in front of your worker. If an attack gets past them and hits your worker, I'd encourage you to raise a support ticket asking for compensation for the attack traffic that we failed to block. I am not personally in a position to promise that we'd refund you but I believe it has happened in the past.
> Will the same isolate (Unbounded Worker), if kept running for long, be able to handle multiple connections/requests concurrently,
JavaScript is inherently single-threaded, so an isolate can only be executing code on behalf of one request at a time. That said, it is already the case that multiple concurrent requests may be handled by the same isolate (one request may be executing while another is e.g. waiting for a response from a remote server). But today you can't really take advantage of that, because you have no control over exactly which isolate receives any particular request, no any way to communicate between neighboring isolates. This is definitely something we're working on but nothing to announce at this time.
> WebRTC is a peer-to-peer (browser-to-browser) protocol. We don't currently have plans to implement it directly in Workers, though that's an interesting idea.
The reason I asked is, since overlay distributed networks are being built on top of WebRTC (like u/feross' https://WebTorrent.io), Workers Unbound, if it supported WebRTC, could potentially then be a participant in such distributed networks. May be, I can seed torrents through Workers Unbound or build a P2P CDN on top of it which is at least as fast as usual CDNs when there are not very many connectable peers nearby. Or, have Workers Unbound participate as a host in a P2P database / filesystem like GunDB [0], for example.
> Is this commonly used for things other than forward proxies?
Yep, pretty much the use-case I was going for with Workers Unbound, tunneling traffic through HTTP to bypass firewalls and navigate NATs. A TURN over HTTPS of sorts, like Tailscale's DERP [1] but with servers worldwide. Will this be supported out-of-the-box?
Thanks again!
I've seen this used in a few contexts, for instance batching requests to a origin (logflare: https://github.com/Logflare/cloudflare-app/blob/master/worke...).
Is this generally seen as ok? I'm planning on building similar things for sending page metrics in parallel to serving traffic.
> > Inability to rate limit Workers in a cost effective way gives me sleepless nights
Agreed, there is something very challenging with the current design of how requests flow through cloudflare.
I have played around with dynamic rules in firewall by manually handling "firewall rules" in a worker as part of a request flow and using KV to share this state. I would then update the cloudflare firewall with api. I had to create a separate service to poll both API and KV to maintain them though.
I'm using them for a couple of small production projects and wrote up a gRPC example, quite happy with the service so far.
We're more like Fargate than Lambda, but Fly apps scale and balance across regions. I wouldn't really call it "more edgy", it's just built specifically for running app servers close to users (vs emulating a traditional single region datacenter).
We actually started with a JS runtime like CloudFlare has, but it was wrong for our customers. They're better off just running Docker images.
There's a lot more in our HN launch thread: https://news.ycombinator.com/item?id=22616857
CloudFlare, CloudFront etc tend to have one or two edge PoPs in India, and one in Singapore, and Fly has one (upcoming) in India, which is coincidentally in the city where I live. So for me, Fly and CloudFlare and CloudFront have servers a few blocks away.
Same case for Singapore — everyone has an edge there.
But of course for the rest of the world it depends. The full blown CDNs will try to put edges in every city, but Fly and AWS Outposts will likely be few per continent / one per timezone / country.
Are Cloudflare's machine sizes unsuitable for being able to offer more memory as an option?
1. To eliminate a layer of application/server/network management (especially if you have complex infra).
2. To get “free” application high availability.
3. To integrate with other stuff on the edge (auth/identity).
4. To serve as a central query aggregator from multiple sources.
[0] https://developers.cloudflare.com/workers/about/security/
Kill me, now. Containers are in no respect virtual machines. Cloudflare Workers, by contrast, literally are virtual machines: your code runs on V8.
A process is a "virtual machine" running on-host with many other such machines, virtualization is provided by the kernel
A host is a "virtual machine" running on metal with many other such machines, virtualization is provided by the CPU
Metal is a "virtual machine" running on microcode with up to 3 sets of sibling architectural state (did any vendor ever implement 8-way SMT?), virtualization is provided by the silicon
It's turtles all the way down
Even better if the isolate is itself running an emulator, in which case it's also turtles all the way up
- These days, it has become common to use the term "Virtual Machine" specifically to refer to hardware virtualization. The old meaning of the term, referring to language runtimes, is (sadly) now so uncommon as to be outright confusing to many people.
- Most other Serverless environments technically do wrap their containers in virtual machines (like Firecracker), since plain containers aren't considered sufficiently secure on their own.
Nice to see more and more pushed to the edge, and good that it's only the beginning of the week.
I'm a little surprised they stuck with the isolates model when moving to include generalized compute. We found isolates to be ideal for a cache layer, but it doesn't have first class support for many languages: https://community.cloudflare.com/t/native-golang-support-for....
Very interested to see if they expand on their storage options throughout the week. Additional consistency guarantees in their KV offering would make it more competitive with Dynamo. I'd love to see a managed relational offering like Cockroach, or perhaps the addition of CockroachCloud to their bandwidth alliance.
One point I'm disappointed about is that they list API Gateway and DNS Queries (per MM requests) at $0.
This may be true if you're deploying on a single domain with Cloudflare, but if you're a SaaS and need SSL for custom domains, Cloudflare bumps you into their enterprise offering that costs a minimum of thousands per month, and (we found) netted out to about $5-10 per month per hostname: https://www.cloudflare.com/ssl-for-saas-providers/
(I recognize this is a different way of metering, but listing both at $0 feels like they're arguing DNS & TLS termination cost nothing at Cloudflare, and that was far from our experience)
Some people have claimed narrow execution limits provide a defense, but we on the Workers team don't believe that's true and I don't think we've made that claim. Specifically, it's easy for an attacker to store state between requests and so continue an attack across many requests. In our current implementation, you can store that state in global variables, but even if we wiped the worker's state after every request, it would still be easy for an attacker to store their state remotely.
We'll be posting more about Spectre later this week.
> That was also how they prevented v8 from allocating tons of memory.
No, we explicitly limit V8 memory usage independent of CPU time.
Ok! I hadn't just gotten that from one your talks on Workers: you had said v8 doesn't really offer a useful hook to limit memory usage as it aborted the process rather than just stopping the isolate, and that the CPU resource limit was thereby an important part of the memory limitation (as with the exception of typed arrays, using memory in JavaScript requires code to actively set memory). If you did change this, it makes me all the more interested in the changes you are making in v8 ;P (though it is also possible these changes were actually just part of upstream and I failed to notice).
https://www.infoq.com/presentations/cloudflare-v8/ (at 20m45s)
Everything I have read suggests containers (being based on CGroups) add virtually no overhead at all (in the vicinity of 1% at worse from memory).
My understanding of isolates is they are more or less a container, but at the v8 level instead of OS. This makes spinning up a function more akin to opening a new tab vs opening a new browser instance.
> The way the team engineered this is by queuing up the process while the two servers are still negotiating their TLS handshake.
That's pretty cool. I'm trying to see a downside, given that presumably it won't spin up a function for traffic from IPs it knows are abusive.
Does anybody know whether this will remove the current maximum runtime limitation? As far as I can tell, workers have a maximum duration of 10ms on the free plan and 50ms on the paid one.
I would assume that it does, considering that it's being compared to AWS Lambda, which has a timeout of 15 minutes.
Note that the current 10ms/50ms limit is on CPU execution time; it doesn't count time waiting for remote servers to respond.
Our WebCrypto implementation just a thin wrapper around BoringSSL, FWIW.
On the topic of open source, I'd say about 10% of the coding we do for the Workers Runtime actually lands in Cap'n Proto / KJ, which has been open source all along: https://github.com/capnproto/capnproto
Unless one is invested in AWS for other needs or need one of the language which Workers doesn’t support (Java?, Go?), it might be a fair option to consider.
I'm a little surprised they stuck with the isolates model when moving to include generalized compute. We found isolates to be ideal for a cache layer, but it doesn't have first class support for many languages: https://community.cloudflare.com/t/native-golang-support-for...
Very interested to see if they expand on their storage options throughout the week. Additional consistency guarantees in their KV offering would make it more competitive with Dynamo. I'd love to see a managed relational offering like Cockroach, or perhaps the addition of CockroachCloud to their bandwidth alliance.
One point I'm disappointed about is that they list API Gateway and DNS Queries (per MM requests) at $0.
This may be true if you're deploying on a single domain with Cloudflare, but if you're a SaaS and need SSL for custom domains, Cloudflare bumps you into their enterprise offering that costs a minimum of thousands per month, and (we found) netted out to about $5-10 per month per hostname: https://www.cloudflare.com/ssl-for-saas-providers/
(I recognize this is a different way of metering, but listing both at $0 feels like they're arguing DNS & TLS termination cost nothing at Cloudflare, and that was far from our experience)
Surprising that Workers Unbound charges egress (first time egress is directly charged by Cloudflare?) and at this quite expensive AWS-like price.
When transfer is so expensive, it makes it harder to switch from other clouds that have more than just compute capacity, especially since you might be paying double to transfer between cloud->CF->user