Introduction
Queuebase is a background job processing system. Jobs use a callback model: your app defines job handlers at a webhook endpoint, the Queuebase service stores and schedules jobs, then calls back to your app to execute them. This works identically in local dev (via the CLI) and in production.
Why Queuebase?
Section titled “Why Queuebase?”- No separate worker infrastructure — Your job handlers live in your app. Queuebase stores, schedules, and retries jobs, then calls back to your app to execute them.
- Same flow in dev and production — The CLI runs a local server with SQLite for development. In production, the hosted API uses Postgres. Your code doesn’t change.
- Type-safe with any validator — Define job inputs with any Standard Schema-compatible library (Zod, Valibot, ArkType). Get full type inference from enqueue to handler.
How it works
Section titled “How it works”- Your app calls
jobClient.myJob.enqueue({ ... }) - The SDK POSTs the job to the Queuebase API (local CLI in dev, hosted API in production)
- Queuebase stores the job in the database and schedules it
- When it’s time to run, Queuebase POSTs back to your app’s webhook endpoint (e.g.
/api/queuebase) - Your handler executes the job and returns the result
This callback model means your job code lives in your app, not in a separate worker process. Queuebase handles the scheduling, retries, and persistence.
Prerequisites
Section titled “Prerequisites”- Node.js 18 or later
- A Next.js or Node.js application
- A validation library compatible with Standard Schema (Zod, Valibot, ArkType, etc.)
Installation
Section titled “Installation”Next.js
Section titled “Next.js”# Zod is shown here, but any Standard Schema-compatible library worksnpm install @queuebase/nextjs zodNode.js (Express, Fastify, etc.)
Section titled “Node.js (Express, Fastify, etc.)”# Zod is shown here, but any Standard Schema-compatible library worksnpm install @queuebase/node zodBoth packages re-export everything from @queuebase/core, so you only need one.