🚚 Custom Domains for Workers GA + Workers for Platforms

Hi, everyone, and welcome to Cloudflare TV. We are on our third day of GA Week, and we're here to talk about two very exciting announcements.

If you're just tuning in right now, we've actually split up.

We have a birthday week every year, and we split that up into two weeks this year.

So we have GA Week, where we're announcing exciting products that customers can get their hands on today.

And then birthday week is for our more aspirational announcements to give you a little bit of insight into what we're thinking at Cloudflare and things that we'll be GAing in the coming months ahead.

So today, we're here to talk about custom domains and workers for platforms.

We'll start with intros, and then we can dive into things.

My name is Tanushree, and I'm on the product management team. Specifically, I'm the product manager for workers for platforms, and excited to be joined by my colleague, Kabir.

Kabir, you want to give a quick intro? Yeah, thanks. I'm Kabir.

I'm also on the workers product management team. I'm excited to chat with you all about custom domains and workers for platforms.

Okay, awesome. Let's get into it.

So custom domains or GA, super exciting. Congratulations. Do you want to start off by just giving us some background?

What are custom domains? Why are they useful?

Yeah, definitely. So I'll talk a little bit about the problem here that we started noticing.

And I've been at Cloudflare for a few years now. So I've seen this over the years.

Developers from organizations of basically all sizes, all shapes, all forms tend to have trouble with one of the most important parts of building an application on the web today.

And that is DNS and certificates. No one really likes handling it.

No one really likes dealing with it. But turns out Cloudflare is one of the best in class DNS providers.

And we're pretty good at certificates too.

So for custom domains, what we set out to do is ease the developer experience when connecting your workers to the Internet.

So we built custom domains to streamline that process of hooking it up.

You just type in a host name and Cloudflare will issue the necessary certs and DNS records on your behalf.

We give you really easy to use feedback if anything goes wrong along the way.

And we're hoping that this helps ease the process of setting up your worker. Got it.

Okay. That's great. I know that personally when I got started with workers and when I'm putting on the developer hat, I just want to focus on writing code and all of the backend that goes into it is super important to make things functional, but it's a little bit of a headache to deal with sometimes.

So I love that it helps smooth out the developer experience.

So I know today's blog post, you wrote an example application that's built entirely on Cloudflare's developer platform.

Can you tell us a little bit about this application?

How is it architected and how does it work?

Yeah, definitely. So custom domains of course help smooth out that developer experience.

You can focus on your code, you can focus on writing your application.

You don't have to deal with the frustrating sometimes infrastructure bits and that glue piece.

Cloudflare is really good at doing the glue and doing that for you.

So while that's the main purpose of why we built custom domains, it's not the only thing that it does.

In the past, your worker was always a proxy between your user and some sort of an application server or an origin server or a database, whatever it was.

You always had this concept of your user is going to talk to a worker and the worker eventually is going to talk to something else that's outside of Cloudflare.

With custom domains, when you hook your worker up to the Internet, you're telling the world, hi, I'm an application that's built on Cloudflare's global network.

And that is really powerful because Cloudflare happens to run one of the world's largest global networks and it happens to be close to almost every single user on the Internet.

So I think this can bring a little bit of a shift in what the definition of a modern application is, how they're set up.

But you no longer have a single application server that you have to deal with, or you don't have to deal with a single region or even replicating your application across multiple regions.

And you don't have to deal with load balancing. These are all things that happen when you do have that single origin server or set of origin servers that sits in some place outside, away from the user.

With workers, we're instantly scalable.

You're global by default. You don't have to deal with regions at all.

Any user can hit your worker from any Cloudflare data center. And with custom domains, you're saying, hey, there actually is no origin server to go home to.

The worker is my application. And it happens to run everywhere. Now, the application code isn't obviously, it's not the only thing that's part of an application.

As you may have heard, Cloudflare is also building a lot of storage products.

That's another announcement that we had today. And I'm sure you'll see more in the future.

So not only does your code run everywhere, but your data is going to be more accessible as well.

In today's post, we talked a little bit about that.

We gave a sneak peek of our application using D1, which is in a private beta right now.

If you want to go try that out, you can check out the blog post.

And there's a link in there to get invited to the beta. Or you can join us on Discord to get more info.

But yeah, this application was a simple to-do app. It's developer examples that you'll see.

If you look at any new platform, you'll see someone's built to-do.

It's like one of the really great intros because it's useful.

It's easy to see how it can scale. It's easy to see how it can become a full -fledged application.

And we built that using custom domains, workers, and D1. Got it.

That's awesome. I know that when we first started workers, a lot of our customers would use it as a proxy.

So it's between an eyeball and their origin. And while workers has a lot of performance benefits for customers, it'd still be the additional latency of going to your origin.

So super awesome that we're releasing more and more tools to be able to actually post your applications on workers.

And you don't need an origin server. You don't need to maintain any of that.

Both for big enterprise companies and also for small startups that are only built on workers.

That's super awesome to see. So tell us a little bit about the beta testing period.

I know that custom domains was announced and you've been doing a beta for a while.

How did that go and how did that translate to some of the stuff that we now see in the GA version?

Yeah. So a little bit of history here. Over the past few months and years, we've been slowly building up more and more capabilities on Cloudflare to help you build full-scale applications.

We had towards the beginning of the year, I think it was Q2, we had a full-stack week and a platform week.

And so those two in tandem, we released custom domains during the platform week into a beta.

We found that it was a great time for developers to start building their whole applications on Cloudflare's network.

During the beta period, huge shout out to all the developers that went and tested it and started getting their hands dirty with custom domains.

We had over 5,000 developers actually use it during the beta period and north of 10,000 custom domains were being created across the platform at any given moment.

And so for today's announcement, we wanted to give a little bit of like a follow-along guide on how you might build your to-do application.

It's pretty simple. It's fast to set up. There's a GitHub link in the blog post so you can take a look at that and follow us as we keep adding more to that.

Today, we just focused on the API. In the coming weeks, we'll start to do things like build a UI on top of it and talk a little bit about what the developer experience looks like there.

So really excited to flesh this out.

Going back to why we ended up building this, we believe the future of building your applications is not in a single data center.

It's everywhere. You build something.

It's easy to set up. It's easy to build. You don't have to deal with all the glue.

You just focus on building your application. Yeah, for sure. Super cool.

And so if I'm a developer, I'm really excited about custom domains. How can I get started with it?

How can I get my hands on it? Yeah. Great question. If you're using Wrangler, you can just go into your routes section of your Wrangler file.

There's some docs on how to get that set up within the custom domain section or routing section of our developer docs.

And you can just specify custom domain equals true.

If you're using your UI, the Cloudflare dashboard and the API both have access to custom domains.

So you can just go into your worker, hit the triggers tab, and you'll see custom domains right there and you can just click add.

So real easy to get started.

It's available for everyone today. Okay. Awesome. I love when we have things that are self-serve, ready to go.

Cool. That's good. Awesome to hear about custom domains.

I'm happy to switch over and talk about workers or platforms now.

Yeah. Yeah. Yeah. I mean, I think maybe interesting to talk about both of these at once, right?

Because first we chat a bit about building your modern application that's on a global network.

And what if you're not just building an application like to do?

You're building a platform. So we've announced workers for platforms in the past.

Janusha, why don't you give us a little bit of a segue? What's it all about?

What was today's announcement? Yeah. Yeah. So initially we announced workers for platforms during platform week earlier this year and over the past few months, we've been slowly onboarding customers, both customers that range from big enterprises that want to use workers for platforms, startups that are building the next big thing that want to go originless or have their origin on workers, and also end developers that are working on hobby projects that want to use workers for platforms for new use cases that it unlocks.

I was actually surprised to see so much interest from our workers paid plan.

I thought that initially thinking about this product that would be geared more towards enterprise offerings, but there's been a lot of excitement from developers that are on our workers paid plan that want to use this as well.

So it's been super awesome to see that. And we've been onboarding customers, getting feedback, and finally excited to GA this.

We're starting with a GA for enterprise customers, but as always, we're bringing it down to the paid plan as well.

So I'll give you a bit of background about what workers for platforms is before we dig into things further.

Workers for platforms is our solution for deploying workers at scale.

This is typically geared towards SaaS use cases.

If you're a SaaS company or if you're a developer that wants to allow end users to deploy workers on demand for each of your end customers or end users.

And the value prop here is that we're giving our customers the ability to upload code that runs their own behavior.

Things like automated actions based on events that come in, sending or receiving data to or from third party APIs, or modifying the payload that comes in to respond with custom content, again, based on properties of a request.

And all of this happens securely. It all happens scalably.

It's all using workers under the hood and any end developers don't need to worry about setting up their own hosting.

They don't need to go to a third party platform.

It's all using workers behind the scenes. So it's super easy for end developers and also for our direct customers to be able to offer this out.

And the real reason why workers for platforms, the motivation behind building it is that there was a big customer pain point that we saw around adoption.

So this is for our customers' customers.

And SAS customers typically have end users that are in various industries.

They're in different regions. Each company has their own best practices.

They have their own internal tools, processes that they follow.

And it's almost impossible to build a platform that has a wide market but is also niche enough to satisfy each customer's use cases.

And we've noticed that customers spin up whole teams or dedicate developers towards doing integrations and customizations.

And that's valuable developer time that can be spent on their core business that they're actually spending figuring out third party APIs, figuring out how to connect to data sources.

And so that's where workers for platforms comes in, is that you can offload that to your end customers who are familiar with exactly what they want to do and give them the opportunity to customize your platform.

Yeah. So long spiel, but hopefully that's great context to get into more details about workers for platforms.

Yeah. That makes a lot of sense. I mean, we've seen this pain point even here at Cloudflare, right?

We have a lot of core businesses that do need some customization.

I think that was one of the genesis of why workers was initially used as kind of a proxy layer in between, right?

So we can now start to give our customers the ability to use that same platform on their platforms.

Totally. And we're talking to internal teams also about this and figuring out ways that we can let Cloudflare customers use workers in ways they haven't been able to before.

Yeah. That's always been a great ethos that I've noticed while we've been working here is customer zero, right?

The concept of use the things that you are building for your customers and start to drive them further.

So in this process and journey of building out workers for platforms, you guys have had beta for some time.

What are some of the trends, use cases, general notes that you have from that beta period?

Yeah. So I've spoken to quite a few of our beta testers and I find that generally use cases fall into four categories.

I mentioned customization.

That's one of the most prevalent ones that I see. So letting end developers write custom logic in response to events.

One example here is I spoke to a B2B fintech company.

They were interested in using workers for platforms to allow their end users to write logic to handle different types of transactions that came in.

So let's say there's a transaction that came in, it was in a specific currency, but this company is global.

They want to have a percentage of that money go into currency A and then the other one into currency B.

And there's also fancy things that you can do there, like depending on what the conversion rate is, set different percentages, you can sort of get complex with that.

But that's one of the use cases of this customization that came up.

The other one that we see quite often is integrations.

So customers want to allow their end users to build out integrations with other platforms.

An example of this is like Slack or Discord notifications when an event takes place.

I know that one use case that I was thinking of is I would love to get notified each time a new user signs up for one of our waitlist products.

It would be really nice to be able to keep track of things like that.

And so you can imagine just all of the applications of different integrations that will make end customer lives a lot easier.

And CRMs are also a big part of this.

When you have a platform that's supposed to take in data from multiple sources, there's sort of those never -ending requests for integrations.

So it's really interesting to be able to use workers for platforms and let your customers create those.

The other use case that comes up is white labeling workers. So using workers behind the scenes to power a whole platform.

This is sort of the hosting piece of it, but also we're coming out with tools to help the developer piece of it.

So allowing end developers use a Cloudflare IDE that we provide our customers with.

And then just hit a button and deploy an application and everything happens behind the scenes.

And then the last one that kind of has some overlap with what I've mentioned before, but is custom webhooks.

So sort of having like a hosted webhook solution on Cloudflare Workers.

So customers don't need to set up their own webhooks on a third party.

A lot of customers support this sort of third party webhook integration, but it's just an extra step for their end developers to use.

And workers for platforms makes that a lot simpler.

Amazing. Yeah. Some of these use cases I'm really excited to see get built on workers in the near future.

It's cool to see that we can do this globally and give it to everybody at scale.

I know if you're a customer today and you're interested in using workers for platforms, it does introduce a few new components.

Could you walk us through what those are for anyone new?

Yeah. So the biggest and most powerful one is we have a new concept.

It's called a dispatch worker. This dispatch worker is written by our direct customers.

And I kind of like to think of it as an admin worker.

So this is something that you write. That's the first touch point for all incoming requests.

And you're able to run off. You're to enrich requests with specific data before any requests then get routed to your end customer workers.

And this is a super useful tool because we've noticed that our customers want to have more control.

That's a big thing that comes with workers for platforms is that it's a bit scary allowing end developers to write code that runs between your systems.

So with this dispatch worker, you're able to parse requests coming on the way in, send them to the right end customer workers, but also sanitize responses on the way back and make sure that any of the data that's coming back is up to par with your standards.

There's nothing that's leaking. And then we also have this concept of user workers, like I mentioned.

And these are these can I just think of them as regular workers.

So these are written by our end customers customers.

In some cases, they don't even know they're writing workers. They're just uploading JavaScript and it magically runs behind the scenes, which is super cool.

And yeah, these workers are called by the dispatch worker. An example of how this works is that some of our customers want to be able to call user workers based on the subdomain of the request coming in.

So a request will come in, it'll go to their dispatch worker.

So the dispatch worker will parse the URL and then send the request off to the user worker that matches the subdomain.

So that's sort of how the routing happens.

And then the third new concept here is a concept called dispatch namespaces.

And I find typically that the easiest way to explain this is we have a concept called service bindings already.

This is where you can bind two workers to each other.

It really helps break down your application so you don't have one big monolithic component.

It helps break things down and you can declare what needs to talk to what.

Dispatch namespaces are really similar in that you can connect dispatch workers to user workers.

The only difference is that this relationship doesn't need to be defined, doesn't need to be predefined.

So the way that it works is that you would have a binding on your dispatch worker to a namespace.

And then you would upload any user workers to that same namespace.

And then the dispatch worker can call out to any user workers in the namespace.

The difference between this and service bindings is that with service bindings, you know which workers are going to be called out with namespaces, with dispatch namespaces.

Because user workers are being uploaded ad hoc, you're not able to create that predefined relationship.

So it allows you to, gives more flexibility, but allows you to call out to the same functionality.

Yeah, that's a great distinction.

Actually, I've had to make this distinction a few times with customers as we've gone through the data period for both of these.

So I'd like to think of it as service bindings are really for your small microservices or service mesh or whatever it is.

You know every single service in the architecture in advance.

But it sounds like with dispatch namespaces and the dispatch worker, you can do all this at runtime.

And it doesn't matter if a user uploads a new worker, that request is going to get routed because your dispatcher already knows how to handle it.

Yep, exactly. That's cool. So I remember last week we shared with the team internally a really neat and interesting demo on the Workers4Platforms product.

Would love to see that today if we can share it with the folks watching. Yeah, totally.

Give me a second to just share my screen here. All right.

Can you see that clear? Yep. Okay, cool. I'm starting off high-level overview with just showing you the docs.

Workers4Platforms lives under Cloudflare for Platforms, which is sort of a new distinction that we've created if anybody's wondering.

But if I'm a SaaS customer, I want to get started with Workers4Platforms.

These are the general steps I would follow. So I'd first create a dispatch namespace.

This is where my end user workers are going to be uploaded to. I would then create a dispatch worker.

This is, again, this is the admin worker that as a SaaS customer I would write.

It's created the exact same way as a normal worker would, but it has a special dispatch namespace binding.

And then that's it.

Once I have that, I can start uploading user workers to my namespace. And any user workers uploaded to this namespace are going to be accessible through the dispatch worker.

It's super easy. We also have a new feature called tags.

You can tag user workers. This helps because oftentimes our direct customers upload versions of a worker for every commit that their end developers do.

And if you want to be able to see how many workers, which scripts a direct customer has, you can tag them all with the customer ID, some sort of identifying character there so that you can perform operations in bulk and also generally see how your customers are using the product.

I'll jump into the demo now. I'm going to switch tabs.

This is a demo project that we've been working on internally. We also have a public GitHub repo that we published recently that shares the code for this, if you're interested.

It's linked in the blog post that we released today.

But here I am. I'm on the admin portal to start off with. We're also using D1 for this project.

So, we're using D1 to manage customers and tokens. You can see we have two customers here.

This is customer one and customer two. They have IDs.

We're also managing tokens here. So, each customer ID is associated with a specific token.

Our workers are running in a multi-tenant environment. So, some basic level of auth is really important.

Obviously, this is an example. The tokens are free to see here.

Not a best practice to follow. But for the case of this example, just showing you how that's set up behind the scenes.

And then we have a dispatch namespace here.

This is called workers for platforms example project. You can see we have four scripts uploaded.

But I want to add another one. So, I would navigate over to my customer portal.

So, I'm customer one. This is my token. I'm going to upload it.

And I'm going to also upload my script five here. And I just have a very, very simple request handler here that responds with hello world.

So, I'm happy with this.

I'm successful.

And if I go back to the customer portal. Oh, sorry.

If I go back to the admin portal, you can see that my script was uploaded here.

And it's really cool because as an end developer, you don't even know this uses workers.

I can actually navigate to my script as well if you want to see what the response looks like.

You can see it's just a very basic hello world response.

Yeah. And then we also newly released a UI for workers for platforms.

So, this is accessible for any platforms customers if they want to be able to see which workers have been uploaded to a namespace.

And then actually see analytics about end workers as well.

So, I'm going to navigate to my Cloudflare tab here.

You can see the team's been doing a lot of testing. But I'm going to go to the workers for platforms example project today.

These are all the scripts that have been uploaded.

And then I can click on a script. I can see the tags that I've associated with a script.

And these are the same ones that are listed here in my D1 database.

And then I can see analytics about my script. So, you can see that there was a peak in requests.

We had about a thousand requests in the past two hours or so.

And then it died down. So, it's super cool. And this is very useful if your end customers are experiencing errors.

This will help identify that. And then you know to go look in the logs.

So, yeah. Super excited. This just got released today.

I'm going to go back to this example project here. Also show off some cool features that we have in the customer portal.

If I was to upload a corrupted script, doesn't follow the right syntax, you'd get an error back from the Cloudflare API.

So, this is all using workers behind the scenes. And as a platform customer, I can either choose to return this directly or I can wrap this around with my own error handling to make it nicer and to make it a customized experience.

Yeah.

So, that's about it. I'm going to stop sharing my screen. Yeah. This is great.

So, okay. I got really excited about workers for platforms. I don't have the craziest cool idea, but I want to go and build it and I want to go see what I can do.

What do I do today? How do I get started? And also, what if I'm one of those customers you mentioned on the paid plan?

Yeah. Yeah. So, if you're an enterprise customer, an existing Cloudflare customer today, you can reach out to your CSM and they'll get this enabled for you to try out.

If you are on the paid plan, we haven't forgotten about you, we're still onboarding customers to the paid plans.

If you want to try it out, please message me in the Discord channel. You'll see that we have a workers for platforms channel where you can find my username.

Let me know what your account ID is. We want to get Pago customers started on this.

But we'll very soon be officially GAing this for Pago customers as well. So, I would, again, just stay tuned on the Discord for when that happens.

Awesome. So, I think if you don't know where the Discord is, there's a bunch of links in all of our blog posts.

So, you can go and check it out. But I think we're up at the end of the hour here.

So, great to chat with everyone today and excited for what's to come in the rest of GA week.