Background jobs for Vercel apps without worker glue
The Vercel platform excels at UI, edge middleware, static assets, and preview deployments. Work that needs to outlast a single function timeout—email, file transforms, data sync, webhook continuation—belongs in a dedicated worker tier. Inquir is that tier: a gateway endpoint your Vercel app POSTs to, a pipeline that runs the job, one console to read retries and logs. Works with any Vercel framework—Next.js, SvelteKit, Nuxt, Astro.
Last updated: 2026-06-28
- Keep on Vercel: UI, edge middleware, static assets, preview deployments.
- Move to Inquir: background jobs, cron pipelines, webhook continuation, long-running processing.
- How it works: your Vercel app POSTs to an Inquir gateway endpoint; the endpoint returns 202 and triggers the pipeline.
Answer first
Direct answer
Background jobs for Vercel apps without worker glue. Your Vercel app—whatever framework it uses—sends an HTTP POST to an Inquir gateway endpoint with an API key. The endpoint queues the job and returns 202 immediately. A pipeline step picks up the payload, runs the slow work outside any HTTP timeout, and can call back to your app when done.
When it fits
- Any Vercel app—Next.js, SvelteKit, Nuxt, Astro—needs background tasks, webhooks, or cron jobs that outlast edge or serverless function timeouts.
- You want one worker tier with shared observability instead of stitching BullMQ, Redis, and a separate worker server onto your Vercel project.
Tradeoffs
- Vercel Cron (via
vercel.json),waitUntil()in Edge Functions, and Fluid Compute all cover lightweight async work that completes inside platform timeouts—cache warming, a single downstream API call, or a small scheduled cleanup. - If your entire stack lives on Vercel and every async path fits within those limits, adding a second vendor is extra ops cost you may not need.
Workload and what breaks
Where Vercel function timeouts become a topology problem
Vercel Serverless Functions and Edge Functions run inside the request/response window. That window is fine for API responses, middleware rewrites, and short async tasks—but PDF generation, bulk email, slow third-party chains, and nightly ETL all outlast it. The platform is not broken; the work belongs elsewhere.
Without a dedicated worker tier, teams bolt on BullMQ+Redis, SQS, or a separately deployed process. That means a second deploy pipeline, a second secret store, and two dashboards to check when a job fails silently at 3 AM—regardless of whether the Vercel app is Next.js, SvelteKit, Nuxt, or Astro.
Trade-offs
When Vercel alone is enough
Vercel Cron (via vercel.json), waitUntil() in Edge Functions, and Fluid Compute all cover lightweight async work that completes inside platform timeouts—cache warming, a single downstream API call, or a small scheduled cleanup.
If your entire stack lives on Vercel and every async path fits within those limits, adding a second vendor is extra ops cost you may not need.
How Inquir helps
Vercel owns the edge; Inquir owns the slow path
Your Vercel app—whatever framework it uses—sends an HTTP POST to an Inquir gateway endpoint with an API key. The endpoint queues the job and returns 202 immediately. A pipeline step picks up the payload, runs the slow work outside any HTTP timeout, and can call back to your app when done.
Background jobs, cron pipelines, and webhook continuation all live in one Inquir workspace. Shared secrets, shared execution history, one place to read logs and configure alerts—no Redis cluster, no worker Dockerfile, no second deploy pipeline.
What you get
Vercel + Inquir: deployment topology patterns
Async handoff on any framework
Any Vercel serverless function—SvelteKit endpoint, Nuxt server route, Astro API route, Next.js Route Handler—POSTs to an Inquir gateway endpoint and returns 202. The pipeline carries the slow work.
Webhook continuation
An Inquir gateway endpoint acks the provider (Stripe, GitHub, Slack) within the timeout window, then continues processing in a pipeline step—provider retries do not re-run expensive work.
Cron beyond vercel.json
Nightly ETL, token rotation, and report generation run as cron-triggered Inquir pipelines with visible run history—not a fragile serverless function behind a Vercel cron hit.
Parallel fan-out
A pipeline parallel node fans out to multiple steps after the 202 response—send N emails, process N files, or call N APIs without blocking the user or the Vercel function.
What to do next
How to wire background jobs from a Vercel app to Inquir
Your Vercel app stays unchanged except for one fetch call. The Inquir gateway endpoint queues the job and returns 202. A pipeline step carries the slow work and posts results back to your app.
Create a gateway endpoint and pipeline step on Inquir
Deploy an HTTP handler that enqueues an async job and returns 202; deploy the worker logic as a separate pipeline step. Keep each step stateless with explicit inputs.
POST from your Vercel app
Anywhere in your Vercel app—SvelteKit, Nuxt, Astro, or Next.js—fetch the Inquir gateway URL with Authorization: Bearer from an environment variable. Return 202 to the user before the pipeline finishes.
Monitor in Inquir execution history
Every run, retry, and pipeline output appears in one console. No digging through Vercel function logs for a job that started in a serverless function.
Code example
Vercel app → Inquir: framework-agnostic enqueue pattern
Any Vercel app POSTs to an Inquir gateway endpoint. The gateway handler enqueues an async job and returns 202 immediately. The pipeline step runs the slow work outside any HTTP timeout. The pattern is identical whether the caller is a Next.js Route Handler, a SvelteKit server endpoint, a Nuxt server route, or an Astro API route.
// Runs in any Vercel serverless function: SvelteKit, Nuxt, Astro, Next.js, etc. async function enqueueBackgroundJob(payload) { const res = await fetch(process.env.INQUIR_GATEWAY_URL + '/jobs/process-upload', { method: 'POST', headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${process.env.INQUIR_API_KEY}`, }, body: JSON.stringify(payload), }); // Gateway always returns 202; job runs in the Inquir pipeline return res.json(); // { jobId, status: 'queued' } }
export async function handler(event) { const body = JSON.parse(event.body || '{}'); if (!body.uploadId) { return { statusCode: 400, body: JSON.stringify({ error: 'uploadId required' }) }; } // Enqueue async work; returns immediately — the pipeline step runs outside the HTTP window const { instanceId: jobId } = await global.durable.startNew('process-upload', undefined, body); return { statusCode: 202, body: JSON.stringify({ jobId, status: 'queued' }) }; }
export async function handler(event) { // event.payload carries the body the Vercel app sent const { uploadId, userId } = event.payload ?? {}; const result = await transformFile(uploadId); await storage.put(`processed/${uploadId}`, result); await notifyUser(userId, uploadId); return { uploadId, bytes: result.byteLength }; }
When it fits
When this topology helps
When this works
- Any Vercel app—Next.js, SvelteKit, Nuxt, Astro—needs background tasks, webhooks, or cron jobs that outlast edge or serverless function timeouts.
- You want one worker tier with shared observability instead of stitching BullMQ, Redis, and a separate worker server onto your Vercel project.
When to skip it
- All background work already completes inside Vercel Fluid Compute or
waitUntil()and you do not need cross-request job history or per-step retries.
FAQ
FAQ
Does this work with frameworks other than Next.js?
Yes—any Vercel app that can call fetch in a serverless function works. SvelteKit server endpoints, Nuxt server routes, and Astro API routes all call the same Inquir gateway URL. No framework-specific adapter required.
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 needs to outlast 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 scheduling, retries, and observability. Your Vercel app just calls an Inquir gateway endpoint—Inquir manages the rest.