一个 Project、两个 Service：Zeabur 双环境部署的省钱做法

2026-09-02 · 部署运维

个人项目最容易纠结的一件事：开发环境到底要不要单独部署一套？

用本地服务当然可以，但有几个场景绕不开线上环境——真机测试要连公网地址、 App 的构建产物没法改 API 地址、想做灰度或者验证线上配置差异。而一旦决定「开发环境也要在线」，直觉做法就是再开一个项目，成本立刻翻倍。

这篇记录一个把成本压到接近单机的做法。

一、先看清成本是怎么来的

最开始我的理解是「两套环境 = 两个部署 = 两份钱」。但这个等式其实只在「每个环境独占一台机器」的前提下成立。

Zeabur 的一个 Project 里可以放多个 Service，而这些 Service 共享同一份计算资源。也就是说，两个环境的服务可以跑在同一个资源池里，按一份资源计费。

二、最终架构

GitHub 仓库
├── main 分支 ──────→ Service: api-prod   ─┐
└── development 分支 → Service: api-dev    ─┴─ 共享一份计算资源
                                              │
                          ┌───────────────────┴───────────────────┐
                          │                                       │
                    PostgreSQL (prod)                     PostgreSQL (dev)

要点三个：

两个 Service，两个分支。 api-prod 跟踪 main，api-dev 跟踪 development。往哪个分支推代码，就自动部署哪个环境，互不干扰。
两套数据库。 环境隔离的关键其实在数据上，不在计算上。两个 Service 各自连自己的库，开发时随便造数据都不会污染生产。
一份计算资源。 上海 2 vCPU / 4 GB 的规格，两个服务分着用，个人项目的访问量完全够。

三、顺带解决的三个问题

1. iOS 的 ATS 例外不用配了

平台会自动给服务分配 HTTPS 域名。iOS 的 App Transport Security 默认只信任合规的 HTTPS，用平台域名就天然满足，真机调试不用往 Info.plist 里加任何例外规则—— 这一点比自建 HTTP 服务省心很多。

2. 国内访问

我用的是 Zeabur 的国内版并选了大陆地域。这个选择在部署时看着没差别，但后面走备案流程时才体会到必要性——服务器在境内，备案才有得办。

3. 本地开发连云端开发库

本地起服务时直接把连接串指向开发库。好处是本地看到的和线上开发环境是同一份数据，调试「线上才有」的问题时不用靠猜。

四、踩到的两个坑

坑一：数据库默认不一定能从公网连

托管数据库出于安全考虑，默认往往只允许内网访问。而「本地连开发库」这个需求恰恰要求公网可达。解决办法是在数据库控制台开启公网访问、拿到对外的连接串。

这是整个方案能否本地联调的前提，建议一开始就确认，不要等到本地跑起来连不上才回头找。

坑二：备案期间域名会被阻断

如果打算用自定义域名，在域名备案通过之前，境内云厂商会拦截该域名的访问。这个阶段要么先用平台分配的默认域名联调，要么用厂商提供的「备案前可用」的临时子域名。别以为是自己 DNS 配错了，花了半天去查解析。

五、几句提醒

环境隔离的重点是数据，不是机器。 两个环境共用计算资源没问题，但数据库一定要分开—— 这是这套省钱方案能成立的前提。
分支策略要和部署绑定。 让 main 永远等于生产，是最省心的约定。需要热修时也走分支，不要直接改线上。
备案相关的事早点确认。 服务器地域、域名解析、资源续费时长，这些都会影响后面的备案流程，选错了要回头改的成本比一开始问清楚高得多。

整体下来，双环境的成本基本等于一台机器。对个人项目来说，这个投入换来的「随时有一个跟生产一致的验证环境」是划算的。