Comment by ji_zai

Is this in line with the TOS? I thought there were restrictions on serving non-website content in the free tier, or does that not apply to the CDN if you're using R2 as an origin?

I don't understand this take. First of all, moving off of Cloudflare is trivial if you really have an alternative. Second of all, self hosting a static website is easy, but that's not we're talking about here. We're talking about DDoS mitigation, which is not gonna be solved over a weekend hack with a load balancer. At least, not at the scale that matters.

What would the Cloudflare going evil phase even look like? Is it anything like Netlify charging me 100k because they don't provide ANY DDoS protection? I don't see any FOSS tools preventing this problem.

That's not CloudFlare's fault.

I dread the day they go evil

> Yeah that's how Cloudflare can reach total control over the Internet. With thunderous applause by people that should know better.

This is an emotionally-manipulative, anti-intellectual comment that certainly does not belong on HN. There's no intellectual curiosity or value in this comment - just scoffing, predictions of doom, manipulative statements like "I know that my position is outright blasphemous in this day and age", and other drivel that belongs on Reddit, not here.

That's because amazon and big telecom convinced you that bandwidth is expensive. It isn't. Once the equipment is there, you might as well use it.

I believe it's quite the opposite, cloud has normalized absurdly high traffic fees, and that is what should be raising alarm bells.

Peering.

Here's how it works:

1) I have a big network and I exchange traffic with another big network. Think of "eyeball" networks like last-mile ISPs (Comcast, mobile providers, etc) where a substantial portion of end-user traffic is going to handfuls of well known networks - Cloudflare, AWS, Netflix, etc.

2) Comcast and Cloudflare say "Hey, I send you X TB/PB/etc and you send me X TB/PB/etc. We both currently pay another provider to route that traffic between us. Let's not do that."

3) In locations where it makes sense they basically throw a cable across datacenters, POPs, internet exchanges, etc. The cost for this is typically extremely low - it's basically a port on a switch/router on each side and MAYBE a "cross connect fee" from the facility. This is usually billed in the tens of dollars/mo if at all. It takes very little time/effort to configure this but of course the details are more complex - multiple ports, multiple facilities, etc.

4) Both sides start routing traffic between their networks over their new shiny direct cables and extremely high speed ports. Faster throughput, lower latency, improved reliability, frees up bandwidth to the transit provider they were using previously, and most importantly the cost of bandwidth between the two networks goes to zero.

This is all well known and publicly available because it's visible in the global routing table(s). Cloudflare, for example[0].

All of the large providers do this and AWS, etc charging in bandwidth per GB (especially at their rates) is more-or-less pure profit.

I have a theory that AWS, etc capitalize on people not really understanding this anymore. AWS is 20 years old - that's an entire generation of CTO/CIOs on down that are completely unfamiliar with these details and think $0.10/GB or whatever is "just what bandwidth costs". It is not.

[0] - https://bgp.he.net/AS13335#_peers

I have heard that they rather drastically constrain QoS instead, which does sound reasonable. So you are still not charged for abusive traffic, but your service will be much slower than what is actually possible with paid tiers.

I think a lot of people don't understand how cheap bandwidth is and is decreasing in cost practically every day. Amazon and Google have a lot of people fooled. Go ask someone operating in China and East Asia (and Japan) how much they're paying for local solutions.

These guys know what they're doing. If and when Cloudflare dies we'll find something else.

it's 100% not sustainable. Use it while it's good, but don't get vendor locked in, because sooner or later they will increase the prices

Their stock performance would agree

By the time it isnt sustaninable I will have IPO'd and be the next offensive new money tech billionaire writing threads on twitter telling you the secret to success is the 5am grindset and everyone who isnt sinking 5mil into the next big thing (tm) can have fun staying poor.

If you are not paying for it, you are not the customer; you're the product being sold.

These days it seems that DDoS attacks are often not targeted at bandwidth either, but rather packets per second. It is (apparently) much easier to exhaust routing capacity with an inordinate number of tiny packets than with a still large number of large packets. Cloudflare has some fun ways to deal with this [0].

[0] https://blog.cloudflare.com/mitigating-a-754-million-pps-ddo...

I rent a GCE VM and there's not many if any people out there who can exhaust Google's network infrastructure. The only thing I have to worry about is making sure my server doesn't respond to abusive traffic.

I just declare firewall jubilee every now and then, where I flush the iptables and let people try again. It's also because people usually only control the IPs they use temporarily, so I don't want someone innocent later on to be blocked from using the service because someone abusive used their IPs beforehand. But even if I didn't do this, it doesn't cost much for Linux to iterate over an array of blocked int32's. It's really only allocated TCP connection resources that are problematic.

Ditto. "Migrating from Netlify to Pages" : https://developers.cloudflare.com/pages/migrations/migrating...

Just looking at pages.cloudflare.com now and I think I'm going to be using cloudflare from now on.

I'm trying to sign up but it keeps saying "Verification is taking longer than expected. Check your Internet connection and refresh the page if the issue persists."

Does anyone else experience this as well?

Depends on your service. 20 second downtime on loading HN? Nobody cares. 20 second downtime on the last play of the Super Bowl - big problems.

For most internet consumers we’re accustomed to poor service so if a page doesn’t load we’ll assume it’s a local problem and try again 20 seconds later, same with buffering, it’s just something that happens occasionally. This is increasing the case for phone calls too. Legacy live tv and radio going silent though is still a major issue, especially on live events.

I think most people pick Netlify for it's Infra as a Service offering, so it would be nice if they had a way to throttle and budget in that offering.

I would even imagine Netlify's target market is small to mid size businesses who really don't need ridiculous burstable scaling capacity at all. Seems like a bit of a trap door for that customer base.

I agree though, I wouldn't host on them as a small business due to that risk, but I am also happy running my own server so I might be an edge case.

I always loved nearlyfreespeech.com for this, (prepay, and if you run out of money the site goes down) but found it to be a pain for projects that really needed a VPS

Folks regularly show up in HN comments during these discussions stating the opposite—that it's categorically better for all sites/projects, now matter how inconsequential, to stay online. It's weird.

This includes some of the TPTB, too. Occasionally, though, someone'll say the quiet part out loud. E.g. re fly.io:

> putting work into features specifically to minimize how much people spend seems like a good way to fail a company

<https://news.ycombinator.com/item?id=24699292>

> When I rent a car in person, I am often given a contract. And this contract is filled with tiny print, and pages of it.

As someone who reads the agreements I sign, one thing that has become prevalent is that they're so used to people not paying attention to what they're signing that they're sometimes not even giving you an accurate copy to review. For example, you read the thing and think, "Okay, I can work within these parameters," then you sign, and later get an email containing your "agreement", but it turns out what's in the email is a different set of terms with a bunch of stuff that wasn't in the terms you actually agreed to when you signed. Or someone hands you a pad with an "I agree to the terms" box checked beside the signature line, and when you ask to see the terms you're agreeing to, they're caught off guard (being totally unequipped to let you do that), which turns into being flummoxed with how to proceed, which turns into getting angry with you for asking.

Every rental and service is so optimized against scammers and abusers that being a perfect legit customer ie. simply want to pay, use the resource, then return the item or terminate the service, you're walking along the edge of a cliff. Annexes, penalties, fees and charges, exclusions, "sign this one more form, everyone signs it". Housing rental is another extreme example, one is simply unable to just get a job in new location and rent something long term.

This applies even offline! Have you ever tried to get a hold of exact insurance policy wording before going through their entire sales process? Impossible, in my experience, whether it's long-term insurance, vehicle insurance, pet insurance, etc.

This is not a hard limit, this is just a webhook and you need to handle disabling everything on your own.

1. You can make mistakes in your code.

2. Some junior developer can by mistake change the code and make it ineffective.

3. Webhook is not instant so you can get billed more than the limit.

4. There is no information which project hit the limit, so you need to Fetch all of your project ID's and then disable all of them. You need to basically disable all the projects assigned to your team/organization.

5. Vercel doesn't guarantee in any way that you won't get billed more, they are just sending an information to you (with a delay).

Hard limit should be a deal between user and company that the user won't ever get billed more than X$