Use a Vercel Function for request-driven application work. Consider a Vercel Daemon when an existing process continuously pulls jobs from a queue or workflow engine. Vercel opened Daemons to public beta on October 15, 2026, giving teams another way to host long-running workers alongside their app.
The useful question for a US SaaS team is whether its worker and recovery model fit the beta's constraints. This comparison uses a fictional document-export service and official documentation checked on October 16. It is an architectural assessment, not a benchmark, a production migration report or a claim that moving the worker will reduce your bill.
Key takeaways
- A daemon pulls work; it cannot serve inbound HTTP or TCP traffic during the current beta.
- Continuous process lifetime does not make a job durable. Store progress and make interrupted jobs safe to retry.
- Check fixed capacity, production-only deployment and storage requirements before choosing the beta.
What the public beta adds
The launch announcement describes containerized processes that run in the same Vercel project as the application. Examples include queue consumers, Temporal workers and self-hosted CI runners. Vercel builds the container and maintains the configured instance count in each region, restarting instances that exit or crash.
That makes an existing polling worker a more natural candidate than code that must accept a browser request. Start by describing how work reaches your process. If the first step is listening on a public port, a daemon does not match that entry point.
Choose the execution model before the host
In the example product, an account owner asks for an export of approved documents. The web request authenticates the owner, validates the scope, records the request and returns a status location. A worker later renders the export, stores it and records completion. Separating these responsibilities gives the customer a stable way to check progress without holding the original request open.
Choose the worker host after defining the job contract. The table compares the responsibilities of each component rather than treating every background action as a reason to run a permanent process.
| Responsibility | Candidate | Decision test |
|---|---|---|
| Accept an export request | HTTP application or Function | Needs authentication and an immediate response |
| Continuously consume the export queue | Daemon or another queue-worker host | Already owns a persistent polling loop |
| Run a scheduled housekeeping check | Scheduled execution | Work starts on a schedule rather than a continuous consumer |
| Coordinate several resumable steps | Durable workflow engine plus its execution runtime | Needs persisted step state and recovery semantics |
| Retain completed files and job state | Durable object storage and database | Must survive worker replacement |
Treat beta limits as architecture inputs
As checked on October 16, the Daemons overview says instances cannot receive inbound traffic. The current beta also lacks preview deployments, autoscaling and persistent local storage; vercel dev does not run daemons. These boundaries affect how you test, scale and recover the service.
Use a locally run container and a separate test queue for integration work. Prevent test credentials or consumers from reaching production jobs. Define the database and storage locations explicitly instead of relying on files surviving inside a container. Choose regions by the location of dependencies and users, then measure the actual workflow rather than assuming a US region alone makes every operation fast.
Keep configuration and deployment ownership clear. A worker rollout can overlap old and new consumers, so job payloads need a deliberate compatibility policy. A field added by the new web release should not make an older running consumer corrupt a job.
Does your worker recover the business job?
Bring the queue, worker and failure cases. We can help compare runtimes and define a recoverable processing path.
Prove recovery with a crash-after-upload test
Give each export request a stable job ID and store its allowed account, input version and destination. Use that identity when recording progress and producing the output. A retry should find the same logical job instead of creating another customer-visible export every time the process restarts.
In an approved test environment, stop the worker after it uploads the file but before it acknowledges completion. Start another consumer and observe what happens when the message returns. The expected behavior is a single usable export and a correct completion record, with any incomplete artifact cleaned up or replaced according to policy.
This exercise exposes a common gap: restarting the process is different from recovering the business operation. Design acknowledgement, retry limits, failure review and duplicate detection together. If an external service cannot support a repeatable operation, document how your team detects and resolves an uncertain result.
- Stop accepting new jobs during shutdown and preserve the status of work already claimed.
- Keep retries bounded and send repeatedly failing jobs to a reviewable failure state.
- Record job age, attempt count and completion evidence without logging document contents or secrets.
Budget for the worker that stays running
Check the current plan quota before treating beta availability as an operating budget. The limits page lists a Hobby allowance of 10 vCPU-hours per month, counted while instances run. It explains that one 1-vCPU instance uses that allowance in about 10 hours and that instances stop when the allowance is reached. That is a trial constraint, not a month of continuous worker capacity.
For a production proposal, list instance size and count, required running hours, queue and database services, object storage, network use and monitoring. Add a capacity test that measures arrival rate, processing time and backlog age under representative work. A worker can remain alive while customers wait too long for their results.
Ask who changes capacity when demand rises, what happens when a dependency is down and how customers see delayed work. Fixed capacity can be a reasonable choice when someone owns it; an undocumented expectation of automatic scaling is a release risk.
Vercel: beta quotas, instance limits and unsupported features
Make a bounded adoption decision
A sensible first candidate is one existing worker with a known queue, durable state and a clear output. Agree on the trial's success conditions: correct results, safe interruption, visible backlog, controlled credentials and an operating estimate based on observed use. Retain a way to run the same job contract on the current host during evaluation.
Before switching consumers, decide how to prevent both environments from accidentally duplicating side effects. Record the queue ownership change and validate pending work. If the beta's preview, capacity or storage constraints conflict with a requirement you cannot relax, keep that workload on a suitable alternative and revisit when the platform changes.
The handoff should let another engineer answer where a job lives, who can retry it and what proves it finished. That operational clarity is the strongest reason to restructure background work, whichever runtime ultimately hosts it.
Frequently asked questions
Can Vercel Daemons replace an HTTP API?
The public beta does not accept inbound HTTP or TCP traffic. Use an appropriate HTTP-serving runtime for requests and a daemon for work it pulls from a queue, workflow engine or external system.
Do Daemons guarantee a job runs exactly once?
Process restart is not a guarantee about business side effects. Design a stable job identity, durable state, safe retries and reconciliation for uncertain outcomes.
Can I test a daemon in a Vercel preview deployment?
The October 16 documentation says preview deployments are unsupported during the beta. Test the container with isolated dependencies locally and plan production adoption explicitly.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.