Deploy to a Custom Domain with Cloudflare Wrangler Environments

Kristian Freeman: [0:00] In the last lesson, we took our worker, added some interesting country specific code to it to render based on where the user is in the world. Now for a final exercise, let's deploy this to a custom domain.

[0:13] If you have a custom domain -- for instance, your personal website or blog -- this is a great way to test out how powerful workers is for custom routing and things like that, but if you don't have one, you can watch this video. It'll be really quick. Then, you can come back and use this info when you're ready to use a custom domain with workers.

[0:32] There's only one caveat that you need to know, which is that you need to have your domain added inside of CloudFlare. For me, I'll just pick a signalnerve.com, which I already have registered. I've just come to it here in my CloudFlare dashboard.

[0:46] In order to deploy things using CloudFlare workers to my custom domain, there's only two pieces of information that I need. The first is my Zone ID. This is just found here by scrolling down from the dashboard, down into the Zone ID section. I'm going to copy that, and I'm going to paste it inside of this Zone ID field right here.

[1:08] The other thing here is the route. By default, I can pass pretty much any route that I want here. For instance, I could say https://signalnerve.com. Then, I could pass in a wildcard route here, which says, "Anytime that someone comes to any URL on signalnerve.com, return with this Worker," so I can do more complex things like, say, for instance, signalnerve.com/about/star.

[1:37] Now, I can do things like match any route inside of /about/ whatever value I want to put here. What I want to do for now is deploy it on a subdomain. I'll say, for instance, helloworldworker.signalnerve.com/star. In this case, I don't even need the wildcard. I'm not going to set up any other paths or routing here. I wanted to return on this helloworldworker.signalnerve.com.

[2:09] The last thing I need to do here is something that you don't need to do, but because I'm doing a demo, I need to come and grab my actual account ID for my real Cloudflare account, or where my signalnerve.com domain is hosted. This is only because I have a test account that I've been using here on Egghead.

[2:27] You can ignore that part and keep the account ID that you still have, but just in case you notice that it changed, that is why. The last thing that we need to do here is come back into the dashboard, and I need to set up a DNS record real quick.

[2:43] The reason that I need to do this is that if you're not super familiar with DNS, Cloudflare needs to know where this URL, this helloworldworker.signalnerve.com, it needs to point to something in order for Cloudflare servers to resolve it.

[3:01] There's a really easy way to do this. I'll just come to Add Record here. I'll set a CNAME, which you can think of as an alias. It says this name here is an alias of target and has its traffic proxied through Cloudflare. My name here is going to match this route, so helloworldworker. I'll just do that here. You can see helloworldworker.signalnerve.com.

[3:29] The target here, I'm just going to put the @ symbol. This represents the root of my domain. I'm just going to say helloworldworker.signalnerve.com is an alias of signalnerve.com and has its traffic proxied through Cloudflare.

[3:46] The reason that I do this is that I'm not actually going to route this subdomain, helloworldworker, to anywhere outside of Cloudflare. Instead, I'm just going to have it sit. I'm going to say, "Hey, this is a subdomain that you should know about." The way that Cloudflare servers are going to work is it's going to return directly from Cloudflare servers by executing your Cloudflare Worker script.

[4:10] You can put pretty much anything you want here. As long as you have a Worker set up using the same routing structure, this will basically get ignored, but because of the way that DNS works, you do have to have some sort of value set here. I'm just going to save that. You can see it's set it up here as a CNAME of signalnerve.com.

[4:31] The last thing that I need to do here is now I need to pick between workers.dev and route zone ID. What's happening here is, as you might remember, we had deployed something to myworker.kristianfreeman.workers.dev. That is my workers.dev instance. Traditionally, we think of that as your development or your staging environment.

[4:54] What this means is that you may want to deploy stuff to workers.dev if you want to test things. Maybe you add a new feature or you're experimenting with a new layout and you want to deploy stuff before it gets to production to make sure that it looks like you'd expect. Maybe you want to share it with people and say, "Hey, how does this look?"

[5:12] Once you're ready to actually deploy it, you may also want to deploy to your route. You want to deploy to your real production URL on your real zone, that's your domain. We have built-in support for that in Wrangler in the form of environments. The way this works is I'll just say env.production. This is just going to be the name of my environment.

[5:35] I've taken this route in zone ID and I've made it available under this different section called env.production. I'll also say workers.dev = false because it will try and inherit this inside of this environment. In this case, obviously, I don't want to deploy to workers.dev. Instead, I want to deploy to my actual route.

[5:57] The nice thing about environments is that I get the same behavior if I run wrangler publish. It will just run the same thing it's done up until now. It'll deploy to this workers.dev instance. If I say wrangler publish -e production, -e being environment, it'll look at env.production, and it'll look for specific information here.

[6:20] You can also do things like change the name of your worker. You can use a different account ID. You can pretty much pass a whole completely different set of information here. For now, we just want to say this isn't deploying to workers.dev. Instead, it's deploying to this route and it has this zone ID.

[6:39] We'll run that. You'll see that I passed in the wrong user configuration here because this is my other account with my actual domains. Let me fix that real quick. I've logged in with the correct information. Now if I run wrangler publish -e production, it will look at my wrangler.toml, find the production environment, and deploy it to the correct route.

[7:03] You can see now instead of it being set to myworker.kristianfreeman.workers.dev, it's looked in my particular environment, looked for production inside of wrangler.toml, and deployed it to this new route. If I open that, you can see I'm now running this on a custom domain, helloworldworker.signalnerve.com.

[7:25] It's not running on workers.dev. This is my real custom domain. I'll leave this up, and you can even go check it out if you want. You can see that it looks exactly the same as our workers.dev instance has. We've successfully deployed both to a staging environment, and also to our production, our final URL here at helloworldworker.signalnerve.com.