Deploying Modern JavaScript Frameworks to Cloudflare Workers in 2026: A Complete Developer Guide

Why This Matters Right Now — April 2026

The edge computing revolution is no longer a buzzword. As of 2026, Cloudflare’s global network spans over 310 cities across more than 120 countries, and the developer ecosystem has matured dramatically. What was once a niche deployment target for Hono and Workers-specific apps is now a first-class destination for virtually every major JavaScript framework in the ecosystem.

If you have been holding back from deploying your Next.js, SvelteKit, Nuxt, or Astro project to Cloudflare Workers because of compatibility concerns or unclear documentation, 2026 is the year that excuse disappears. Cloudflare now officially supports an impressive list of frameworks natively, and the developer experience has been refined through years of community feedback and tooling improvements.

This guide walks through everything you need to know — from understanding why Cloudflare Workers matters in 2026 to deploying each supported framework confidently, in the right order of operations.

The Supported Framework Landscape in 2026

Before diving into setup, here is the complete list of frameworks that Cloudflare officially supports for deployment via Workers and Pages as of 2026:

Full-stack & Meta-frameworks: Next.js, Nuxt, SvelteKit, Analog, SolidStart, Qwik, TanStack Start, React Router (formerly Remix), RedwoodSDK, Waku, Vike

Static & Content-focused: Astro, Gatsby, Docusaurus

API & Edge-first: Hono

UI Libraries (with SSR/SSG adapters): React, Vue, Angular

Each of these has a dedicated adapter or a first-class build integration. The way you approach deployment differs slightly per framework, and this guide covers the logical sequence to get any of them running on Cloudflare Workers.

Part 1: Understanding the Architecture Before You Deploy

Why Cloudflare Workers and Not Traditional Servers

In 2026, the conversation around serverless has shifted from “should I use it?” to “which edge platform fits my workload?” Cloudflare Workers runs your JavaScript at the network edge, meaning your code executes in a data center geographically close to every single user. There is no cold start penalty the way traditional Lambda-style functions suffer from, because Workers run in V8 isolates rather than containers.

The practical implications for your framework-based application are significant: faster Time to First Byte (TTFB), lower operational overhead, no server management, and a pricing model that scales from zero.

However, the trade-off is the Workers runtime is not Node.js. It is a standards-based JavaScript environment that supports the Web Platform APIs — fetch, Request, Response, Streams, crypto, and more — but does not support every Node.js built-in module. This is why the adapter layer for each framework is critical.

The Role of Adapters

Each framework in the supported list either ships with a Cloudflare adapter or has community-maintained one that transforms your build output into something the Workers runtime can execute. Understanding this model prevents hours of confusion during deployment.

For example:

• SvelteKit uses @sveltejs/adapter-cloudflare
• Next.js on Cloudflare uses the OpenNext-based adapter, now maintained as @opennextjs/cloudflare
• Nuxt uses nitro with the cloudflare-pages or cloudflare-module preset
• Astro uses @astrojs/cloudflare
• Analog uses @analogjs/platform with the Cloudflare preset

Always verify the adapter version compatibility with your framework version before beginning. Mismatched adapter versions are the single most common source of failed deployments.

Part 2: Prerequisites and Environment Setup

Step 1: Set Up Your Cloudflare Account and Wrangler CLI

Everything starts here. You need a Cloudflare account and the Wrangler CLI — Cloudflare’s official command-line tool for managing Workers, Pages, KV, D1, R2, and more.

As of 2026, Wrangler v4 is the current stable release. Install it globally or use it as a dev dependency:

npm install -g wrangler

Authenticate Wrangler with your Cloudflare account:

wrangler login

This opens a browser window for OAuth authentication. Once complete, Wrangler has access to your account, zones, and Workers.

Verify the setup:

wrangler whoami

You should see your account name and account ID. Keep your account ID handy — you will reference it in wrangler.toml.

Step 2: Understand wrangler.toml

Every Cloudflare Workers project is configured via a wrangler.toml file at the root of your project. This is the single source of truth for your deployment configuration. A minimal example:

name = "my-app"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat"]

[vars]
ENVIRONMENT = "production"

The compatibility_date field is critically important. It tells the Workers runtime which version of the platform APIs to expose. Always use a date that matches your tested environment. The nodejs_compat flag is required by most modern frameworks to polyfill Node.js APIs that the framework's internals depend on.

Step 3: Node.js and Package Manager Requirements

Ensure your local development environment is running Node.js 20 or later. Cloudflare’s tooling as of 2026 has dropped support for anything below Node.js 18, and many framework adapters require Node.js 20 features.

Use a version manager for consistency:

nvm install 20
nvm use 20

Your package manager choice — npm, pnpm, or yarn — does not significantly impact the deployment workflow, but pnpm is increasingly the standard in the Cloudflare ecosystem due to its strict dependency resolution and disk efficiency.

Part 3: Framework-Specific Deployment — In Order of Complexity

Tier 1: Simplest Deployments (Static / Content Sites)

React (Vite-based SPA)

A standard React app built with Vite deploys as a static asset bundle to Cloudflare Pages. There is no adapter needed for a pure SPA:

npm create vite@latest my-react-app -- --template react-ts
cd my-react-app
npm install
npm run build

Deploy the dist folder to Cloudflare Pages via the dashboard or CLI:

wrangler pages deploy dist

Vue

Identical to React above when using Vite. Build produces a static output:

npm create vue@latest my-vue-app
cd my-vue-app
npm install
npm run build
wrangler pages deploy dist

Docusaurus

Docusaurus generates a fully static site by default. After building:

npx create-docusaurus@latest my-docs classic
cd my-docs
npm run build
wrangler pages deploy build

The output folder for Docusaurus is build, not dist. Note this distinction when configuring your Pages project.

Gatsby

Gatsby’s static output also deploys cleanly. Install the Cloudflare adapter:

npm install gatsby-adapter-cloudflare

Configure in gatsby-config.js:

const adapter = require("gatsby-adapter-cloudflare");

module.exports = {
  adapter: adapter(),
};

Then build and deploy:

gatsby build
wrangler pages deploy public

Astro

Astro is uniquely flexible — it supports static, SSR, and hybrid rendering. For full SSR on Cloudflare:

npx astro add cloudflare

This automatically installs @astrojs/cloudflare and updates your astro.config.mjs:

import { defineConfig } from "astro/config";
import cloudflare from "@astrojs/cloudflare";

export default defineConfig({
  output: "server",
  adapter: cloudflare(),
});

Build and deploy:

npm run build
wrangler pages deploy dist

Tier 2: Full-Stack SSR Frameworks

Hono

Hono is a lightweight, blazing-fast web framework built specifically for edge runtimes. It is arguably the most native Cloudflare Workers framework in this entire list:

npm create hono@latest my-hono-app
cd my-hono-app

Select cloudflare-workers as the template. Your entry point:

import { Hono } from "hono";

const app = new Hono();
app.get("/", (c) => c.text("Hello from the edge, 2026!"));
export default app;

Deploy:

wrangler deploy

Hono requires no adapter. It is the reference implementation for the Workers runtime model.

SvelteKit

SvelteKit on Cloudflare requires the official adapter:

npm install -D @sveltejs/adapter-cloudflare

Update svelte.config.js:

import adapter from "@sveltejs/adapter-cloudflare";

export default {
  kit: {
    adapter: adapter({
      routes: {
        include: ["/*"],
        exclude: ["<all>"],
      },
    }),
  },
};

Build and deploy:

npm run build
wrangler pages deploy .svelte-kit/cloudflare

Nuxt

Nuxt uses Nitro as its server engine, which has a built-in Cloudflare preset. In nuxt.config.ts:

export default defineNuxtConfig({
  nitro: {
    preset: "cloudflare-pages",
  },
});

Build and deploy:

npm run build
wrangler pages deploy .output/public

For Workers (non-Pages) deployment, switch the preset to cloudflare-module.

Angular (with SSR)

Angular SSR on Cloudflare uses the @angular/ssr package with a Cloudflare-compatible server entry. As of Angular 19+, the Cloudflare adapter is available via:

ng add @angular/ssr --server-routing

Configure your wrangler.toml to point to the SSR bundle output, and ensure nodejs_compat is enabled.

Qwik

Qwik’s city framework includes a Cloudflare adapter out of the box:

npm run qwik add cloudflare-pages

This installs the adapter and sets up vite.config.ts accordingly. Build:

npm run build
wrangler pages deploy dist

Tier 3: Advanced Full-Stack Deployments

Next.js (via OpenNext)

Next.js on Cloudflare is the most discussed and historically most challenging deployment target. In 2026, the @opennextjs/cloudflare adapter has matured significantly and supports the App Router, Server Actions, and Partial Prerendering.

Install:

npm install @opennextjs/cloudflare

Add a build script in package.json:

{
  "scripts": {
    "build:worker": "opennextjs-cloudflare"
  }
}

Configure wrangler.toml for your output:

name = "my-nextjs-app"
compatibility_date = "2025-01-01"
compatibility_flags = ["nodejs_compat"]
pages_build_output_dir = ".open-next/assets"

[build]
command = "npm run build:worker"

Deploy:

npm run build:worker
wrangler pages deploy

Note: Not all Next.js features are supported on the Workers runtime. Image Optimization with next/image requires additional configuration or delegation to Cloudflare Images. Review the OpenNext Cloudflare compatibility matrix before migrating a large production application.

React Router (formerly Remix)

React Router v7 (the evolution of Remix) has first-class Cloudflare support. Create a new project with the Cloudflare template:

npx create-react-router@latest --template cloudflare my-app

This scaffolds a project pre-configured with the Cloudflare adapter. Your wrangler.toml, entry worker file, and react-router.config.ts are all set up correctly from the start.

Build and deploy:

npm run build
wrangler deploy

TanStack Start

TanStack Start, the full-stack variant of TanStack Router, reached stable in late 2024 and supports Cloudflare via Nitro:

In app.config.ts:

import { defineConfig } from "@tanstack/start/config";

export default defineConfig({
  server: {
    preset: "cloudflare-pages",
  },
});

Build and deploy:

npm run build
wrangler pages deploy dist

SolidStart

SolidStart, the meta-framework for Solid.js, uses Nitro and supports Cloudflare Pages natively:

npm create solid@latest my-solid-app

Select the Cloudflare preset during scaffolding, or configure manually in app.config.ts:

import { defineConfig } from "@solidjs/start/config";

export default defineConfig({
  server: {
    preset: "cloudflare-pages",
  },
});

Analog (Angular Meta-Framework)

Analog is a full-stack meta-framework for Angular, analogous to what Nuxt is for Vue or SvelteKit is for Svelte. It uses Nitro under the hood:

// vite.config.ts
import analog from "@analogjs/platform";

export default defineConfig({
  plugins: [
    analog({
      nitro: {
        preset: "cloudflare-pages",
      },
    }),
  ],
});

Vike (formerly vite-plugin-ssr)

Vike gives you granular control over your SSR setup. The Cloudflare integration is done via a custom server entry:

// server/index.ts
import { renderPage } from "vike/server";

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const pageContextInit = { urlOriginal: request.url };
    const pageContext = await renderPage(pageContextInit);
    if (pageContext.httpResponse === null) return new Response("Not found", { status: 404 });
    return new Response(pageContext.httpResponse.body, {
      headers: { "Content-Type": pageContext.httpResponse.contentType },
    });
  },
};

Waku

Waku is a minimal React framework designed for RSC (React Server Components). It has a Cloudflare deployment path:

npm create waku@latest my-waku-app
cd my-waku-app
npm run build -- --with-vercel  # or cloudflare output
wrangler pages deploy dist

Check the official Waku documentation for the exact build flag, as the Cloudflare deployment output has been evolving.

RedwoodSDK

RedwoodSDK (the evolution of RedwoodJS for the Workers era) is purpose-built for Cloudflare Workers with D1, KV, and R2 integration. Scaffold a new project:

npm create rwsdk@latest my-rw-app

The generated project includes a pre-configured wrangler.toml with D1 database bindings, R2 bucket bindings, and a Worker entry point.

Part 4: Production-Grade Concerns

Environment Variables and Secrets

In a production deployment, never hardcode credentials or API keys in your source files or even your wrangler.toml. Cloudflare Workers has a native secrets management system.

Set a secret via CLI:

wrangler secret put DATABASE_URL

This prompts you to enter the secret value, which is encrypted and stored in Cloudflare’s infrastructure. It is available in your Worker as env.DATABASE_URL.

For non-sensitive configuration, use [vars] in wrangler.toml:

[vars]
APP_ENV = "production"
API_BASE_URL = "https://api.example.com"

Why Secrets Management Matters in Production

In a Workers environment, your code runs across hundreds of edge nodes. If secrets were committed to your repository or stored in plaintext config files, a single leak would compromise all of them simultaneously. Cloudflare’s encrypted secrets store ensures that your credentials are only decrypted at runtime within the isolated execution context of your Worker, never exposed in logs or build artifacts.

Bindings: KV, D1, R2, and Queues

One of the most powerful aspects of the Cloudflare ecosystem is the tight integration between Workers and Cloudflare’s storage and data primitives. Configure them in wrangler.toml:

[[kv_namespaces]]
binding = "SESSION_STORE"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
[[r2_buckets]]
binding = "ASSETS"
bucket_name = "my-app-assets"

These bindings are injected into your Worker’s env object at runtime. This is the correct, secure pattern — no connection strings, no TCP connections, no firewall rules. Just native API calls within the same network.

Custom Domains

Point a custom domain to your Worker or Pages project:

wrangler pages domain add yourdomain.example.com

Or configure it in the Cloudflare dashboard under Workers and Pages, then your domain’s DNS settings. Use orange-clouded DNS records (proxied) to ensure traffic routes through Cloudflare’s network and your Worker.

Part 5: Local Development Workflow

Cloudflare provides wrangler dev as a local development server that accurately emulates the Workers runtime, including bindings:

wrangler dev

For Pages projects:

wrangler pages dev

As of Wrangler v4, local development uses Miniflare v4 under the hood, which provides near-perfect fidelity to the production runtime. You can even connect to remote D1 databases and KV namespaces during development using the --remote flag, which is useful for testing migrations without affecting production data.

Conclusion

Cloudflare Workers in 2026 represents one of the most compelling deployment targets in the JavaScript ecosystem. What started as a specialised platform for edge API handlers has grown into a full-stack runtime that can host nearly any modern framework with minimal friction.

The key to a smooth deployment experience is understanding the layered model: the Workers runtime is not Node.js, adapters bridge that gap, and wrangler.toml is the control plane for everything. Approach each framework in the complexity order described in this guide — start with static sites to build confidence, then move to SSR frameworks, and finally tackle the more opinionated full-stack setups.

Merits of This Approach

Global edge performance: Your application runs within milliseconds of every user on the planet, with no need to manage multi-region infrastructure.

Operational simplicity: No servers to patch, no container orchestration, no auto-scaling configuration. Cloudflare handles all of it.

Ecosystem breadth: With 18+ frameworks officially supported as of 2026, you are rarely forced to abandon your preferred tooling.

Cost model: The generous free tier and usage-based pricing mean small to medium applications can run for near zero cost.

Integrated data layer: KV, D1, R2, Queues, and Durable Objects are first-class citizens. Your data lives on the same network as your compute.

Developer experience: Wrangler, local emulation via Miniflare, and first-class TypeScript support make the day-to-day development loop fast and predictable.

Demerits and Limitations

Runtime constraints: Not all Node.js APIs are available. Libraries that deeply depend on Node.js internals — native addons, fs in non-polyfilled contexts, certain crypto operations — may not work without modification.

CPU time limits: Workers are designed for fast, short-lived tasks. The default CPU time limit per request is 30ms (subroutine mode) or 30 seconds (standard mode). CPU-intensive workloads like image processing or ML inference require careful architecture.

Framework maturity on edge varies: While Next.js, SvelteKit, and Nuxt have well-tested Cloudflare adapters, newer frameworks like Waku or TanStack Start are still evolving their edge deployment story. Production usage requires closer monitoring.

Stateful patterns require rethinking: Sessions, WebSockets (possible via Durable Objects), and long-lived connections require adapting your architecture. You cannot simply lift and shift a stateful Express app.

Debugging complexity: Debugging production edge functions is more involved than debugging a traditional server. Structured logging via console.log (visible in Cloudflare's real-time log tail) and proper error boundaries are non-negotiable.

Vendor lock-in: The more deeply you integrate Cloudflare-specific primitives (D1, Durable Objects, R2 bindings), the harder it becomes to migrate away. This is a common trade-off with any platform-native approach.

Caution: Do This at Your Own Risk

While Cloudflare Workers is a production-grade platform used by companies at massive scale, every deployment scenario in this guide should be treated as a starting point rather than a final recipe. Framework adapters are maintained by both Cloudflare and community contributors, and compatibility can shift with major framework version bumps.

Always test thoroughly in a staging environment (use Cloudflare’s built-in preview deployments for Pages) before routing production traffic. Review the compatibility matrix for your specific framework version and adapter version. And never treat a successful local wrangler dev session as a guarantee of production behaviour — the local emulation is very good in 2026, but edge cases exist.

If you are migrating a revenue-critical application, run Cloudflare Workers in parallel with your existing deployment, use traffic splitting or gradual rollout, and monitor error rates closely before full cutover.

1. How do I deploy Next.js to Cloudflare Workers in 2026?
2. What JavaScript frameworks does Cloudflare Pages support?
3. How does the OpenNext Cloudflare adapter work for Next.js App Router?
4. What is the difference between Cloudflare Workers and Cloudflare Pages?
5. How do I use SvelteKit with Cloudflare adapter in production?
6. Can I deploy Nuxt 3 to Cloudflare Workers?
7. What is wrangler.toml and how do I configure it for my framework?
8. Does Cloudflare Workers support Node.js APIs?
9. How do I manage environment variables and secrets in Cloudflare Workers?
10. What is the CPU time limit for Cloudflare Workers in 2026?
11. How do I deploy Astro to Cloudflare with SSR enabled?
12. What is Miniflare and how does it improve local Workers development?
13. How do I use Cloudflare D1 database with SvelteKit or Nuxt?
14. Is Hono better than Express for Cloudflare Workers?
15. How do I deploy a React Router v7 (Remix) app to Cloudflare?
16. What are the limitations of running Angular SSR on Cloudflare Workers?
17. How do I add a custom domain to a Cloudflare Pages project?
18. What is the difference between Cloudflare KV, D1, and R2?
19. How do I deploy Qwik City to Cloudflare Pages?
20. What is RedwoodSDK and how does it differ from RedwoodJS?

#CloudflareWorkers #CloudflarePages #Wrangler #NextjsDeployment #SvelteKit #NuxtJS #AstroFramework #HonoJS #ReactRouter #RemixRun #TanStackStart #SolidStart #AnalogJS #Qwik #Vike #Waku #RedwoodSDK #EdgeComputing #JamstackDeployment #ServerlessEdge #WebDevelopment2026 #FullStackDeployment #CloudflareD1 #CloudflareR2 #ModernWebDev #JavaScriptFrameworks #TypeScriptDeployment #EdgeFirst #WebPerformance #DevOps2026 #CloudNative #FrontendDevelopment #BackendlessArchitecture #JAMstack2026 #OpenNextJS #MiniflareV4 #WorkersRuntime #DeploymentGuide #AngularSSR #GatsbyCloudflare #DocusaurusDeployment