How to Build and Deploy Apps on Cloudflare Workers
Knowing how to build apps on Cloudflare Workers just became a more valuable skill. On October 10, Cloudflare announced it is acquiring Deno, with the stated goal of improving the programming model for Workers.
We broke down the deal in our morning post. Here is the hands-on side: a clear path from an empty folder to a deployed serverless app running on Cloudflare’s global network, using tools you can install in about ten minutes.
What You Need Before You Start
You need a free Cloudflare account, Node.js (a current LTS release), a terminal, and basic JavaScript or TypeScript knowledge. A code editor like VS Code is enough. If you already know Deno or Node, you will feel at home quickly. You do not need to understand servers, containers or load balancers, which is the whole point of serverless.
Step 1: Create a New Workers Project
Open your terminal and run npm create cloudflare@latest my-first-worker. The scaffolding tool asks which template you want. Pick the simple “Hello World” Worker and choose TypeScript if you want type safety from day one. It installs dependencies and creates a project with a src/index.ts file and a Wrangler configuration file.
Wrangler is Cloudflare’s command line tool. It runs your Worker locally, manages bindings and deploys your code. The official Workers documentation is the best reference when a flag or config key changes.
Step 2: Write and Test Your First Handler
A Worker is a function that receives a request and returns a response. Open src/index.ts and replace the default with a handler that reads the URL path and returns JSON for /api/health and a friendly message for everything else. Keep the first version tiny.
Now run npx wrangler dev. Wrangler starts a local server, usually on port 8787. Open it in your browser or use curl to hit /api/health. Edit the file, save, and watch the response change. This fast loop is where most developers fall in love with the platform.
Step 3: Add Storage and Configuration
Real apps need data. Workers connect to storage through bindings that you declare in the Wrangler config. For small key-value data such as feature flags or cached responses, create a KV namespace. For relational data, create a D1 database (Cloudflare’s serverless SQL option). For files and images, use R2 object storage.
Start with one binding only. For example, run npx wrangler d1 create app-db, paste the generated binding into your config, then write a simple query in your handler. Store secrets such as API keys with npx wrangler secret put API_KEY, never in your repository.
If your project uses Node packages, check the compatibility notes in the docs and enable the Node compatibility flag when needed. Since the Deno deal is aimed at improving the Workers programming model, expect the developer experience around runtimes and standards to keep evolving, so pin your Wrangler version in production projects and read release notes before upgrading.
Step 4: Deploy to the Edge
Log in once with npx wrangler login, then run npx wrangler deploy. In a few seconds your Worker is live on a workers.dev subdomain and served from Cloudflare’s network close to your users. Test the live URL, then attach your own domain from the Cloudflare dashboard if the domain is managed there.
Next, set up a basic CI pipeline. A GitHub Actions workflow that runs your tests and then wrangler deploy on merges to main is enough. Use a scoped API token with only the permissions the pipeline needs. This turns deployment into a non-event.
Step 5: Monitor, Log and Control Cost
Turn on Workers logs and check the analytics tab after launch. Watch request counts, error rates and CPU time. Review the current Workers pricing so you understand free-tier limits before a traffic spike surprises you. Add simple rate limiting for public endpoints.
Common Mistakes to Avoid
Treating a Worker like a long-running server. Workers are built for short, fast request handling. Heavy batch jobs or very long tasks need queues, scheduled triggers or a different service.
Hardcoding secrets and config. Keys in source code end up in Git history. Use secrets and environment bindings from the first commit.
Skipping local testing. Deploying every small change to production wastes time and risks outages. Use wrangler dev and automated tests, and keep a staging environment for anything customer facing.
Key Takeaways
- Start small: One handler and one binding is enough for a useful first deployment.
- Wrangler is your base tool: It handles local dev, secrets, bindings and deploys.
- Pick storage by need: KV for simple keys, D1 for SQL, R2 for files.
- Automate deployment: CI with scoped tokens removes manual risk.
- Watch the platform: The Deno acquisition signals changes ahead, so pin versions and read release notes.
Need Expert Help?
If this feels like a lot to manage alone, TecniForge can handle the heavy lifting. Our team specializes in custom software development and AI integration. Get in touch with our experts.
Also read: Cloudflare Deno Acquisition, our earlier coverage on why this matters today. You can also read the original report on TechCrunch.
Your challenge for today: run the scaffold command, deploy the Hello World Worker, and share the live URL with a teammate. Ten minutes from now you will have a global app.
Discover more from TecniForge
Subscribe to get the latest posts sent to your email.