Vercel Daemons 公测：无需 HTTP 服务器即可运行后台进程

Vercel 正在从单纯的 Web 应用托管平台向更通用的计算平台演进。最新进入公测的 Vercel Daemons，让开发者可以在 Vercel 上运行长时间运行的后台进程，而不再需要为每一个任务强行包装一个 HTTP 服务器。

什么是 Vercel Daemons

Daemons 允许你在 Vercel 上运行长期存活的进程，这些进程可以从 Vercel Queues、数据库或第三方系统中主动拉取并执行任务。与传统的 Serverless 函数不同，Daemons 不依赖入站 HTTP 请求来触发，而是以常驻容器的形态持续运行。

这类模式的典型应用场景包括：消费 Vercel Queues 轮询模式的客户端、Celery、BullMQ、RabbitMQ 或 Kafka 的消费者；Temporal 或 Cadence 的长轮询 worker；以及为 GitHub Actions、GitLab 或 CircleCI 提供自托管 CI runner——这些 runner 可以主动轮询作业，而不需要接受外部连接。

Serverless 函数是 Vercel 长期以来的核心执行模型：函数实例由 HTTP 请求或其他事件触发，启动后处理完当次调用即被冻结或回收，因此单次执行有超时上限（免费与 Pro 计划通常为数十秒到几分钟）。这种模型适合请求-响应型负载，却不适合需要持续监听队列、维持长连接或轮询远端作业的场景。Daemon（守护进程）则是 Unix 传统中的常驻后台进程概念，启动后长期存活、循环执行任务，不依附于任何一次用户请求。Vercel Daemons 把这套语义搬到了托管平台上：你声明实例数量和区域，平台负责拉起容器并保持其存活，进程自行决定何时从队列拉取下一条消息。理解这一区别的关键在于触发器——Serverless 由外部事件驱动，Daemon 则由进程内部的循环主动驱动。

底层机制：Fluid compute 上的容器

Daemons 运行在 Fluid compute 之上，以容器形式部署，并与你的应用处于同一个项目中。Vercel 负责构建镜像，并按你在各个区域配置的实例数量进行维护。如果实例退出或崩溃，平台会自动重启。

这种设计与 Vercel 一贯的“部署即基础设施”思路保持一致。你不需要单独管理一套 worker 集群，也不用为后台任务单独搭建一套部署流水线——Daemons 和应用共享同一个项目上下文，日志与指标也统一收敛到 Vercel 的控制台中。

Fluid compute 是 Vercel 此前推出的计算模型，它在传统 Serverless 的基础上引入了实例复用与并发处理能力，让同一份运行环境可以同时服务多个并发请求，从而降低冷启动频率与资源闲置。它的本质仍是按需伸缩的托管运行时，只是把“一请求一实例”的粒度放宽为“一实例多任务”。Daemons 建立在同一套运行时之上，但绕过了按需触发的调度逻辑：实例被持续保持运行，不进入空闲回收状态。这意味着 Daemons 的资源计费方式更接近常驻容器——按实例数与运行时长计算，而非按调用次数。对开发者来说，这既带来了长任务的可行性，也要求更仔细地评估实例数量与成本之间的平衡。

配置方式：一个 Dockerfile 加一段配置

入门流程相当直接。开发者需要先将应用及其依赖打包进 Dockerfile 或 Containerfile，然后在项目根目录的配置文件中添加一个 daemons 条目。

官方给出的示例是在 worker/Dockerfile 中运行一个 Celery worker，部署到 iad1（华盛顿特区）区域：

#:schema https://openapi.vercel.sh/vercel.json
[daemons.celery]
root = "worker/"
entrypoint = "Dockerfile"
command = ["celery", "-A", "app", "worker", "--loglevel=info"]
replicas.iad1 = 1

worker 所需的连接信息通过项目的生产环境变量注入，随后部署到生产环境即可。Vercel 会启动配置好的实例，输出会出现在项目的 Logs 中，CPU 和内存指标则可通过 Observability Plus 查看。

Celery 是 Python 生态中最广泛使用的分布式任务队列框架，通常由一个或多个 worker 进程连接消息代理（如 Redis 或 RabbitMQ），从队列中拉取任务并执行。与此同类的方案还有 Node.js 生态的 BullMQ（基于 Redis）、Python 的 RQ，以及跨语言的 Kafka 消费者组和 Temporal 工作流 worker。这些方案的共同点是：worker 必须作为长驻进程运行并主动拉取任务，而不是被动等待 HTTP 请求。正因如此，它们此前很难直接部署在纯 Serverless 平台上，往往需要单独的容器托管服务。Daemons 的配置示例中直接运行 Celery worker，说明 Vercel 现在能够承载这类标准的后台处理进程。

对平台与开发者的意义

Daemons 补上了 Vercel 在后台任务处理上的一个明显缺口。此前，想在 Vercel 上运行队列消费者或长轮询 worker，通常得借助外部服务或接受某种程度的架构妥协。

对于已经在使用 Vercel 的团队来说，这意味着一部分原本需要迁移到其他平台的工作负载，现在可以留在同一个项目里。尤其是那些已经采用 Celery、BullMQ、Kafka 等主流队列方案的团队，迁移成本主要集中在对容器化和配置文件的适配，而不需要重写任务逻辑。

另一边，Daemons 也把 Vercel 与那些以容器编排见长的平台拉近了距离。它是否适合承载核心业务的后台处理，仍取决于具体的可靠性要求和成本考量，但作为公测功能，它已经为 Vercel 的运行时版图增加了一块过去缺失的拼图。

更多细节可查阅 Vercel Daemons 官方文档。

自托管 CI runner 指团队在自己的基础设施上运行的持续集成执行器，而不是使用 GitHub、GitLab 或 CircleCI 提供的托管运行器。典型实现（如 GitHub Actions self-hosted runner）采用“轮询”模式：runner 主动向平台请求待执行的作业，执行完毕后再拉取下一个，整个过程不需要平台向 runner 发起入站连接。这种出站连接模式恰好适合部署在无法暴露公网端口、或希望控制计算成本与数据边界的网络环境中。Vercel Daemons 支持这一场景，意味着团队可以把 CI 执行器与业务应用放在同一个项目和计费体系下，避免额外维护一套独立的容器编排设施。