后端回来了：Vercel 支持直接运行 Dockerfile

你是否也想过用部署前端的丝滑体验来部署后端 Docker 服务？Vercel 近日正式支持直接运行 Dockerfile！本文我们将深入解析这一重磅更新、适用场景以及 Fluid Compute 底层机制。

北京时间 2026 年 7 月 1 日， Vercel 在官网宣布正式支持通过 Dockerfile 部署应用，并在文章结尾喊出了 Backends are back。开发者现在可以在项目中添加 Dockerfile.vercel，让 Vercel 自动完成镜像构建、镜像存储和部署，并将应用运行在 Fluid Compute 之上。

这项更新意味着，Vercel 不再只是一个更适合 Next.js、前端应用和 Serverless Functions 的平台，而是进一步向自定义后端服务 and 通用 Web 应用运行平台扩展。

注意事项

这并不等于 Vercel 可以运行任何 Docker 应用。更准确地说，Vercel 支持的是通过 Dockerfile 描述构建过程、并以 HTTP 服务形式运行的无状态应用。

应用需要监听平台注入的端口，并把数据库、文件、缓存等持久化状态交给外部服务处理。

Vercel Support Dockerfile

什么是 Dockerfile？

Dockerfile 是一个用来描述“如何构建 Docker 镜像”的文本文件。

它通常会写明应用基于什么系统或运行时镜像、需要安装哪些依赖、复制哪些代码、执行什么构建命令，以及容器启动时应该运行什么程序。简单来说，Dockerfile 不是应用本身，而是应用运行环境的说明书。

例如，一个 Node.js Web 服务的 Dockerfile 可能长这样：

FROM node:22-alpine

WORKDIR /app

COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile

COPY . .
RUN pnpm build

CMD ["pnpm", "start"]

这个文件表达的意思是：使用 Node.js 22 作为基础环境，安装依赖，复制项目代码，执行构建，最后启动应用。

对于开发者来说，Dockerfile 最大的价值是“可复现”。只要 Dockerfile 写得清楚，无论是在本地、CI、云平台还是其他服务器上，都可以构建出相对一致的运行环境。

这也是 Vercel 支持 Dockerfile 的意义：当平台无法通过框架自动识别一个项目应该如何构建和运行时，开发者可以直接用 Dockerfile 明确告诉 Vercel。

Dockerfile 和 docker-compose.yaml 有什么区别？

很多人会把 Dockerfile 和 docker-compose.yaml 混在一起，但它们其实解决的是两个不同层级的问题。

Dockerfile 负责“构建一个镜像”，而 docker-compose.yaml 负责“编排多个容器”。

举个例子，一个 Web 应用可能需要：

一个 Next.js 前端；
一个 Express API；
一个 PostgreSQL 数据库；
一个 Redis 缓存；
一个 MinIO 对象存储。

其中，Express API 自己可以有一个 Dockerfile，用来描述 API 镜像怎么构建。而 docker-compose.yaml 则负责把 API、数据库、Redis、MinIO 这些服务一起启动，并配置端口、环境变量、数据卷和服务之间的网络关系。

简单对比如下：

项目	Dockerfile	docker-compose.yaml
主要作用	构建单个镜像	启动和编排多个容器
关注重点	应用如何打包、安装依赖、启动	多个服务如何协作
常见内容	FROM、RUN、COPY、CMD	services、ports、volumes、networks
适合场景	定义一个应用的运行环境	本地开发、多容器部署、服务编排
是否包含数据库编排	通常不包含	可以包含 PostgreSQL、Redis 等
Vercel 此次支持重点	是	不是传统 Compose 部署

核心差异

Vercel 这次支持的是 Dockerfile，而不是把 Vercel 变成一台可以直接运行完整 docker compose up -d 的 VPS。

你可以把一个 HTTP 服务通过 Dockerfile 部署到 Vercel，但不能直接把一整套包含数据库、Redis、后台 worker、对象存储、管理面板的 Compose 栈原样搬到 Vercel 上运行。

Vercel 支持的是什么类型的 Docker 应用？

Vercel 官方文档中，后端框架如 Express、Fastify 等会作为 Vercel Function 运行，并默认使用 Fluid Compute；Fluid Compute 可以让应用根据流量自动伸缩，并支持更高效的并发处理。

从使用模型看，适合部署到 Vercel 的 Dockerfile 应用通常具备几个特征：

是 Web 服务或 API 服务；
通过 HTTP 对外提供能力；
能监听平台提供的端口；
本身无状态；
数据库存储、文件上传、缓存、队列等依赖外部托管服务。

下面我们通过 Tab 栏来看看适合与不适合部署到 Vercel 的应用类型对比：

应用类型	示例
Web 后端 API	Express、Hono、Fastify、FastAPI、Go HTTP Server
全栈 Web 应用	Next.js、Nuxt、SvelteKit、TanStack Start
内容网站	博客、文档站、企业官网、CMS 前台
Bot / Webhook 服务	Slack Bot、GitHub Webhook、MCP Server
AI 工具后端	Chatbot API、Agent 控制层、图片处理入口
轻量内部工具	Dashboard、Admin Panel、数据查询面板

应用类型	原因
PostgreSQL、MySQL、Redis	需要长期持久化状态和磁盘
1Panel、宝塔、CasaOS	依赖完整服务器环境和系统级能力
Docker Compose 多容器栈	Vercel 不是传统容器编排平台
BT 下载器、网盘服务	通常需要长时间运行和本地持久化
游戏服务器、VPN、代理服务	不属于普通 HTTP Web 应用模型
强依赖本地磁盘的应用	容器实例应视为无状态

换句话说，Vercel 支持 Dockerfile 后，部署范围确实扩大了，但它依然不是 VPS，也不是 Kubernetes 的替代品。

从 Vercel Templates 看适合的应用场景

从 Vercel Templates 页面也可以看出，Vercel 目前重点覆盖的仍然是 Web 应用、后端 API、AI 应用和全栈项目，而不是传统意义上的服务器软件。Vercel 的 Backend Templates 中已经包含 Hono、Express、Elysia、MCP Server、Slack Bolt 等模板，这些都属于轻量 HTTP 服务、Bot 后端、Webhook 服务或 AI 工具后端。

Starter Templates 中也可以看到 Next.js、Nuxt、SvelteKit、Rust Hello World、Rust Axum、TanStack Start、Slack Bolt with Hono 等模板。这说明 Vercel 希望覆盖的不只是前端页面，也包括通过 HTTP 暴露能力的后端程序。

Payload Website Starter 是另一个很典型的例子。这个模板包含后台管理、认证、内容发布、草稿预览、SEO、搜索、重定向、定时发布等功能，但它会配合 Neon Database 和 Vercel Blob Storage 等外部服务处理数据库和文件存储。

这其实体现了 Vercel 的推荐架构：计算放在 Vercel，状态放在外部托管服务。

为什么这次更新重要？

过去，Vercel 的最佳体验主要集中在 Next.js 和前端生态。虽然 Vercel 也支持多种 Serverless Functions 和后端框架，但如果项目需要特殊系统依赖、自定义启动命令、非标准框架、FFmpeg、Chromium、nginx 或其他复杂运行环境，就可能需要额外改造。

Dockerfile 支持补上了这块短板。

开发者不再必须完全适配 Vercel 的框架检测逻辑，而是可以用 Dockerfile 描述自己的应用如何构建、如何启动。对于传统后端项目、跨语言服务、AI 工具后端 and 自定义 Web Server 来说，这会明显降低迁移成本。

同时，部署到 Vercel 后，应用仍然可以获得 Vercel 原有的工程体验，例如 Git 集成、Preview Deployment、自动伸缩、日志、指标、回滚和平台级安全能力。Vercel 的 Functions 文档也强调，平台会根据框架自动设置构建和优化，并通过 CDN 与函数运行环境提供低运维体验。

Fluid Compute：介于 Serverless 和服务器之间

Vercel 这次 Dockerfile 支持的底层重点之一，是 Fluid Compute。

根据 Vercel 文档，Fluid Compute 是一种介于传统 Serverless 和服务器之间的计算模型。它保留了 Serverless 的自动伸缩和低运维优势，同时加入了类似服务器的能力，例如同一个实例可以并发处理多个请求。

对于 AI 应用、API 服务和 I/O 密集型任务来说，这一点很重要。很多请求的大部分时间并不是 CPU 真正在计算，而是在等待数据库、向量数据库、外部 API 或模型服务返回结果。Fluid Compute 的并发模型可以让同一个实例更有效地处理这些等待时间。

Vercel 的 Fluid Compute 文档也提到，它支持 Node.js、Python、Edge、Bun、Rust 等运行时，并且适合需要优化并发和减少冷启动影响的场景。

计费方式：按实际资源使用付费

Vercel 在 Fluid Compute 的计费文档中使用 CPU 与内存维度计算资源消耗。例如，一个请求如果实例存活 10 秒，但实际活跃 CPU 时间只有 4 秒，费用会拆分为 CPU 使用和内存占用两部分计算。

这说明 Vercel 并不是按照传统 VPS 那样“买一台机器一直开着”来计费，而是更接近按请求、按资源消耗计费的云函数模型。

成本考量

对于低频访问、突发流量、I/O 等待较多的 Web 服务来说，这种模式可能更划算。但对于需要 24 小时高负载运行、持续占用 CPU 或内存的服务，传统 VPS、专用服务器或 Kubernetes 仍然可能更合适。

这不是 VPS，但让 Vercel 更像完整应用平台

Vercel 支持 Dockerfile 后，最容易产生的误解是：“是不是以后所有 Docker 应用都能放到 Vercel？”

答案是否定的。

它不能取代 VPS，也不能取代 Docker Compose 或 Kubernetes。它更适合部署单个 Web 服务、API 服务、全栈应用或 AI 工具后端，而不是运行一整套长期常驻、强依赖本地磁盘和系统权限的服务器环境。

但这次更新依然非常重要。因为它把 Vercel 的边界从“框架友好的前端和全栈应用”继续推向“更通用的 HTTP 后端服务”。

对于开发者来说，理想场景可能是：

前端页面部署在 Vercel；
后端 API 通过 Dockerfile 部署到 Vercel；
PostgreSQL 使用 Neon、Supabase 或其他托管数据库；
文件存储使用 Vercel Blob、S3 或 R2；
缓存和队列使用外部托管 Redis 或消息队列；
每次 Git push 自动生成 Preview 环境。

这是一种更现代的云应用部署方式：不再维护服务器本身，而是把应用拆成计算、数据库、对象存储、缓存和队列等托管组件。

结语

Vercel 支持 Dockerfile，并不是简单地“支持 Docker”这么一句话就能概括。

它真正改变的是：开发者可以用更标准、更通用的方式，把自定义 HTTP 服务部署到 Vercel。对于那些无法被框架自动识别、但本质上仍然是 Web 服务的项目，Dockerfile 提供了一条更直接的上云路径。

不过，Dockerfile on Vercel 不是 Docker Compose on Vercel，也不是 VPS on Vercel。

它适合的是无状态 HTTP 应用，而不是完整服务器环境。

如果说过去 Vercel 最擅长的是前端部署体验，那么这次 Dockerfile 支持，则让更多后端服务也能享受到类似的开发体验：一次提交、自动构建、自动预览、自动伸缩，并在同一个平台上完成发布。