In this part of the tutorial, we'll be deploying your Worker to production, where users will be able to access it!

If you haven't gone through the front-end part of this tutorial yet, head back to that part first.

Before we continue, let's take another look at your wrangler.toml file to make sure everything's in order. Your file should look something like this:

type = "webpack"
name = "redirect"
account_id = "YOUR_ACCOUNT_ID"
workers_dev = true
route = ""
zone_id = ""

kv_namespaces = [ 
    { binding = "SHORTEN", id = "7654a938359f4f0e86b11afc7133166b", preview_id = "58f1a4c227534317817846d697f9ade7" }
]

[site]
bucket = "./public"
entry-point = "workers-site"

If it doesn't, please check in the back-end or front-end parts of this tutorial to ensure everything's set up properly. Once deployed, your Worker will be available for requests at <name>.<yoursubdomain>.workers.dev, where name is the project name you defined in the wrangler.toml name key, and yoursubdomain is your Workers subdomain, which you can see on your dashboard. Note that in production, your Worker will use the KV namespace available at id instead of preview_id automatically.

If everything looks good here, deploy your Worker with wrangler:

$ wrangler publish

And that's it! 🎉 Wrangler should return the URL your Worker's available at in the output, and you should be able to see it in your dashboard too. Go check it out and take it for a spin!

What we covered and what's next

Thanks for coming along this tutorial journey with me! We've covered:

• What Cloudflare Workers are and some of the advantages of using them
• How to use Workers KV to store key:value pairs of data, and access it in your code
• How to use Wrangler to scaffold your project, interact with KV, test and deploy
• Using Workers Sites to upload and serve static assets from your KV namespace
• Creating API endpoints for your Worker

If you're looking to extend this project further, here are a few ideas:

• Add basic reporting functionality: Make use of your KV namespace to store the number of clicks a link has received so far!
• Use a custom domain: Make use of routes to deploy the worker on a custom domain! (as it stands right now, the shortener actually lengthens domains 😛)
• Enable the ability to delete a link: Currently, links expire every 24 hours. Give users more control over when the link goes away.
• Improving error handling: Currently, error handling is pretty basic. Improve it by adding a static 404 page when a slug isn't found/expired, or experiment with piping failures to a 3rd party log ingestion service!

Let me know if you add in any of these features or build whole new things on top of this. Hope you enjoyed the tutorial; have fun building with Cloudflare Workers!