What part of your app runs on Workers?
Think of a sign-up page with an invitation form. Cloudflare can deliver the page, styles and images as prepared files. When someone submits the form, a Worker can run the code that checks the invitation and sends back an answer. Cloudflare calls those ready-to-serve files static assets.
The Workers runtime is the environment that runs that code. If the form handler needs a feature or package the runtime does not support, you will need to change that part or run it elsewhere. Start by checking the code that handles the form, rather than the page that shows it.
How do you get a first version onto Workers?
Identify the framework your app uses, then follow Cloudflare’s current guide for it. For example, the Next.js guide describes a main setup and other options for existing projects. A project that runs on your laptop may use a different runtime there.
Use a Cloudflare account and the app’s source code. Wrangler is Cloudflare’s command-line tool for configuring, testing and deploying a Worker. To deploy is to put a prepared version of the app online. If a piece of code needs a private credential, add it as a Cloudflare secret and keep it out of the page sent to the browser.
Before deploying the invitation form, check that the test version uses a test record store and can only send messages to a destination you control. At the supplied address, try a valid test invitation. Look for the expected record and check that an invalid invitation leaves the store unchanged.
Do you need to buy a domain first?
No. You can start with the workers.dev address Cloudflare assigns to your app. A domain is the name people type to find the app. You can connect a name you already own once the app works at the supplied address.
To use Workers Custom Domains, the domain’s DNS settings need to be active in your Cloudflare account. DNS directs a name to the right service. Cloudflare creates the routing record and the certificate that lets a browser connect securely. Before sharing the new address, make sure a test sign-in email returns you to it.
Where do the invitations and uploaded files go?
D1 can keep the invitation and sign-up records. R2 can hold files a user uploads. Both connect to your Worker, and you can also use a compatible outside service.
Decide how the app will check who can open each record or file. A successful upload tells you that a file was written. To check privacy, sign in as a second test user and try to open the first user’s file. Keep a recoverable copy of the data separately from the code you deploy.
Which Cloudflare preview link are you opening?
Cloudflare has two ways to try a version away from the live address. With Workers Previews configured, you can give changes their own settings and address. A Version URL opens one uploaded Worker version with that version’s existing settings and resources.
Copy the actual URL from your deployment result. Workers Preview links are public by default. Cloudflare Access can require people to sign in before they can open them.
Before anyone submits the invitation form, confirm which database, file store and email service this link reaches. Two Previews connected to the same D1 database can change the same records. Separate them when you need a safe place to write test data.
Which requests and computing time do you pay for?
On Workers, the main meters are requests to your code and the time the code spends actively computing, called CPU time. Opening one app page can trigger several requests.
For illustration, eight million metered requests averaging five milliseconds of CPU work would use 40 million CPU milliseconds in a month. On Standard that is within the included request count and 10 million CPU milliseconds over the allowance. The Worker bill in that example is US$5.20 before other services or charges.
Direct static-asset delivery has no Workers request charge. With Workers Caching enabled, a response from the Worker’s cache can still count as a request. The CPU meter runs when your code runs.
| Plan or service | Allowance and extra charges |
|---|---|
| Workers Free | 100,000 requests per day and up to 10 milliseconds of CPU time each time the Worker runs. Requests can fail after the account reaches its daily allowance, which resets at midnight UTC. |
| Workers Paid with Standard usage | At least $5 per account per month, including 10 million requests and 30 million CPU milliseconds. Extra usage costs $0.30 per million requests and $0.02 per million CPU milliseconds. |
| Records, files and other services | D1, R2 and other products have their own usage rules. Check their meters when you estimate the whole app’s bill. |
Will putting yesterday’s app back fix the problem?
If a release broke the form, first check whether the earlier version can still read the records the app has now. Cloudflare’s rollback puts an earlier code version back in service. It leaves changes made to the database and file store in place.
In the Worker’s Deployments list, choose Rollback for an eligible earlier version. Cloudflare limits this to the 100 most recently published versions. It can also refuse a rollback when the older version needs a resource that was deleted or changed. Keep a recoverable copy before changes to stored data and check the form again after switching versions.
What might make Workers a poor fit?
Check the limits for the hardest task you expect the app to do. Cloudflare documents a 128 MB memory limit for each running copy of a Worker, which can handle more than one request at a time. A job that reads and processes a large file can hit that limit even when ordinary pages work.
If you later move the app, list the Cloudflare-specific connections your code uses and export the records and files separately. Check that another service can read a copied record and its file before switching the public address.
Where can you learn the next steps?
- Check your app before going liveA release record for sign-in, saved data, failed actions, phone screens and recovery.