如何使用 OpenNext 在 Vercel 之外部署 Next.js
Vercel 是部署 Next.js 阻力最小的路径——但它并非唯一的选择。无论你是在优化成本、在已有的云基础设施中工作,还是需要对运行时环境有更多控制,在 Vercel 之外部署 Next.js 在 2026 年都是一个得到充分支持的选项。
本文将介绍主要的几种方式:原生自托管,以及通过 OpenNext 使用平台适配器。
关键要点
- Next.js 支持多种自托管方式——Node.js 服务器、Docker 容器和 standalone 输出——让你无需任何适配器即可获得完全控制权。
- OpenNext 将 Next.js 的构建输出适配到 serverless 和边缘平台,对 AWS Lambda 和 Cloudflare Workers 提供了强力支持。
- Next.js 16.2 中引入的 Deployment Adapter API 提供了一个稳定、带版本控制的契约,适配器可以直接消费。
- 对于基于容器的团队,选择自托管;对于 serverless 规模化场景,选择 OpenNext + AWS;对于边缘优先、低延迟交付,选择 OpenNext + Cloudflare。
你并非总是需要适配器
在动用 OpenNext 之前,值得先了解 Next.js 开箱即用支持哪些方式。
Next.js 官方支持通过 Node.js 服务器、Docker 容器或静态导出进行自托管,其中 standalone 输出常用于优化容器部署,具体可参见自托管指南。
- Node.js 服务器 — 在 Nginx 等反向代理后运行
next start - Docker 容器 — 使用 Dockerfile 打包应用,并部署到任意容器平台(ECS、Cloud Run、Fly.io)
- Standalone 输出 — 仅打包必要内容的最小构建产物,非常适合容器场景
这些方式给你完全的控制权,并且对已经运行容器化工作负载的团队来说非常合适。代价是你需要自行负责扩缩容、跨实例的缓存协调以及 CDN 配置。
如果你需要让 ISR、按需重新验证(on-demand revalidation)或流式渲染在多个实例间正确工作,这些功能性需求需要被显式地配置好——它们在托管平台之外并非免费提供。
OpenNext 增加了什么
OpenNext 是一个开源项目,负责将 Next.js 的构建输出适配到 serverless 和边缘平台。它于 2023 年作为 SST 社区的 AWS Lambda 适配器诞生,此后已扩展到 Cloudflare 和 Netlify。
其核心思路是:Next.js 生成结构化的构建输出,而 OpenNext 将该输出映射到每个平台的原语之上——Lambda 函数、Workers、CDN 规则和缓存层。
Deployment Adapter API(Next.js 16.2+)
OpenNext 的工作直接推动了一次重大的生态转变。在与 Vercel、Cloudflare、Netlify、AWS Amplify 和 Google Cloud 的协作下,社区在 Next.js 16.2 中确立了一个稳定的 Deployment Adapter API。
此前,各平台不得不对 Next.js 构建输出进行逆向工程——这是一个脆弱的过程,每次发布都可能失效。如今,Next.js 会输出一份带类型、带版本的应用描述:路由、静态资源、缓存规则和运行时目标。适配器可以直接消费这份契约。
正如 Netlify 的 Philippe Serhal 所言:“我们 90% 问题的共同根源,就是缺乏一个有文档、稳定的机制来配置和读取构建输出。” 这一问题如今已在上游得到解决。
Vercel 自己的适配器也使用这同一份公开契约——不存在私有钩子。
Discover how at OpenReplay.com.
使用 OpenNext 部署到 AWS 和 Cloudflare
Next.js 的 AWS 部署
由 SST 社区维护的 OpenNext AWS 适配器将你的 Next.js 应用映射到 Lambda 函数,并通过 CloudFront 提供 CDN、S3 提供静态资源。它会处理 ISR 重新验证以及跨 serverless 实例的缓存同步——这些恰恰是手动配置真正棘手的部分。
Next.js 的 Cloudflare Workers 部署
由 Cloudflare 团队维护的 Cloudflare 适配器会将你的应用转换为兼容 Cloudflare Workers 的格式。对于新建或现有应用,推荐的方式通常是使用适配器工具初始化或迁移项目,详见 Cloudflare 适配器文档。
一个重要提示:构建转换需要一定时间,因此该适配器并不适合日常开发迭代——开发时请使用 next dev,在准备部署时再进行构建。
选择合适的方式
| 方式 | 最适合的场景 |
|---|---|
next start / Docker | 已有容器基础设施,需要完全控制 |
| OpenNext + AWS | Serverless 规模化,Lambda 原生团队 |
| OpenNext + Cloudflare Workers | 边缘优先,全球低延迟 |
新的 Adapter API 意味着各适配器正在汇聚到一个共享的兼容性层和测试套件之上,这在评估流式 SSR 或部分预渲染(Partial Prerendering)等特性的支持时,能在各平台间提供更一致的表现。
结论
在 Vercel 之外部署 Next.js 不再是一种变通方案——它已是一等公民选项。原生自托管能够覆盖直接的使用场景。对于 serverless 和边缘部署,OpenNext 在 AWS 和 Cloudflare 上提供了强健的适配器,如今基于稳定且官方支持的 API 构建。选择适合你基础设施的方式,而不是设置成本最低的那一个。
常见问题
不会。借助 OpenNext 的 AWS 和 Cloudflare 适配器,ISR、按需重新验证和流式 SSR 等特性在生产环境中都得到支持。Next.js 16.2 中的 Deployment Adapter API 通过共享的测试套件帮助适配器保持兼容性,因此特性对等程度比以往更接近了。
当你的团队已经在 ECS、Cloud Run 或 Fly.io 等平台上运行容器化工作负载,并希望对运行时拥有完全控制时,选择 Docker 或 next start。当你希望在 AWS Lambda 上获得 serverless 扩缩容,或通过 Cloudflare Workers 实现边缘交付,而又不想自行管理基础设施时,OpenNext 更合适。
由 SST 社区维护的 AWS 适配器自 2023 年起便已用于生产,Cloudflare 适配器则由 Cloudflare 团队积极维护。自 Next.js 16.2 起,两者都构建在官方 Deployment Adapter API 之上,提供了稳定的契约,而不再依赖逆向工程的构建输出。
日常开发请使用 next dev,因为它能提供快速的热重载。Cloudflare 的构建转换耗时较长,适用于预览或部署,而非主动迭代。推荐流程是:使用 next dev 进行开发,然后在部署前使用适配器工具进行构建和预览。
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.
