This is 100% open source and self-hostable.

https://github.com/cloudflare/cloudflare-os

It runs on top of our open source runtime.

https://github.com/cloudflare/workerd

Cloudflare seems mature enough at this point that if you're willing to accept any kind of vendor lock-in, then accepting it through them is likely acceptable. I won't say they're on-par with the big cloud providers, but if they offer the services you need and you'd be willing to lock-in with AWS, etc., then they should be considered.

If you're generally opposed to any vendor lock-in, then Cloudflare is definitely a hard sell. Many of their services are pretty specific to their ecosystem and I imagine trying to keep things portable would be infeasible any many scenarios. Granted, this is true in a provider like AWS, too, if you were depending heavily on their proprietary, managed services. But there's definitely value in knowing that you can stick to "generic" services as much as possible in AWS and be able to move away relatively easily.

Cloudflare is definitely becoming a "real" cloud provider (I'd say their release of R2, for me, pushed them into the "serious contender" category), but they focus on pretty specific features that aren't very portable. This Cloudflare OS service is a good example of that. If it is exactly what you need, then it is worth checking out and taking on the risk of vendor lock-in. But if you're doing something where long-term planning and portability is important, then you'll have a hard time warranting even considering them.

Yes. Be locked in. It's better to go 100% and only pay the switch costs if you have to.

Developing abstractions to let you switch technologies has 2 costs: The actual development, and not fully utilizing a specific technology. Lots of people prefer pain in small doses because it can be rationalized as eventual payoff.

There are degrees of this decision, of course, but I would say most folks worry too much about this particular champagne problem.

No, you’re not too paranoid. It has already proven both in the software and hardware world what vendor lock-in can lead to.

Also check out Bunny.net.

They also provide cover to those doing the dirty stuff which drives the need for their other products.

Not remotely paranoid.

I feel exactly the same. The CF services I do use are DNS and R2. I'd be curious if there's a guide somewhere that lists their services through the lens of lock-in. For example, R2 is somewhat S3 compatible so it's less risky to use because I can swap providers.

Any platform specific code or config can be replaced with self-built infrastructure. Everything else you write should be portable.

Cloudflare is hit or miss there.

They move pretty quick so they tend to ship a lot of product very quickly that have a lot of potentials. But they are very much MVPs, and you'll hit a lot of limitations that aren't always obvious at first blush. And then it can take years before they mature, at which point they'll pour a ton of resources and they'll go from useless to top tier in like 2 months.

It's really hard to tell.

The Vite plugin for Cloudflare Worker was one of those. It was really rough at first and I wasted hundreds of hours getting stuff working as advertised. And then in a week they fixed all the bugs.

AI Gateway is another. We used it at first because it seemed to check all the boxes, and turns out it had tons of limitations and almost none of the features of other offerings, with very few updates months+. And then recently they basically added all the features it was missing in a few weeks/months and now its good.

Agent SDK too, it was always behind with outdated dependencies and missing features all other agent frameworks had. And then one day they started iterating super fast and now its legitimately good.

You can never tell reading the docs, so you have to try it, curse because you only find the limitations once you're running the thing for real in production, abandon it, then a few months later its everything you could ever want.

I have a love hate relationship with Cloudflare. Mostly love, but still.

Yeah, with love the words "open source" mean a lot less here (de facto, of course not de jure) when the resulting open source product is entirely contingent on Cloudflare's PaaS.

And I think they suffer a little a little bit from their infrastructure being _comparatively_ unique. As providers go, they're on the harder end to replace with something else if you were to ever want to retarget your workloads.

Not at all too paranoid. Just like people figured out even with elastic everything, compute from Spot instances and all the other things we're supposed to do in AWS, the data out charges between AZ's and Region's still more than made up the cost savings for true resiliency. People are going to figure out relatively similar pricing traps in Cloudflare that are difficult to design around.

If you run an unindexed D1 query, then you get dinged for every row read. If you didn't properly perform scalability testing in non-production, then you'll never know this until you get a bill that you dissect to find out 5 million rows read for a 5 row result, if you even dig that far in the billing.

If you do not use the WebSocket Hibernation API with Durable Objects, then when you spin up a DO and hold open thousands of client WebSockets, you are being billed continuously for the entire time those connections are open—even if zero messages are being sent.

If you keep optimizing for payload size like many do by default but not event frequency (like poll a Worker every second instead of keeping a single stream open), it will show up unpleasantly in the billing.

If you treat KV like a transactional database keeping state, then be aware writes are expensive compared to reads. Pumping high-frequency write traffic into KV will result in exorbitant write operation costs and eventual consistency headaches. High-frequency state mutations belong in Durable Objects, not KV.

Batch your data to minimize request count, aggressively index your SQL queries to minimize row scans, and hibernate your idle persistent connections whenever you can. Doing all this will make your solutions cost efficient, but very locked into their ecosystem.

Cloudflare is just another corporation with greed in their eyes and if you don't design yourself to their puzzle than you're not welcomed.

This is an extra wall in walled garden land; another one you will need to jump if you want to break free. Another stab at gatekeeping the upcoming Ai era of the internet. It's no different to the playbook of Google, Apple, and Facebook of the 00's. So, no, you're not paranoid.

In the terms of security: My firefox on FreeBSD instantly triggers endless loops of "prove your human" on their turnstile. I can't use old handhelds of android and a single VPN triggers all. Anything that they don't see as "secure" you're denied from.

What is stopping Cloudflare from deeming your LLM as unsafe?

Scenario: You're ready to launch, you come up with the next best innovation for the next generation of Ai internet. Revolutionary and you're about to launch, blast off; wait. You're denied your launch because it threatens their service. The former: they like your idea more-so and clone it to become theirs.

Stories of above have all been posted on HN before. Startups have been sabotaged by rug-pulling of cloud providers. It is early-vendor lock-in and at it's best. Google & Co would be jealous; if they were not in bed with.

This will turn in to a netting of: Your Ai isn't using our service, so your Ai isn't allowed to interact with ours.

What does Cloudflare offer as a service? A turnstile to the Internet of Things and the difference this time is that you get to self-host your own corner on their patch of land with their ticket prices and access policy of.

Remember folks, no corporation gives a rat's ass about you. Internally, or externally, you're just another sheep to extract wool from.