Cloudflare launches Workers Unbound, next evolution of its serverless platform
blog.cloudflare.com
blog.cloudflare.com
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:
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.
Focus so far in the design process has been how requests get evaluated against a list of Custom and Managed Rules but if you imagine a world in which everything is a rule (incl. routing to/firing a Worker) it becomes tractable to do what you're asking about.
We'll be in discussions with the Workers team about how to best illustrate the handoff to Workers and what happens downstream: cache, origin fetch, etc.
You sowed the seeds for future crops, literally.
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.
For the anti DDoS: it was not a big/common issue and in the rare cases we can work with providers to mitigate.
For most, I think GeoDNS is good enough and very simple. The number of users using nameservers that break it (like Cloudflare's 1.1.1.1)* is still small.
*: The reason why it breaks is because they don't send along the EDNS client subnet to the upstream nameserver for "privacy reasons". I disagree with that notion because 1. it's just the subnet 2. the website/service will see the full client IP anyways when it gets the http request. I mean how many times does one resolve a hostname and then not connect to it? And we are talking about the authorative nameserver, not the ISP nameserver.
But if your API is not implemented on the edge (e.g. in a Worker), and the responses are not cacheable at the edge, and you aren't using Argo, then there's not much else Cloudflare can do to make the request faster. Cloudflare is just proxying requests at that point, and the presence of a proxy will indeed probably add a few milliseconds of latency vs. the client talking directly to the origin. (Of course, you do get other benefits like DDoS protection.)
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.
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'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)
> 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.
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!
If you can manage to tunnel over WebSocket, though, that'll be supported a lot sooner.
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.
We use a variation of this technique, and it works.
> 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.
You and I have pretty much the same problem then. Beware though of race conditions.
Also, a still cheaper way to keep a counter would be to use CountMinSketch and related probabilistic datastructures, but as before, data-race needs to be handled.
It's OK, but you won't see a ton of benefit unless you have a very large amount of traffic -- enough that you're commonly seeing single isolates handling concurrent requests.
We're working on something that should be a lot better for this.
Our traffic patterns are such that per active-user we would add 100K requests per month when we go live. We send metrics out batched every 10s or so, but stumbled upon this post that warns of internal limit on total number of requests originating from Workers per second set at 2000, account-wide [0].
Is there a way to discuss our usecase and get whitelisted for limits as our traffic isn't malicious, hopefully without having to subscribe to the enterprise plan? I raised a support-ticket but a bot replied that since we are "free customers" it hasn't be been looked at.
[0] https://community.cloudflare.com/t/workers-and-sub-requests/...
Oh, there is no such limit.
The post you link to is quoting another poster who is quoting something they heard from someone else. It sounds like something that may have originated with someone hearing about a particular implementation detail of our anti-abuse systems but the game of telephone has transformed it into something that's just not true at all.
As described in my comment on that thread, we do have certain anti-abuse heuristics which might result in a 1015 error. It's very unusual for people to hit these in legitimate use. Have you seen such an error? 100k requests per user per month doesn't sound like it would come anywhere near being an issue (even with 10M users).
FWIW the heuristics are designed such that simply adding more users (who behave the same as existing users) shouldn't ever cause a problem.
Nice. Thanks! That's re-assuring.
> It sounds like something that may have originated with someone hearing about a particular implementation detail of our anti-abuse systems but the game of telephone has transformed it into something that's just not true at all.
A Cloudflare employee engaged in this thread [0] confirmed existence of this internal limit: "...basically 2k subrequests _per minute_ per colo / zone / IP. Once you hit that you start serving 429s.", which another customer hit with ~5M requests per day (per a screenshot shared later in the thread) and had to get whitelisted for.
[0] https://community.cloudflare.com/t/massive-rate-limiting-iss...
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.
Also, compared to the 10+ seconds I've experienced with Google I'd be happy with 5ms any time. :)
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
1. What's the average cold start time when spinning up a new instance? For comparison, AWS Fargate often has cold starts of around 1 minute.
2. Is there a limit on the container size created by the Dockerfile?
3. Is there a limit on the number of concurrent instances a single user can run?
2. There's no hard limit. We've had 8GB images running (that I know of). Cold starts can be pretty bad on those just because pulling down an 8gb filesystem is slow.
3. Also no hard limit. I'm curious what you're doing though! Feel free to email me: kurt at fly.io
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.
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)
Surprising that Workers Unbound charges egress (first time egress is directly charged by Cloudflare?) and at this quite expensive AWS-like price.
So basically all the classic benefits of serverless and edge computing would apply, the difference being we would need some more drivers, python libraries and a GPU attached.
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.
Presumably the thinking behind this approach is that it allows them to advertise cheap instance costs and storage costs, while still making bank, assuming the customer's traffic volumes are non-negotiable?
Also has the effect of lowering prices for casual dabblers, who might want to play about with what's on offer without moving much traffic.
Assuming that Hetzner's 1 EUR/TB isn't losing them money, AWS's 50-90 USD/TB should put the margin at 98% plus.
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.
Freedom to store and process in more logical, secure and efficient places is a good thing.
Which is to say, the only parties that benefit from being able to store your data in other countries is often global monopolies shifting your data to where they have the least legal oversight.
Forcing data to be stored within borders just makes it harder, more expensive, and more inefficient to serve more customers for no real security benefit. And a company with illegitimate operations isn't going to be following these guidelines anyway.
Why do you say so? There's nothing technically stopping a teleco to add extra nodes there, use 10% for themselves and rent out the remaining 90% resources.
There's also security; they can't just store/process customer certificates on minimally secured boxes on street corners. Just about any useful code requires some kind of cert or secret or connection string somewhere. Cloud providers require all sorts of physical security restrictions, guards, cameras, sharks with lasers and such in order to host these things.
The way it's working now is telcos are outsourcing it to the cloud providers, and cloud providers are sticking racks in the carriers' metro hubs (with shark/laser requirements). These racks show up like mini regions in cloud providers' portals, so users can deploy VM's there just like any other region. Much lower barrier to entry that way.
Maybe someday you'll get sub-microsecond latency on custom apps from some box hanging on your street, but that's not coming anytime soon AFAIK.
They are already doing that for their own code, no reason any CRUD app would behave much differently than teleco code. In fact teleco code has much higher SLO than regular web services.
> There's also security; they can't just store/process customer certificates on minimally secured boxes on street corners. Just about any useful code requires some kind of cert or secret or connection string somewhere.
Already solved problem by using SDS for mutual TLS.
> The way it's working now is telcos are outsourcing it to the cloud providers, and cloud providers are sticking racks in the carriers' metro hubs (with shark/laser requirements). These racks show up like mini regions in cloud providers' portals, so users can deploy VM's there just like any other region.
Do you have any source for this? Which cloud is providing such services and with which teleco?
Edit: https://www.fiercewireless.com/5g/verizon-partners-aws-to-br... Looks like it isn't farfetched, AWS is already teaming up with Verizon to provide this.
Interestingly when I took my job I also thought we were going to be deploying to every intersection, and was a bit disappointed when I found that the reality was much less interesting.
And just so you know, no the security angle is huge. Something like SDS may be fine for some purposes, but if there is anything valuable resident in memory or running over PCIE or whatever else, side channel attacks are real and people will steal them. Look up some hacks people do just to cheat at Xbox, it's insane. If you can't prove you're secure against that, you'll never get big money customers on your platform. Currently that still means sharks with laser beams.
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.
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
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.
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)
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.
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.
[0] https://developers.cloudflare.com/workers/about/security/
Looks like Python there is an existing python <-> wasm interop
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.
As a customer I would be ready to pay a bit extra rather than go through the purchase at NameCheap. wait 60 days, and then transfer dance.
I don't even think you've misled anyone by doing this, since it's essentially a new product (new domain registrations).
The point of living up to the original promise: the original promise was to offer domain registrations at low prices. You are afraid to not live up to it? Well you don't because you don't allow registrations. You still have a landing page that advertises the service. You have call-to-actions called "register now" and the page [1] tells about new registrations and renewals. Then after clicking on it you land on a domain transfer page that doesn't really tell you that that's the only thing that works right now. So by being afraid to not live up to the promise you actually don't live up to it.
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?
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 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.
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.