Background jobs for Vercel apps without worker glue
Background jobs for Vercel apps: keep Next.js and the edge layer on Vercel, move slow async work—email, PDF generation, webhook continuation, data sync—to serverless jobs and pipelines on Inquir. No self-hosted queues, no 10-second timeout hacks, one place to read retries and logs.
Last updated: 2026-04-20
- Keep on Vercel: Next.js app, previews, edge middleware, static assets.
- Move to Inquir: background jobs, cron tasks, webhook async handoff, long-running processing.
- Use both together: Vercel calls Inquir gateway routes to enqueue work; Inquir pipelines run it and post results back.
Answer first
Direct answer
Background jobs for Vercel apps without worker glue. Your Vercel app calls an Inquir gateway route to enqueue a job or trigger a pipeline. Inquir handles the queue, retries, observability, and secrets—your Next.js app stays thin and stateless.
When it fits
- Your Next.js or Nuxt app needs background tasks, webhooks, or cron jobs that exceed edge/serverless timeouts.
- You want one worker tier with shared observability instead of stitching BullMQ + a separate worker server.
Tradeoffs
- A self-hosted BullMQ or SQS consumer needs its own server or container, its own deploy, its own scaling policy, and its own log configuration—before you write one line of business logic.
- Timeouts force awkward patterns: background `fetch()`, `waitUntil()` hacks, or fire-and-forget calls that swallow errors silently.
Workload and what breaks
Why Vercel is not enough for background work
Vercel Edge Functions and Serverless Functions have request-scoped timeouts—anything that needs more than a few seconds must either hack around limits or send work somewhere else. PDF generation, bulk email, slow third-party API chains, and data sync are obvious examples.
Without a dedicated worker tier, teams bolt on external queues (BullMQ, SQS, Pub/Sub) plus a separately deployed background process. That means two deploy pipelines, two secret stores, and two places to look when a job silently fails at 3 AM.
Trade-offs
Why adding a separate worker breaks flow
A self-hosted BullMQ or SQS consumer needs its own server or container, its own deploy, its own scaling policy, and its own log configuration—before you write one line of business logic.
Timeouts force awkward patterns: background `fetch()`, `waitUntil()` hacks, or fire-and-forget calls that swallow errors silently.
How Inquir helps
Keep Vercel for the UI, Inquir for background work
Your Vercel app calls an Inquir gateway route to enqueue a job or trigger a pipeline. Inquir handles the queue, retries, observability, and secrets—your Next.js app stays thin and stateless.
Background jobs, cron tasks, and webhook continuation all live in one Inquir workspace. Shared secrets, shared execution history, one place to read logs and set alerts—no separate worker infrastructure to maintain.
What you get
Background job patterns for Vercel apps
Async handoff from API routes
Next.js API route returns 202 immediately; calls Inquir gateway to trigger a pipeline that does the slow work—email, PDF, data enrichment.
Webhook continuation
Inquir webhook function acks the provider within the timeout window, then continues processing in a pipeline step—no more Vercel function timeout on Stripe webhooks.
Scheduled background jobs
Run nightly ETL, token rotation, or report generation as cron-triggered pipelines—visible run history alongside your Vercel preview deploys.
Parallel fan-out
Trigger multiple pipeline steps in parallel after an HTTP response—send N emails, process N files, or call N APIs without blocking the user.
What to do next
How to wire background jobs from a Vercel app to Inquir
Create a pipeline or job function on Inquir
Write the slow logic as a handler; expose it as a pipeline step. Keep it stateless with explicit inputs.
Enqueue from your Vercel API route
POST to the Inquir gateway route with an API key in the Authorization header. Return 202 to the user immediately.
Monitor in Inquir execution history
See every job run, retry, and output in one console—no separate worker dashboard.
Code example
Next.js → Inquir: enqueue a background job
Next.js API route returns 202 immediately; triggers an Inquir pipeline in the background. The pipeline step does the slow work and posts a webhook back when done.
export async function POST(request: Request) { const { reportId } = await request.json(); // Enqueue background job on Inquir — do not await await fetch(process.env.INQUIR_GATEWAY_URL + '/jobs/generate-pdf', { method: 'POST', headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${process.env.INQUIR_API_KEY}`, }, body: JSON.stringify({ reportId }), }); return Response.json({ status: 'queued' }, { status: 202 }); }
export async function handler(event) { const { reportId } = JSON.parse(event.body || '{}'); if (!reportId) return { statusCode: 400, body: JSON.stringify({ error: 'reportId required' }) }; const pdf = await buildReport(reportId); await storage.upload(pdf, `reports/${reportId}.pdf`); await notifyUser(reportId); return { reportId, size: pdf.byteLength }; }
When it fits
When this pattern helps
When this works
- Your Next.js or Nuxt app needs background tasks, webhooks, or cron jobs that exceed edge/serverless timeouts.
- You want one worker tier with shared observability instead of stitching BullMQ + a separate worker server.
When to skip it
- Your background work already fits inside Vercel Fluid Compute concurrency and you are comfortable with the billing model there.
FAQ
FAQ
Can I still deploy my Next.js app on Vercel?
Yes—this is the recommended pattern. Keep the Vercel frontend and edge layer; move only background workers and slow async work to Inquir.
How do I secure the enqueue call?
Store an Inquir API key in Vercel environment variables. The Inquir gateway route requires a bearer token so only your Vercel app can trigger jobs.
What about Vercel Fluid Compute?
Fluid Compute extends concurrency for serverless functions on Vercel—useful when IO-heavy work fits within request scope. Use Inquir for work that genuinely needs to outlive the HTTP request, run on a schedule, or continue after a webhook ACK.
Do I need to manage a separate queue?
No. Inquir pipelines handle queuing, retries, and observability. Your Vercel API route just calls an Inquir gateway route—Inquir manages the rest.