Comparison · Inquir Compute

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.

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.

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.

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.

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.

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.

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.

1

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.

2

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.

3

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.

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.

vercel-app/enqueue.js (any Vercel framework — client side)
// 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' }
}
inquir/gateway-enqueue.mjs (Inquir HTTP gateway handler)
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' }) };
}
inquir/process-upload.mjs (Inquir pipeline step)
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 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

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.