Is Cloudflare Worker Previews Free

Is Cloudflare Worker Previews free? Yes: Workers Free includes 100 Previews per Worker and 100 deployments per Preview. That entitlement does not make branch testing unmetered; dynamic execution, build minutes, storage, AI inference, and Containers keep separate limits or prices.

Cloudflare Worker Previews gives each Git branch a production-like environment under the same Worker. The useful answer is not simply "$0." It is: the Preview object is available on Free, then the branch consumes or touches the same platform products you already need to budget.

Is Cloudflare Worker Previews Free?

Yes, the entitlement is free. Cloudflare's current Preview limits list 100 Previews per Worker on the Free plan, 500 on paid plans, and 100 deployments inside each Preview on either plan.

That answer has a boundary. A Preview is an environment object, not a bundle of free runtime, storage, builds, or model calls. Cloudflare's live Workers pricing page still gives Free accounts 100,000 dynamic Worker requests per day and a 10 millisecond CPU limit per invocation. Workers Paid still starts at $5 per account per month, includes 10 million requests and 30 million CPU milliseconds per month, then charges published overage rates.

The live Preview and pricing docs were verified on September 28, 2026. Neither page publishes a Preview-specific fee, but neither says Preview execution is unlimited or receives a separate usage pool. The safe budget is therefore free Preview entitlement, existing product meters.

What Actually Changed on September 22, 2026

Cloudflare launched Worker Previews on September 22, 2026 to give every branch its own running environment, stable Preview URL, configuration, observability, and state. Running npx wrangler preview creates or updates the Preview associated with the current branch.

The business consequence is a shorter evidence loop. A coding agent can deploy a branch, send requests to it, inspect logs and traces, revise the code, and update the same shareable Preview URL before anyone merges to production. Several agents or engineers can work in parallel without taking turns on one shared staging Worker.

Each branch receives two useful URL types. The Preview URL always follows the latest deployment for that branch. A Deployment URL stays pinned to one exact deployment, which makes a review comment or regression comparison reproducible.

The isolation is meaningful. Cloudflare automatically gives each Preview its own Durable Object namespace and storage. It can also provision a separate container app and instances. Variables, secrets, and bindings can differ from production, while logs and traces remain scoped to the branch.

This is a stronger workflow than the old Version URL model, but it is not a complete clone of production. Several bindings and triggers still touch shared or production systems. That limitation should decide how much authority you give an agent, not the convenience of the Preview URL.

Worker Previews Free Plan: What You Get

The Free plan is large enough for a normal branch workflow. One Worker can hold 100 Preview environments, and every Preview can retain 100 deployments. Paid raises the environment count to 500 but does not raise the deployment history per Preview.

These are different dimensions. If one branch is deployed repeatedly, it still occupies one Preview slot while its deployment history grows. Several branches with one active Preview each occupy several Preview slots even when none receives traffic.

The old-versus-new object math is useful. Matching five branches with Wrangler environments meant managing five separate Workers. Worker Previews puts the same branch count under one Worker as five Preview objects. On Free, that changes account occupancy from 5% of the 100-Worker limit to 1% of the Worker limit plus 5% of that Worker's Preview entitlement. The documented base price can remain $0 in either layout when usage fits; the gain is simpler isolation and less environment sprawl, not discounted execution.

Worker Previews requires Wrangler 4.135.0 or later. The project-local version is the one that matters because project commands do not silently substitute a newer global installation. That is an easy source of a false "feature unavailable" diagnosis in an older repository.

The configuration boundary matters too. Previews do not inherit production settings. The branch gets what is declared in the previews block, plus resources Cloudflare isolates automatically. An empty or incomplete block can produce a Preview that deploys successfully but cannot reach the resource the code expects.

Cloudflare Preview Limits: What Deletes First

Cloudflare cleans up automatically when either object limit is full. At the Worker level, it deletes the Preview that was deployed least recently. Inside one Preview, it deletes the oldest deployment.

That makes the 101st deployment to the same Preview a retention event: the oldest deployment drops out so the new one fits. It does not mean the first 100 builds were free. Workers Builds measures build minutes separately, whether those builds created production deployments or Preview deployments.

For an agent that revises a branch often, the stable Preview URL remains useful because it always points to the latest deployment. The risk sits in forensic history. If a team needs to reproduce an older failure, it should keep the relevant deployment URL and logs before that deployment becomes the oldest item.

Automatic object deletion is also not a complete resource cleanup policy. Deleting a Preview removes its Preview record and Durable Object namespace, but Cloudflare warns that a generated container app can remain visible. A branch-close job should delete the Preview, then inspect Container applications when Containers were involved.

Cloudflare Worker Previews Pricing Has Four Layers

Cloudflare Worker Previews pricing has no published per-Preview line item. The bill still has four practical layers: Worker execution, builds, bound resources, and optional compute or model products.

1. Worker execution

Workers Free permits 100,000 requests per account per day and caps each invocation at 10 milliseconds of CPU. Static-asset requests are free and unlimited; the request allowance applies to requests that hit Worker code. A branch test that only loads static files can therefore look cheap while an API-heavy test consumes the dynamic allowance.

Workers Paid starts at $5 per account per month. It includes 10 million requests and 30 million CPU milliseconds each month, then costs $0.30 per additional million requests and $0.02 per additional million CPU milliseconds. Paid uses a 30-second default CPU limit for an HTTP invocation and can be configured up to 5 minutes.

The 10 millisecond Free limit is often the first wall. Request volume cannot compensate for it. A test suite sending only a few requests still fails if one dynamic invocation consistently needs more than 10 milliseconds of CPU.

For the wider platform decision, the Cloudflare review separates the $5 Workers account plan from Cloudflare's per-domain application plans and other product meters.

2. Workers Builds

Workers Builds limits and pricing gives Free accounts 3,000 build minutes per month, one concurrent build, and a 20-minute timeout. Paid includes 6,000 minutes, then charges $0.005 per additional minute, with six concurrent builds and the same timeout. Agent-generated branches can hit concurrency or minutes even when their Preview object count stays low.

This is why "100 deployments per Preview" must not be read as "100 included builds." One is retained deployment history. The other is CI compute.

3. Storage and bound resources

KV, D1, R2, Queues, Vectorize, Hyperdrive, and other bindings use their own resource identifiers and meters. Two Previews bound to the same D1 database or R2 bucket share that data. Isolation requires a separate resource, and the separate resource still follows that product's pricing.

For scale, R2 includes 10 GB-month, 1 million Class A operations, and 10 million Class B operations per month. Standard storage beyond that is $0.015 per GB-month, with Class A at $4.50 per million and Class B at $0.36 per million. D1 Free includes 5 million rows read and 100,000 rows written per day plus 5 GB total storage. The D1 Free-limit analysis explains why a shared staging database can become an availability boundary even while Preview objects remain available.

KV has another distinct daily envelope: 100,000 reads, 1,000 writes, 1,000 deletes, and 1,000 list requests on Free, with 1 GB stored. A test that seeds or clears a namespace can spend that allowance much faster than a read-only smoke test.

4. AI inference and Containers

Workers AI pricing gives both Free and Paid accounts 10,000 Neurons per day at no charge. On Paid, usage above that allocation costs $0.011 per 1,000 Neurons. A branch test that calls a model is therefore budgeting two activities: the Worker request and the inference it triggers. An external coding-agent subscription or model API is another vendor's bill and is not included by the Preview entitlement.

Container pricing lists no Container allocation on Free. Workers Paid includes 25 GiB-hours of memory, 375 vCPU-minutes, and 200 GB-hours of disk per month, with separate overage rates. Container traffic also uses Workers and Durable Objects, so an automatically isolated Preview container is not a single-meter product.

Worker Preview Costs for Five Active Branches

The clean worksheet starts with the workload, not the plan label. Assume five active branches, each receiving 200 dynamic test requests per day. That is 1,000 requests per day across five Preview objects.

On Free, the Preview count is comfortable and the modeled traffic is small. The account has 99,000 dynamic requests per day left only if nothing else uses the allowance. Production traffic, other Workers, and the five branch environments all belong in the operating worksheet.

There is an important evidence label here. Cloudflare calls 100,000 requests per day an account-plan limit, and a Preview runs a real version of the Worker. The Preview docs do not explicitly say that Preview traffic debits the same meter. Applying the account meter to Preview requests is therefore a conservative budgeting assumption until an account usage observation or explicit Cloudflare statement confirms it.

No Cloudflare account credentials, Worker project, or project-local Wrangler installation were available for this verification run. No disposable Previews were deployed and no usage delta was collected. The entitlement answer is source-verified; this worksheet is a model.

On Paid, this branch workload produces no request overage by itself, but the account still pays the $5 monthly minimum. CPU and attached products can change that conclusion. At the same testing density, all 100 Free Preview slots would generate 20,000 requests per day, 20% of the modeled daily allowance. All 500 paid slots would generate 3 million requests in a 30-day month, 30% of the included monthly requests. In both clean-room examples, the Preview object cap arrives before the request allowance. Production traffic can reverse that order.

What It Means for Builders, Operators, and Buyers

Builders get parallel runtime proof, not automatic resource safety

A builder can give every active branch a stable URL and isolated Durable Object state. That removes the shared-staging collision where one engineer's deploy invalidates another engineer's review. It also gives a coding agent a concrete target for curl, browser checks, logs, and traces.

The wall is configuration. D1, KV, and R2 do not become isolated merely because the code does. If two Previews use the same identifier, they share the resource. The safe default is a dedicated non-production resource or an intentionally shared staging resource with disposable data.

Operators own the shared budget and cleanup path

An operator should track four numbers separately: active Preview objects, deployments retained per Preview, dynamic Worker usage, and attached-product usage. One dashboard total cannot explain all four.

The cleanup path belongs in pull-request automation. Delete a Preview when its branch closes. If Containers were used, inspect for the generated container application. Keep any deployment URL or trace needed for an incident before retention rolls it away.

Buyers should upgrade for a named boundary

Do not buy Paid because the word "Preview" sounds premium. Buy it when a named requirement crosses Free: more than 100 simultaneous Previews on one Worker, dynamic traffic plus production approaching 100,000 requests per day, an invocation needing more than 10 milliseconds CPU, or any Container requirement.

Paid can also be the rational risk choice before raw volume demands it. A customer-facing team may prefer a monthly allowance and overage bill to a daily Free limit, even when five branch tests consume only 1% of that modeled daily envelope.

What to Do Differently

Act now if several engineers or agents are taking turns on one mutable staging Worker. Move branch validation to Previews, define a non-production resource policy, and make branch-close cleanup part of CI. The release directly removes a coordination bottleneck.

Wait if the application depends on multi-Worker service bindings, Queue consumers, Cron Triggers, production routes, or automatically isolated Workflows. Those paths do not stay wholly inside a Preview today. A Preview can still test the HTTP-facing slice, but it cannot prove the complete system is isolated.

You are mostly unaffected if the project already uses a stable per-branch environment elsewhere, or if the Worker is static and changes are fully covered by local and deployment-version checks. The new object does not create value merely by existing.

The decision rule is direct: stay on Free while the object count, per-invocation CPU, modeled account traffic, and product needs all fit. Move to Paid when any one of those boundaries is operationally important. The request count is not the only crossover.

What's Overhyped

The launch framing is strongest when it describes an isolated branch Worker. It is too broad if read as an isolated copy of an entire Cloudflare application.

• A service binding from a Preview calls the other Worker's production deployment. Multi-Worker request paths are not automatically matched branch to branch.
• A Workflow binding uses an existing deployed Workflow. Cloudflare does not create a Preview-specific Workflow for the branch.
• A Preview can send messages to a Queue, but it cannot be the Queue consumer. Pointing it at a production Queue can cause production to consume its test messages.
• Cron Triggers and production routes still target production.
• KV, D1, R2, and several other resources are isolated only when you bind a different resource identifier.
• Preview URLs are public by default. The workers.dev form carries X-Robots-Tag: noindex, but a custom-domain Preview should be protected with Cloudflare Access when unreleased work must stay private.
• Container support is partial, and deletion can leave the generated app visible until it is cleaned up separately.

Those are not edge cases for an agent. They are the difference between "the agent can test its branch" and "the agent cannot touch production." The current resource-isolation matrix should be treated as an authorization document, not optional setup reading.

The other overstatement is financial: 100 Previews on Free does not mean 100 fully free staging stacks. It means Cloudflare will let one Worker hold that many Preview objects. The resources behind them determine the budget.

Check the Entitlement, Then Use the Setup Guide

The entitlement check needs only four questions:

1. Is the account on Workers Free or Paid?
2. How many active Previews does this Worker already have?
3. What do production and other Workers already consume from the account's request and CPU budget?
4. Does the project pin Wrangler 4.135.0 or later?

If those answers fit, use Cloudflare's official Worker Previews setup guide for configuration and deployment. Keep the cost review separate: list every bound resource, build path, model call, and Container before an agent starts generating branches.

Cloudflare Worker Previews FAQ

Can I use Cloudflare workers for free?

Yes. Workers Free costs $0, includes 100,000 dynamic Worker requests per day, and supports up to 100 Previews per Worker. Each invocation still has a 10 millisecond CPU limit, and attached products keep separate allowances.

How much does a Cloudflare worker cost?

Workers Free costs $0. Workers Paid starts at $5 per account per month, includes 10 million requests and 30 million CPU milliseconds, then bills published overage rates. A Preview does not have a separate published base fee.

How many Cloudflare workers can I have for free?

Workers Free permits 100 Workers per account. That is separate from the Worker Previews limit, which permits 100 Previews under each Worker on Free.

How much does Cloudflare Workers AI cost?

Workers AI includes 10,000 Neurons per day at no charge. On Workers Paid, usage above that daily allocation costs $0.011 per 1,000 Neurons.

Are Cloudflare workers AI free?

Workers AI has a free daily allocation of 10,000 Neurons on both Workers Free and Workers Paid. Free accounts stop at the allocation; Paid accounts can continue at $0.011 per 1,000 Neurons above it.

Who is Cloudflare's biggest competitor?

There is no single competitor across Cloudflare's network, security, compute, storage, and developer products. Compare the specific layer you intend to replace rather than treating the whole company as one product.

Why is Cloudflare falling?

The question is ambiguous and time-sensitive: it may refer to a stock price, service status, traffic, or another metric. None of those interpretations changes the Worker Previews limits verified from Cloudflare's live documentation on September 28, 2026.

Is Cloudflare a Russian company?

No. Cloudflare's company overview identifies San Francisco as its headquarters and says Cloudflare, Inc. is publicly listed on the New York Stock Exchange as NET.

Why does the FBI use Cloudflare?

This article does not establish that the FBI uses Cloudflare and makes no claim about an agency's vendor stack. The question is unrelated to the documented Worker Previews entitlement and usage limits.

The Monday Move

Start with five branches, cap each at 200 dynamic test requests per day, and label the resulting 1,000 daily requests as a shared-meter assumption in the budget. Record the account's request usage before and after the pilot when you have billing access. If the delta confirms the model, keep the worksheet; if it does not, replace the assumption with the observation.

At the same time, inventory every binding in the previews block. Mark it automatic isolation, dedicated test resource, intentionally shared, or production-touching. Do not let an agent deploy until every production-touching row has an explicit reason.

Want the next infrastructure release translated into a budget and operating decision? Join the newsletter.