Cloudflare Dynamic Workers

Use Cloudflare Dynamic Workers when the sandbox should load through the Worker Loader API instead of Durable Objects. ViteHub keeps this provider explicit, so it never replaces the standard Cloudflare sandbox automatically.

Before you start

Install @vitehub/sandbox.

pnpm add https://pkg.pr.new/vite-hub/vitehub/@vitehub/sandbox@main

You also need a Cloudflare deployment that supports the Worker Loader API. ViteHub adds the worker_loaders entry for the configured binding when it builds the Cloudflare target.

Configure Cloudflare Dynamic Workers

export default defineNuxtConfig({
  modules: ['@vitehub/sandbox/nuxt'],
  sandbox: {
    provider: 'cloudflare-dynamic',
    loaderBinding: 'LOADER',
    compatibilityDate: '2026-03-25',
  },
})

Cloudflare Dynamic-specific options

Use loaderBinding to point ViteHub at the Worker Loader binding name in your Cloudflare runtime. If you do not set it, ViteHub defaults to LOADER.

Set compatibilityDate explicitly. The provider uses it to build the worker code payload and to validate that the runtime is pinned to a Cloudflare date string.

Use sandboxId when repeated runs should reuse the same dynamic worker identity. ViteHub uses load() for ephemeral runs and get() when sandboxId is present.

Leave globalOutbound unset when the sandbox should not make outbound network calls. ViteHub defaults that field to a blocked posture unless you enable it explicitly.

Define a sandbox

Sandbox definitions stay portable. The provider changes the runtime that executes the bundle, not the definition API itself.

import { defineSandbox } from '@vitehub/sandbox'

export default defineSandbox(async (payload?: { notes?: string }) => {
  return {
    notes: payload?.notes || '',
  }
}, {
  timeout: 30_000,
})

What changes on Cloudflare