Looking at the docs for their JS SDK, they have this warning:
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
https://developers.cloudflare.com/flagship/sdk/client-provid...
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
Let's think about it. This is probably something used internally at CloudFlare and someone thought I'd be interesting to make it public.
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
Hmm not sure I necessarily agree. Cloudflare's strategy has been looking like "the only platform you need" for a while now.
Their recent features / announcements have been equivalent to:
(LaunchDarkly)
Resend, Firecrawl, CrewAI, Helicone, Replicate, Pinecone
-
Which like… many companies have a painful procurement process. If all you need is Cloudflare, and prices are within reason- why not use them
Their quality of the products they ship have already became shitty for quite a while now.
they are quickly turning into a slop shop
instead of polishing their existing products (and most of them do require a lot of work) they jump into any other niche someone thought was a good idea. My guess is that with ai being able to prototype things quickly they just started doing everything that is even a bit relevant.
which won't end well
I think they were doing that before AI got big the last couple years.
Their core network stuff always seemed pretty robust but all the newer stuff was much more thrown together. Thinking specifically of Zero Trust/Argo Tunnels which has been around a few years (and I do like) but has some rough edges.
Don’t forget they now also have an OpenRouter alternative.
[dead]
Both Cloudflare and Vercel have feature parity. Flags is a feature already in Vercel. While customer-first is a thing, it is also a no-brainer to start with: we use it, Vercel has it, let us build it.
Now waiting for Cloudflare to allow me to use Rust for serverless, real native code, not WebAssembly.
https://vercel.com/docs/functions/runtimes/rust
They have containers, does that count?
If you’re specifically thinking of native ephemeral workers with very fast startup, it seems like those would have to be sandboxed somehow, and WebAssembly seems like a decent solution. Is there really a significant native code gap between WebAssembly workers and native containers?
Containers seem to only be "Available on Workers Paid plan", whereas Vercel supports it on the hobby account as well.
Kind of relevant on those cheapskate projects that only start paying licenses after the SOW is signed, but already expect some kind of prototyping in place.
WebAssembly is a solution looking for a problem outside the browser, with worse development experience.
If I want bytecode based runtimes, I already have them with first class development experience, and decades of deployment experience, between Erlang, JVM and CLR.
Haven't used Vercel but back in the Heroku/CloudFoundry days it was pretty easy to jam arbitrary binaries into the runtime containers and some of the build packs were flexible enough you could override most of the functionality.
Not sure if that's possible/how easy it is on Vercel
https://blog.cloudflare.com/flagship
Here's why we built it!
>Agentic coding tools like OpenCode and Claude Code are shipping entire features in minutes.
How many minutes do I need to wait until app-scoped tokens are live?
Sorry, just reached the weekly token limit.
Ah, no-look coding.
How can we possibly trust the AI to disable the 'CODE_IS_SKYNET' flag.
Care to share why
Jane Wong salivating reading this
Hi! One of the engineers from the Flagship team here, app-scoped tokens are WIP.
That sounds like the product is not finished and should not be released?
"If you are not ashamed by what you are shipping, you are not shipping early enough" (Quoting from memory)
That’s really about creating an MVP for a startup, because too many founders stay in a cave trying to make it “perfect” before collecting valuable user feedback.
This does not apply to Cloudflare, especially not for an auth token that needs to be published on your website that cannot be restricted.
If your engineer tells you that, you're going to have a bad time.
I think you're thinking this:
> If you are not embarrassed by the first version of your product, you've launched too late. -Reid Hoffman
That's a terrible attitude for an infrastructure company. This is what private betas / close iteration with customers is for.
This has been the Cloudflare standard operating procedure for the last year or so. Non stop shipping alpha/beta products.
Otherwise known as vibe code snacking. Vibe out the easy 80% and say the hard 20% is “coming soon tm”
Is it perhaps available behind a flag somewhere?
Then it's not finished?