Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropping Cloudflare for Bunny.net

jola.dev

Post reply on HN
Print view View original

161–170 of 225 posts

Re: Dropping Cloudflare for Bunny.net

#161

Post by gordonhart »

xur17 wrote: post #158
gordonhart wrote: post #64

Earlier quoted context omitted.

For personal projects, I'd rather just pay $2/month and not think about it than get hit with a random bill and scramble to migrate before the next month's bill. Bunny is perfect for this use case where you have a handful of projects that aren't all actively maintained. It just works without hand-holding, and since you're paying for the service, there's no rugpull looming.

Don't you still have to worry about big bills since bunny bills based on usage?

The biggest bill I've gotten from Bunny was like $10 when my app (https://atlasof.space) briefly went viral and got 100k+ views in a month. Bunny CDN is so reasonably priced and the realistic visitor ceiling for my projects is low enough that it's still negligible. The free->paid cliff is typically a lot steeper than this in my experience.

Re: Dropping Cloudflare for Bunny.net

#162

Post by mark_and_sweep »

jFriedensreich wrote: post #119
mark_and_sweep wrote: post #108

Earlier quoted context omitted.

AFAIC, WinterTC doesn't specify how to start an HTTP server. Their minimum common API requires, among other things, that the Request and Response interfaces from the fetch specification are present. Unfortunately, it does not specify any sort of serve function.

Because an edge runtime should not directly start servers in the first place. You provide handlers that fulfil requests from the system. Edge runtimes that pretend to start the servers in the edge worker context are flawed and ugly from the very start. APIs like that leak implementation details and increase vendor lock-in for no added benefit.

> > I don't understand how none of the alternatives really embrace WinterTC

> You provide handlers that fulfil requests from the system.

As I said previously, though I wish they were, such handlers are not part of WinterTC.

And then again, how those handlers are registered is also not part of WinterTC, which I also wish it were.

> APIs like that leak implementation details

How?

Almost all runtimes, like Bunny Edge Scripting, Cloudflare Workers, Deno, Bun, etc. use the same basic signature for the handler:

(request: Request) => Promise

Only how you register said handler is, unfortunately, different for each runtime.

Re: Dropping Cloudflare for Bunny.net

#163

Post by Kye »

broken-kebab wrote: post #116
Etheryte wrote: post #57

Earlier quoted context omitted.

Predictability matters. The whole point of paying someone else to handle a problem for you is that you don't have to worry about it. If you go all in on a provider and then suddenly find out that you've been switched to a paid plan in the middle of your vacation, that's not a place anyone wants to be. Saying there's no lock-in is nice, but that overlooks the fact that there most definitely is friction. What if there'…

It's impossible to generalize over free vs paid in regard to predictability. E.g. a provider I paid for simply disappeared once when I was quite busy while my old free gmail still works. Realistically CF's free tier is more predictable than many paid options on market.

My threat model here focuses on what the provider gets out of the free tier. Cloudflare gets a broad view into activity on the internet for building the models they use for their paid offerings. Free Gmail puts people on a path in to Google's ecosystem with basically zero marginal cost.

Re: Dropping Cloudflare for Bunny.net

#164

Post by mark_and_sweep »

jFriedensreich wrote: post #140
whh wrote: post #135

Earlier quoted context omitted.

FWIW, Cloudflare's edge platform is pretty proprietary too.

The platform yes, but the runtime and the APIs are apache 2.0 licensed and uses web standards wherever possible. Thats way more open than most alternatives i am aware of.

Their fetch handler [1] is not a web standard.

[1] https://developers.cloudflare.com/workers/runtime-apis/handl...

Re: Dropping Cloudflare for Bunny.net

#165

Post by aeden »

evolve2k wrote: post #13
evolve2k wrote: post #7

I’ve mainly been using cloudflare for the very excellent (and free) premium DNS offering. Easy upload of bind test files Flattened CNAME to support naked domains Robust free role based permissions to add other ppl Anyone have suggestions for moving a stack of domains, many being little community and hobby projects away from cloudflare for a small overall price. Agency pricing like migadu offers for email on custom do…

I should add a friend has recommended DNsimple.com and I’ve previously found their service to be excellent. https://dnsimple.com/ 50 cents per domain per month 10 cents per million queries That’s prob cheap enough to support lots of little hobby sites and bigger traffic sites likely have some budget.

Thanks for recommending us, I (and the rest of the team) appreciate it.

Re: Dropping Cloudflare for Bunny.net

#167

Post by wonger_ »

xur17 wrote: post #158
gordonhart wrote: post #64

Earlier quoted context omitted.

For personal projects, I'd rather just pay $2/month and not think about it than get hit with a random bill and scramble to migrate before the next month's bill. Bunny is perfect for this use case where you have a handful of projects that aren't all actively maintained. It just works without hand-holding, and since you're paying for the service, there's no rugpull looming.

Don't you still have to worry about big bills since bunny bills based on usage?

https://support.bunny.net/hc/en-us/articles/360000235911-How...

> Minimum Account Balance

> In order to keep your service online, you are required to keep a positive account credit balance. If your account balance drops low, our system will automatically send multiple warning emails. If despite that, you still fail to recharge your account, the system will automatically suspend your account and all your pull zones. Any data in your storage zones will also be deleted after a few days without a backup. Therefore, always make sure to keep your account in good standing.

You proactively replenish your balance, so in the worst case, you can just let the account go.

Re: Dropping Cloudflare for Bunny.net

#168

Post by nazcan »

sophacles wrote: post #121
samlinnfer wrote: post #60

I do have a question, is it even possible to have a CDN set up where they don't MITM and strip your TLS and re-encrypt or are we just picking which jurisdiction gets to inspect your traffic? edit: I'm thinking of the use case where the CDN as a proxy for APIs and uncachable content as well, where it used as a reverse proxy for transit/ddos protection.

Why would you want a content delivery network for uncachable content? Literally the point of CDN is to cache content and deliver it. Granted cloudflare also does DDOS protection, and that makes sense for an API. For that you could do some DDOS protection without stripping TLS, but it can only protect against volumetric attacks like syn/ack floods and not against attacks that are establishing full TCP connections and…

It seems like having a feedback loop to the DDOS protector could help a lot - i.e. saying how busy you are.

At some level, it's like they become your edge router.

Re: Dropping Cloudflare for Bunny.net

#169

Post by kentonv »

shimman wrote: post #152
jFriedensreich wrote: post #140

Earlier quoted context omitted.

The platform yes, but the runtime and the APIs are apache 2.0 licensed and uses web standards wherever possible. Thats way more open than most alternatives i am aware of.

Unless the project is controlled by democratic committee where cloudflare doesn't have a majority of seats it's not open source in any meaningful sense of the word, maybe we should stop acting like corporate sourced software is anything but an attempt to get free labor from the commons.

I can assure you that nobody at Cloudflare ever thought that open sourcing workerd would be a way to get "free labor from the commons". On the contrary, we are wary of external contributions. The Workers Runtime is a complicated codebase, and we invest a lot of time into getting new team members up to speed on how to write code correctly. We cannot make such an investment in external contributors who are only there to land one PR. Usually, a one-time contributor trying to do something complicated will waste more of the team's time than they save.

But in practice, we almost never receive major contributions from outside the team. Which is fine. We're happy just to have our team working in the open.

The reasons we open sourced it are:

1. Support a realistic local dev environment (without binary blobs).

2. Provide an off-ramp for customers concerned about lock-in. Yes, really. We have big customers that demand this, and we have had big customers that actually did move off Cloudflare by switching to workerd on their own servers. It makes business sense for us to support this because otherwise we couldn't win those big customers in the first place.

Post reply on HN