Cloudflare Workers Changed How I Think About Protecting Digital Products
I thought Cloudflare was a security company. The orange cloud that sits in front of websites and blocks bots. The CAPTCHA you click through before you're allowed to read a recipe. That was the extent of it for me until about a week ago, when I needed to solve a specific problem and discovered that Cloudflare is also a free application platform.
The problem: I'd built a paid web app (Skin Resonance, a sound frequency tool for skincare support) and it lived on a single URL. One link, shared with every buyer. Anyone who had it could use the product, share it, post it publicly. My entire revenue model was protected by a polite note at the bottom of a PDF asking people not to share.
What I didn't know Cloudflare could do
Cloudflare Workers are small pieces of code that run on Cloudflare's global network. They sit between a visitor and your website and can intercept, modify, or redirect any request before it reaches your actual content. The free tier gives you 100,000 requests per day, which is far beyond what a small product needs.
Cloudflare Workers: application logic at the network edge, free at small scale.
Cloudflare KV is a key-value database built into the same platform. You store data (in my case, access tokens), and your Worker reads from it on every request. Also free at small scale: 100,000 reads and 1,000 writes per day.
What this means in practice: you can build access control, redirect logic, A/B testing, API endpoints, URL shorteners, and all sorts of application-level behaviour without running a server, without paying for hosting, and without writing a traditional backend. The code deploys globally in seconds and runs at the network edge, closer to your users than a centralised server would be.
I had no idea any of this existed. I'd been using Cloudflare Pages to host static sites for months and never looked at what else was in the dashboard.
The problem with a shared URL
When you sell a digital product as a web app, you need some way to make sure only paying customers can access it. The common approaches all have trade-offs.
User accounts (email, password, login) are the standard solution, but for a solo operator selling a €15 product, the development time and ongoing maintenance are disproportionate. You're building an authentication system to protect something that costs less than lunch.
Squarespace Members Area offers individual logins, but it interferes with PWA installation. When a buyer adds the app to their phone's home screen, the login session doesn't reliably carry across. The app also can't cache properly for offline use if every request needs to pass through authentication. Since "install on your phone" is a listed feature of Skin Resonance, that ruled it out.
A shared password (one password emailed to all buyers) has the same vulnerability as a shared URL. One person leaks it and everyone's in. You can't tell who shared it, and changing it means contacting every existing customer.
What I built with Cloudflare Workers
A token-gated access system. Each buyer gets a unique URL. A Cloudflare Worker checks every request against a database of valid tokens. Valid token: the app loads. Invalid or missing token: the visitor is redirected to the purchase page.
The buyer's URL looks something like app.example.com/a/sr-8f3a2b9c. The sr-8f3a2b9c part is a unique token generated at the moment of purchase, stored in Cloudflare KV, and emailed to the buyer automatically.
The app code didn't change. The Worker sits in front of it and handles all the access logic independently.
The full system has four components. The Worker intercepts requests and checks tokens. Cloudflare KV stores the tokens alongside the buyer's email, creation date, access count, and last access time. A Zapier automation connects Squarespace orders to the Worker: purchase triggers token creation, which triggers a branded welcome email with the buyer's unique link. And an admin API (protected by a secret key) lets me create, list, inspect, and revoke tokens without touching any code.
I've written before about choosing between Zapier and Make for automation. For this setup, Zapier's webhook action and Squarespace Commerce trigger made it the simpler choice. The purchase-to-delivery sequence is fully automated. Someone buys on Squarespace. Within a couple of minutes, they receive an email from the product's own domain with their personal access link and instructions for installing the app on their phone.
Keeping an eye on access
Each token records how many times it's been used and when it was last accessed. Listing all tokens through the admin API shows every buyer's usage at a glance.
Normal usage for my product might be a handful of accesses per week. If a token shows hundreds of accesses, or a sudden spike that doesn't match one person's behaviour, that link has probably been shared.
The response is quick. Revoke the token (one API call, takes effect immediately). The shared link stops working and redirects to the purchase page. Generate a fresh token. Email the buyer their new link with a note that the previous one was deactivated because it appeared to have been shared. The buyer keeps their access. The person they shared it with is directed to buy their own.
I've also set up an automated weekly report through Zapier that emails me a summary of all tokens and their access counts. I scan it in 30 seconds over coffee and move on. No need to remember to log into Cloudflare and check manually.
This isn't a system that prevents all sharing. Someone could screen-record the app or share their token privately with one person and I'd likely never know. But for a €15 product sold to individuals, the goal is to stop casual sharing, make abuse visible, and have a way to act on it.
The cost
Zero. Cloudflare Workers free tier, Cloudflare KV free tier, one Zapier task per sale (fits within existing plans). The access protection for a paid digital product costs nothing to run.
What this opened up for me
The bigger takeaway isn't the specific solution. It's that Cloudflare's platform is far more capable than I'd assumed. Workers can run application logic. KV can store data. You can build API endpoints, redirect systems, access gates, and lightweight backends without provisioning a server or paying for infrastructure.
If you're a small business owner or solo operator hosting anything on Cloudflare (even just a static site on Cloudflare Pages), it's worth spending an afternoon looking at what Workers can do. The Workers documentation is clear, the free tier is generous, and the problems you can solve with a few hundred lines of code and a KV namespace go well beyond what I'd expected from a company I associated with CAPTCHA puzzles.
Claude wrote the Worker code and guided me through the setup (KV namespace, environment variables, domain routing, Zapier integration). I've written about how AI handles the implementation while I direct the decisions before, and this project followed the same pattern. I made every architectural decision, manage the tokens, and run the monitoring. The implementation took a few hours in a single session. The running cost is nothing, and I own every piece of it.
A note on jurisdiction
Cloudflare is a US company, which means the data stored in KV (tokens, access logs) sits under US jurisdiction and the CLOUD Act. For this specific product, sold at a low price point with minimal personal data, the trade-off felt acceptable given how much the free tier lets a solo operator build. But it is a trade-off. My next project is to evaluate Scaleway Serverlless Functions as a French-jurisdiction alternative with a similar architecture. If you are building something with heavier GDPR considerations or want EU-hosted infrastructure from the start, Scaleway is the closest direct equivalent. OVHcloud Functions is another French option worth looking at. I will write up the migration when I have tested it properly.
If you sell a digital product and you're wondering how to protect it without building a full authentication system, get in touch. This is the kind of problem I help clients solve.
