Vercel or a VPS for background jobs?

Quick answer: Keep an occasional, bounded job in a Vercel Function if its configured runtime and duration cover the work. Use a durable workflow or queue when the job must survive pauses, retries or deployments without losing progress. A persistent VPS worker fits a process that must run continuously or needs operating-system-level control, provided someone owns patches, monitoring and recovery. You can leave the frontend on Vercel and move only the worker.

Important constraint: Vercel does support longer background work. Its current Function limits document an 800-second general Pro/Enterprise maximum and an eligible 1,800-second extended beta, subject to runtime and configuration conditions. A 20-minute job exceeds 800 seconds but can fit the beta’s duration ceiling in an eligible setup. Neither a Cron schedule nor a waitUntil callback removes the Function’s invocation limit. Sources: Function duration, Cron Jobs, Functions API.

The choice is less about where the web page is hosted than how the work behaves. A report export that uses CPU for 30 seconds and then waits on a third-party API for 19 minutes has a different resource shape from 20 minutes of continuous image processing. Both may have the same wall time. A worker that polls forever has a third shape. Record the job before comparing platforms; otherwise a single duration number hides the restart and side-effect risks that determine the design.

Write a job card before choosing execution

For each job, record its trigger, expected and worst plausible wall time, active CPU time, memory, network waits, data size, secrets, and whether the user needs an immediate response. Then ask what happens if the process stops halfway. Can it retry the whole job without sending a second invoice or duplicate email? Can it resume from a checkpoint? Who sees failures and who can restart it? A short job with an irreversible side effect can need more careful orchestration than a longer read-only calculation.

These cards describe decisions to verify, not performance results. Measure the job in a representative environment, including realistic data and third-party delays, before selecting a production timeout. If work varies widely, a median duration is a poor safety margin. A scheduled export can be split into smaller units when each unit can be checkpointed, but that changes the application design and side-effect rules.

For each card, also name the unit of completion. Is the export finished when the file exists, when its download link is stored, or when the customer receives a notification? These events can be separated by a crash. Record them independently so a retry can finish the missing step without repeating one already committed. If a job writes to an external service, ask whether that service accepts a stable request ID; if it does not, define a way to reconcile an uncertain response before sending the action again. A longer runtime alone will not solve a duplicate side effect.

A bounded Function is still a real background option

Vercel’s limits page currently lists 300 seconds maximum on Hobby for Fluid Compute Node, Bun and Python Functions. For Pro and Enterprise it lists a 300-second default, an 800-second generally available maximum, and 1,800 seconds under an extended beta. The duration configuration guide adds eligibility details, including supported runtime versions, function-level configuration, and exclusions involving Secure Compute or Static IP. Check the current account, runtime and deployed Function settings before treating the beta as available.

A 40-second follow-up may fit a configured Function well. If the HTTP request should respond before the follow-up finishes, Vercel documents waitUntil and framework after() behavior for continuing work after the response. That changes when the response is returned; it does not grant unlimited execution time. Decide how a failed follow-up is recorded and replayed. A webhook sender may also retry the original request, so give the operation a stable idempotency key or an equivalent duplicate guard before it causes a second external action.

A 20-minute export is 1,200 seconds. It exceeds the 800-second general maximum but falls below the 1,800-second beta ceiling. That arithmetic is only a duration comparison. The job might be ineligible for the beta, need more memory than configured, run into third-party delays, or require progress and retries that are awkward inside one invocation. If an eligible long Function is used, set a deadline below its allowed duration, store progress outside the invocation, and decide how to recover an interrupted export. Do not treat the beta ceiling as a completion guarantee.

Vercel Cron Jobs can trigger Functions on a schedule, but the Function still has its duration limit. Cron does not automatically retry a failed invocation, and scheduled invocations can overlap. If a daily export has not finished when the next run begins, the app needs a rule for overlap: skip, queue or coordinate a single logical run. A Cron expression by itself is neither a durable queue nor an exactly-once side-effect mechanism.

Durable execution solves a different problem

Vercel Workflows offer durable, multi-step execution that can pause, resume and retry steps across crashes or deployments. That is useful when a task waits for a response, needs checkpoints, or should resume without keeping one uninterrupted Function alive. A workflow’s elapsed lifetime is not the same as permission to run one CPU-heavy step without bounds. Design each active step for its own limits, persist the state it needs, and make repeated steps safe.

For the export, a workflow could record the input and job ID, fetch or process a bounded batch, save a checkpoint, then continue to the next batch. The final step publishes one completed artifact. If a step is retried, it must recognize work already committed. A file name derived only from a timestamp may be insufficient if two retries create different outputs; a stable job ID and explicit completion record make duplicates visible. The exact storage and queue design depends on the app, but the recovery question is universal: what evidence lets the next attempt know where to resume?

Workflows add orchestration and state to the cost and operational picture. Current documentation describes usage-based events and data, without a price used here. Compare the actual job’s number of steps, stored state, compute, network and storage against your account’s terms. If a single bounded Function handles the task reliably, a workflow may add unnecessary complexity. If a 20-minute invocation must restart from zero after every interruption, durable steps may be worth the extra design work.

A VPS worker trades platform limits for operator work

A persistent worker on a VPS can stay running, poll a queue and control its operating environment. It can be a reasonable fit for a process with no natural endpoint, a dependency the Function runtime cannot host, or a workload that benefits from one long-lived local process. The VPS does not supply correctness by itself. Your team must patch the OS and runtime, protect secrets, supervise the process, define health checks, restart failed work, manage disk and logs, and recover after the server is unavailable.

For the continuous poller card, first ask whether polling must be continuous. If the source offers events or a schedule is sufficient, a bounded Function or durable workflow may reduce the need for an always-running machine. If the process truly maintains a live connection or state in memory, design how it rebuilds that state after a restart. Give it a durable cursor or checkpoint and a duplicate-safe handler. An in-memory counter alone will not survive a host failure.

The frontend can remain on Vercel while the VPS worker consumes jobs through a queue or data store. That hybrid avoids moving a working web deployment solely because one task has different execution needs. It also adds a trust boundary: the web app must authenticate job submission, the worker must have scoped credentials, and both sides need a shared record of job state. A failed worker should leave the user with an accurate “pending” or “failed” result rather than a silent success page.

Compare cost inputs without inventing a price winner

Use the same representative job volume and reliability expectation for each model. Quote the current plan and market only after the architecture is clear. Vercel’s Hobby plan is for personal, noncommercial use, so it is not a free production-business baseline in this comparison.

Fill each row with your own observed volume and current quote. Include operator time even when it does not appear on a cloud invoice. Keep storage and network in every model that uses them. A low server sticker price is not a fair comparison with a managed job path if the worker needs a second machine, monitoring and after-hours recovery; equally, usage-based orchestration is not automatically cheaper for frequent, compute-heavy work.

Choose the least complex model that meets the job’s duration, restart and side-effect requirements. For a bounded webhook follow-up, that may be a Function with duplicate protection. For a 20-minute export, check beta eligibility and compare it with checkpointed workflow design. For a continuous poller, decide whether it can become event-driven; if not, assign an owner to a persistent worker. Revisit the decision when job volume or failure tolerance changes. The hosting hub covers related infrastructure choices, but the job card is the useful starting point for this one.