SSR and workers

Several Workbench adapters mount into SSR frameworks whose server processes are optimized for request handling, not long-running job consumption:

• Next.js
• Astro
• Nuxt
• TanStack Start

The pattern

1. Web server — your framework app mounts Workbench and serves the dashboard UI
2. Worker process — a separate Node/Bun process runs Worker instances that consume jobs from Redis

Both processes connect to the same Redis. Workbench reads queue state from Redis; workers mutate it. No duplicate config needed beyond shared REDIS_URL.

Example layout

my-app/
├── app/                    # Next.js app with Workbench at /jobs
├── worker/
│   └── index.ts            # BullMQ Worker bootstrap
└── package.json            # "dev": "concurrently \"next dev\" \"bun worker/index.ts\""

See the monorepo examples for working setups:

• examples/with-next
• examples/with-astro
• examples/with-nuxt
• examples/with-tanstack-start

Why not run workers in the framework server?

Serverless and edge deployments can't run persistent workers. Even on a long-lived Node server, mixing worker loops with SSR request handling makes scaling and deploys harder — workers and web traffic have different resource profiles.

Mounting Workbench in the web server is fine: it's read-heavy HTTP. Workers belong in a dedicated process (or container) you scale independently.