Host continuous background workers on a managed worker platform such as Vercel Daemons, a cloud container service, or a VPS you operate. Start with managed hosting when you want the platform to maintain running processes. Choose based on how work arrives, access to your queue, and how jobs recover after interruption.
Copy link to headingDo you need a worker, a cron job, or a workflow?
Background workers run application code outside the user's request. For example, an app can accept a report request and put a job on a queue. The worker retrieves that job, generates the report, and stores the result for the app to retrieve later.
Identify how work reaches your code before choosing the execution model. Queue consumers wait for new tasks, while scheduled scripts start at a specified time and exit when finished.
Vercel Cron Jobs triggers an HTTP request to a production route. That route can do suitable work within its execution limits or enqueue a longer task. Scheduling determines when work starts; the task still needs an execution and recovery plan.
Vercel Queues supports push callbacks and polling consumers. You can therefore choose a callback handler or a process that retrieves messages. For a sequence that must preserve progress between steps, Vercel Workflows can retry failed steps, wait for events, and resume after crashes or deployments.
Copy link to headingWhich hosting model fits your worker?
Copy link to headingStart with managed worker hosting
Managed worker hosting lets you deploy the process and configure its capacity while the platform handles its execution lifecycle. Evaluate this model when your team wants to ship worker code without operating the underlying server.
Vercel Daemons runs continuous processes from container images and maintains your configured instance count. Render background workers also run continuously, polling for tasks without receiving inbound network traffic. Railway services support persistent processes deployed from source or Docker images, alongside scheduled jobs that run to completion.
For each candidate, build the image to verify its dependencies, then run the worker's actual start command against a development queue. Confirm that the running worker authenticates to the broker and processes a representative job before treating the deployment as compatible.
Copy link to headingEvaluate a container service for existing cloud infrastructure
If your deployment already depends on a cloud provider's infrastructure, evaluate its container service as a worker host. Amazon ECS services maintain a desired number of tasks and replace tasks that stop. Queue consumers can run without a public HTTP endpoint because ECS doesn't require a load balancer.
Include task permissions and network access in the evaluation. Identify who will maintain the service configuration and how a release reaches it. The worker's container image is one input to that operating model; it doesn't transfer an existing queue or its permissions.
Copy link to headingAccount for server operations on a VPS
On a self-managed VPS, your team owns the worker's host as well as its deployment. Docker restart policies can restart a container after it exits or when Docker restarts, depending on the policy. You still need an owner for host updates, monitoring, and recovery when the server itself is unavailable.
Include those responsibilities when comparing the VPS with managed hosting. Test a host restart and an application release, then check whether pending jobs continue processing and whether an operator can identify failures from the available logs.
Copy link to headingHow do you host background workers with Docker?
Docker packages your worker's runtime, dependencies, and application code into an image. Use the Dockerfile's build instructions and startup configuration to install what the worker needs and launch its consumer process. For example, a Python image can start a Celery worker, while a Node.js image can start a BullMQ consumer. Neither needs a web server to retrieve jobs from a queue.
For an existing Docker worker, check whether the host builds your Dockerfile or accepts a prebuilt image, and how it selects the startup command. Test that command locally against a development broker. If a startup script wraps the worker, verify that shutdown signals reach the worker process so it can stop accepting jobs and finish active work.
Keep queue data and completed results in external storage, and supply runtime credentials through the host's configuration. Rebuilding or replacing the worker container should leave the work it needs to process available.
Copy link to headingHow can you run background workers on Vercel?
Vercel Daemons supports pull-based workers such as Celery, Sidekiq, and BullMQ. Package the worker with a Dockerfile or Containerfile and deploy it as a daemon. Vercel maintains the requested processes and restarts instances that exit or crash.
This gives an existing worker a deployment path alongside your application. Keep its job-processing logic and validate the dependencies it needs from the new environment. The worker can continue to use its queue library; separately confirm that the broker's protocol, credentials, and network access work from the destination.
Daemon configuration follows the production deployment, and you can change instance counts with an override without redeploying. During a rollout, old instances have a grace period to finish active work while the new version starts. Test message formats and database changes against both versions so a deployment doesn't leave one unable to process the other's jobs.
The current Daemons limits shape the deployment plan. Workers run only in production, with no autoscaling or persistent local storage. Run their images locally with Docker for testing, store durable state externally, and set capacity deliberately. Daemons also doesn't accept inbound HTTP or TCP connections; use an HTTP service for webhook delivery or an API endpoint.
Copy link to headingWhat should you test before choosing a host?
Copy link to headingCheck the full connection path
Run a job from the proposed host against every required dependency. Include TLS and authentication, then verify both reads and writes. Check whether the broker's private hostname resolves from the destination; copying its environment variable won't extend the current platform's network.
If the broker must move too, plan that as a separate state migration. Account for delayed jobs and retries as well as jobs waiting for immediate execution. Preserve a way to reconcile the old and new systems before retiring either one.
Copy link to headingMeasure concurrency against downstream capacity
Treat instance count and worker concurrency as separate settings. If each of two instances processes four jobs simultaneously, the configured total is eight, assuming no additional concurrency limit. Check that the database and external APIs can handle that amount of work.
Use a representative backlog to measure job completion time and resource use. Increase capacity only after identifying the bottleneck. If jobs spend most of their time waiting on a rate-limited API, adding workers can create more throttled requests without clearing the queue sooner.
Copy link to headingTest interruption and repeated execution
Check a graceful stop and an abrupt termination separately. Configure the shutdown handler to stop accepting new work and finish or release active tasks according to the queue library's rules. Test what happens when a task outlasts the host's shutdown window, including how long it takes to become available again.
Retries also need application-level protection. BullMQ recommends idempotent jobs, where retrying a failed attempt preserves the intended result. For example, use a stable report identifier and enforce uniqueness when saving the result. Handle notification delivery separately so repeating the job doesn't send another notification. Test failures between the database write and the notification call; saving a result alone doesn't make both operations safe to repeat.
Copy link to headingMake job progress observable
Include a job identifier in logs so you can follow one task through attempts and completion. Monitor the age of pending work alongside failures and throughput to distinguish a healthy process from one that has stopped completing jobs. Test whether your team can find and recover a job that repeatedly fails.
Copy link to headingHow should you move an existing worker?
Begin with one worker and a development queue. Verify its normal execution, then test a release while work is in progress. Before production handoff, check whether old and new workers can safely consume the same job formats and whether their combined concurrency fits downstream limits.
The guides for moving Render background workers to Vercel Daemons and moving Railway workers to Vercel Daemons cover platform settings, broker access, and worker handoff. Use the guide for your current host to plan cutover and rollback.
Move scheduler ownership separately from consumers. Confirm that only the intended scheduler enqueues each recurring task, and account for intervals missed during the transition. Keep the previous worker configuration available until the new deployment has processed representative work and you have tested the recovery path.
Copy link to headingFrequently asked questions
Copy link to headingCan Vercel run background workers continuously?
Yes. Vercel Daemons hosts long-running container processes that retrieve work from queues or other systems. You configure the instance count, and Vercel replaces processes that stop; Daemons is currently in Public Beta.
Copy link to headingWhere can I host a Python background worker?
Python workers can run on managed worker platforms, cloud container services, or a VPS. On Vercel, you can package a Celery worker with a Dockerfile and run it as a daemon. Validate its Python dependencies and broker connection with a representative task before moving production work.
Copy link to headingCan I deploy a Docker worker without a web server?
Yes. Configure the container to launch a queue consumer as its main process. On Vercel, deploy that process as a daemon; an HTTP container Function serves a different execution model.
Copy link to headingCan I keep my existing queue when changing worker hosts?
Yes, if the new worker can reach the broker securely and supports its protocol and job format. Verify access from the destination before switching consumers. If the broker also moves, include pending work and scheduled retries in the migration plan.
Copy link to headingIs adding worker instances the same as increasing concurrency?
Instance count controls how many copies of the worker run. Concurrency controls how much work each copy handles at once, subject to any shared limits. Evaluate both settings together against the capacity of the systems each job calls.
Copy link to headingDoes automatic restart guarantee that an interrupted job finishes?
No. Restarting replaces the process, but job recovery depends on queue acknowledgment, retry behavior, and application state. Test an interruption during processing and confirm that the task can complete without repeating an unintended side effect.