rita3ko

(confession: i work at cloudflare)

but we just made our first announcements for this week, including: - d1 (our serverless database) going GA - hyperdrive (SQL query cache for postgres and mysql) going GA - and workers analytics engine

if you just moved off google domains, i recommend checking out cloudflare pages, which is cloudflare's product for hosting static and dynamic sites (with gitops, everything else included).

you can do both! all of our models are supported either via workers / pages binding (which makes it really easy to host the rest of the logic), and via REST API

docs: https://developers.cloudflare.com/workers-ai/get-started/res...

(llama specific example here too under curl: https://developers.cloudflare.com/workers-ai/models/llm/ )

we always are! email is rita at cloudflare dot com :)

stay tuned!

we (cloudflare) have a great example of a vector database build on workers + kv here: https://ai.cloudflare.com/demos/vector-store/

(plan to talk about how we built it soon)

edit: clarify i work at cloudflare

What details are you looking for? Maybe we can fill you in :)

We still have some work to do to get the runtime ready to open source and make it broadly available, but happy to answer any questions we can.

it sure is: https://boards.greenhouse.io/cloudflare/jobs/3156953?gh_jid=...

Pages itself has been GA for a little while now (https://blog.cloudflare.com/cloudflare-pages-ga/). For the integrations with Workers, it's TBD (we generally want to leave things in beta for a bit and let it bake in before giving you the thumbs up to put your production site on it), but we move fast, so likely sometime in the first half of next year.

hi there! i'm on the workers team at cloudflare.

you're right that the ideal application would run fully on the edge (which is why we try to offer things like KV, Durable Objects, and more options in the future for you to have your data where your logic is running).

however — moving your data to the edge is unlikely to happen overnight. and it's going to take us a bit to offer you all the data options for all the different use cases that you need (after all, there are many types of databases for a reason), so this gives users greater optionality. secondly, if your data is already somewhere but you want to build new features on top of it, now you can. (say, i already have a database with all my apartment listings in it, but i want to add a new feature where i let my users add photos of the apts). i can now build that feature in workers, without having to undergo an otherwise massive migration.

one last thing, this is just the beginning of what even database connectors mean. in the future, we can cache data, and actually improve performance and reliability even if the dc is far (as you said, make it easier to have best of both worlds).

also a good time to mention that if you build something in in rust using workers, you should submit it to win some free swag:

https://challenge.developers.cloudflare.com/

jam.dev are good friends of ours (both founders ex-cloudflare and some of my good personal friends!) :) but was thinking about it more as a play on jamstack.

re: excluding branches — we're actively looking into it!

and yes, that error has been fixed AFAIK, but let me double check.

Yes, it's included in the existing plan if you already have Pro / Business.

There's a bit of background here https://developers.cloudflare.com/pages/migrations/migrating...

TL;DR: Workers Sites is basically an elaborate Worker template (which you can modify) and allows you to deploy your sites using the Wrangler CLI — it'll take care of uploading your assets and all, but you're responsible for setting up CI, etc for a continuous deployment experience.

Cloudflare Pages, by contract, integrates directly with Github, which allows us to offer a lot more features out of the box, including running your build, preview URLs, etc.

Hope that makes sense.

Hey there. I'm the PM for Pages. That's fair feedback (though a lot could have changed even in the past few weeks, so I would recommend taking another look)

- It's hard for me to tell what's causing the issue (the build logs should give an idea of at least at which stage). One thing we've added over the course of the beta is connection to GH comments, which requires a new type of permission. So that might be causing the failure, but also, failed builds should result in a comment (and email) for notifications, depending on your GH settings. All of that said, my email is rita at cloudflare if you want to forward me more details, I can help look into it.

- Creating a canonical notion of your domain is something we're thinking about. Right now the preview links will set X-Robot-Tag so they can't be crawled but yeah, ideally we want to give you a way to remove myproject.pages.dev if you're not using it

- The cache-control settings are intended to keep your site from serving stale content by relying on etags — your browser should still serve from cache if the asset hasn't been updated. On the Cloudflare site, we have much longer TTLs.

Anyway, thanks for trying Pages! We're continuing to iterate on it, even after GA so should only be getting better :)

(edit: spacing :P)

hi there! cloudflare pages pm here :) we certainly plan to (nothing against gitlab!!), likely in the next couple months. my email is rita at cloudflare. happy to keep you posted

Genuinely curious — what would you expect to get from containers that you can't get from building on Workers + Pages as described above?

Sorry about that — had to keep them separate to avoid spoilers ahead of launch, but trying to avoid a migration on launch day.

To satisfy your curiosity though for our Gatsby setup, you can actually check it out here: https://github.com/cloudflare/cloudflare-docs (the rest of our docs are open source and built in the same way, the Pages docs will just go there as a subdirectory, same as the other products).

Doc engine itself is here: https://github.com/cloudflare/cloudflare-docs-engine

You're just one step ahead of us :)

We'll be working on building in one-click configuration to have Cloudflare Access in front of your preview deployments specifically for this purpose.

More good news: we support private repos today :)

Hi there, I'm the PM working on Cloudflare Pages. We don't have support for this now since we're still in beta, so not everything is there yet, but it's certainly a use case we intend to support. You'll just be able to specify no build step. :)