Choosing Between Cloudflare Workers and Cloudflare Pages for Edge Compute

The Decision: Logic vs. Layout

When deploying serverless code to Cloudflare's edge, the choice usually boils down to whether you are building a standalone logic engine (Workers) or a content-driven application (Pages). While both run on the same V8 isolate runtime—meaning they share identical CPU and memory limits—their deployment pipelines and routing philosophies differ fundamentally.

The primary takeaway: Use Cloudflare Pages if your project has a frontend (React, Vue, Astro) and requires a Git-driven CI/CD pipeline. Use Cloudflare Workers if you are building a headless API, a middleware proxy, or a background task runner that doesn't require a static asset build step.

Feature Comparison Matrix

Feature	Cloudflare Workers	Cloudflare Pages
Primary Use Case	APIs, Middleware, WebSockets	Full-stack Apps, Static Sites, Blogs
Deployment	Wrangler CLI / API	Git Integration (Push-to-Deploy)
Routing	Explicit (wrangler.toml / Dashboard)	File-system based (/functions folder)
Static Assets	Manual (R2 or Workers Sites)	Automatic (Build output directory)
Scheduled Tasks	Supported (Cron Triggers)	Not Supported
Preview Env	Manual (via --env flag)	Automatic (Unique URL per commit)

Engineering Trade-offs

Development Velocity vs. Control

Cloudflare Pages abstracts the infrastructure. When you push to GitHub or GitLab, Pages triggers a build (e.g., npm run build) and deploys the resulting static files and Functions. This is ideal for teams using frameworks like Next.js or Remix. However, this abstraction adds a "shim" (a generated _worker.js file) that handles the routing between static assets and serverless functions, which can introduce a slight overhead in cold-start latency compared to a lean, hand-coded Worker.

Routing and State

Workers allow for complex middleware chains and multiple entry points. If you need to handle WebSockets or use Durable Objects (stateful entities at the edge), Workers is the only viable path. Pages Functions are designed for request-response cycles tied to a URL path. If your architecture requires a Cron trigger to prune a database every hour, you must use a Worker, as Pages cannot trigger code independently of an HTTP request.

Cost Structures

While both share the same duration pricing (GB-s), the request billing differs. Pages offers unlimited requests for static assets on the free tier, charging only for the execution of Functions. Workers charge per request regardless of whether the response is a static string or a complex computation. For high-traffic sites with many static pages, Pages is significantly more cost-effective.

Implementation: Validating the Choice

To determine which platform fits your performance and functional requirements, you can scaffold both using the Wrangler CLI (the official Cloudflare developer tool). Ensure you have Node.js installed and are authenticated via wrangler login.

Scenario A: Testing a Headless API (Workers)

Run the following command in your terminal to create a minimal Worker:

# Initialize a new worker project
wrangler init my-api-worker
# Select 'Fetch handler' and 'TypeScript' when prompted

# Deploy to the production environment
wrangler deploy

Verification: Check the wrangler.toml file. You will see an explicit route or workers_dev configuration. This project can now be extended with a [triggers] section for Cron jobs.

Scenario B: Testing a Full-stack App (Pages)

Run the following to scaffold a Pages project:

# Initialize a Pages project
wrangler pages init my-web-app
# Follow prompts to connect to your Git provider

# Run local development server to test file-system routing
wrangler pages dev . --port 8788

Verification: Create a folder named /functions in your root and add a file hello.ts. Navigate to localhost:8788/hello. If the page loads, the file-system router is active. Note that attempting to add a Cron trigger to this project's configuration will be ignored by the platform.

Limitations and Risks

• Runtime Constraints: Neither platform supports standard Node.js APIs like fs or child_process. You must use fetch and compatible WASM modules.
• Build Environment: Pages uses predefined build images. If your project requires specific native system binaries during the build phase, you may need to switch to a Worker and handle the build in a custom Docker CI pipeline.
• Log Retention: On free plans, logs are only available via "Tail" for 72 hours. For permanent audit trails, a paid plan is required to enable Logpush to R2 or S3.

Rollback Procedure

Because these deployments change the routing of your production domain, keep the following in mind:

• For Workers: Use wrangler rollback to revert to a previous deployment version if a new script causes 500 errors.
• For Pages: Go to the Cloudflare Dashboard > Workers & Pages > [Your Project] > Deployments. Select a previous successful commit and click "Rollback to this deployment."