Worker SSR runs your framework's server code on the edge network, in a Worker close to each visitor, instead of shipping only prebuilt files. Each request renders on demand; static assets from the same build are served alongside. Use it for a JavaScript framework app that needs server rendering, API routes or server actions, and that builds for Cloudflare Workers.
For a PHP, Ruby or Node server process, use Container apps. To keep an existing backend and serve the rest statically, use a Hybrid app.
Note
Worker SSR needs a plan. It has no per-site fee: a Worker SSR app bills for its Workers CPU time and delivery usage like any other app. See Plans & pricing.
Supported frameworks
dply detects the framework from package.json. Frameworks other than Next.js need their Cloudflare adapter installed, or the build fails with a message naming the missing package.
| Framework | Detected by | Adapter you install | Build command | Worker output |
|---|---|---|---|---|
| Next.js | next |
none | dply runs npx @opennextjs/cloudflare build |
.open-next/worker.js |
| SvelteKit | @sveltejs/kit |
@sveltejs/adapter-cloudflare |
your build command | .svelte-kit/cloudflare/_worker.js/ |
| Astro | astro |
@astrojs/cloudflare |
your build command | dist/_worker.js/ |
| Remix | @remix-run/cloudflare |
@remix-run/cloudflare |
your build command | build/server/index.js |
| Keel | @shaferllc/keel |
none | dply runs wrangler deploy --dry-run |
.dply-keel-bundle/worker.js |
For Next.js and Keel, dply ignores the app's build command and runs its own. For the others it runs your build command (by default npm run build) after installing dependencies, and expects the Worker output at the path above. Remix's older _worker.js template is not detected.
Create a Worker SSR app
When dply detects a supported framework, choose Worker SSR as the delivery mode on create. The first build of a Next.js app can take several minutes.
How requests are handled
Each deploy uploads its own Worker script and its static assets. Requests to your hostnames pass through the firewall, bot protection, rate limits, access gate and your redirects, then go to that deploy's Worker, which renders the page or serves an asset.
Edge middleware from src/middleware.ts is not used on Worker SSR apps; your framework's own middleware (for example Next.js middleware.ts) runs inside the Worker instead.
Each request to the Worker carries X-Dply-Deployment-Id and X-Dply-Site-Id headers.
Environment variables
Every production variable under Environment is available to your server code on the Worker's env object (for example env.API_KEY), as a secret. Frameworks that read process.env get the same values where their Cloudflare adapter provides it. Changes apply on the next deploy.
The Worker runs with Cloudflare's nodejs_compat flag and a compatibility date of 2024-11-01.
Limits
- The Worker bundle, including every module, can be at most 9 MB. A larger bundle fails the build with the size and module count.
- Your code runs under Cloudflare's Workers runtime limits for CPU time and memory per request. dply does not change them.
- A Worker runs no long-lived process. For background work use Queues or Workflows.
Caching
dply does not add Cache-Control to rendered responses; your framework's headers pass through. To cache rendered pages on the edge, turn caching on in the Cache section. See Caching.
Rollbacks, promotions and previews
Every deploy keeps its own Worker script, so a rollback or a preview promotion switches traffic to an existing script without rebuilding. Old scripts are removed when their deploy ages out of the app's retained releases.
Scheduled work
A schedule on a Worker SSR app calls the scheduled export of your Worker entry. Framework builds do not export one by default. See Scheduled tasks.
When the Worker is unreachable
If the Worker for a deploy cannot be reached, visitors get 503 with Retry-After: 30 and the text "Service temporarily unavailable". Redeploy the app; if it persists, contact support.