部署到自己的服务器，意味着要把类似 SSH 的访问权限交给一个代理，这台服务器是你付费购买的，上面可能还运行着其他东西。这与发布到免费子域名相比是完全不同的信任级别，设置流程也体现了这一点——几个字段，填一次，之后每次构建只需点一个按钮。以下是人们在配置前后实际会问的问题。
创建部署目标需要什么？
在设置 → 部署中，需要五项内容：
- 一个你以后能认出来的名称——"prod-vps"、"client-hostgator"，什么名字都行，只要你晚上11点在下拉菜单里还能记得住
- 主机地址和端口
- SFTP 凭据
- 网站根目录路径
不需要 API 令牌，不需要在服务器上安装命令行工具，也不需要维护定时任务。只要你的主机提供 SFTP 访问——这几乎涵盖了所有共享主机、所有 VPS、所有托管型 WordPress 主机——大约两分钟就能搞定。
用密码还是密钥？
如果你的主机支持，用密钥。密码也完全可用，我们会按账号范围安全存储，但密钥能少一个到处存放的秘密——如果以后出了问题，这就是"撤销一个密钥"和"到处重置一个可能被重复使用过的密码"之间的区别。很多廉价的共享主机 SFTP 设置只支持密码认证，这也没问题。只是不要在别处重复使用这个密码。
如何找到正确的网站根目录路径？
这是人们第一次最容易搞错的字段,因为错误答案看起来同样合理。它不是你的主目录,也不是 /var/www ——它就是你的 Web 服务器配置为对外提供服务的那个确切文件夹。
| 服务器 | 常见网站根目录 |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html ——或者三年前某个之前的开发者随手起的、如今没人记得原因的某个路径 |
如果不确定,用任意 SFTP 客户端在你认为正确的文件夹里放一个可丢弃的 test.txt 测试文件,然后检查它能否在 yoursite.com/test.txt上加载出来。如果这里搞错了,部署仍然会报告成功——智能体老老实实地把文件写进了错误的文件夹,而你只能盯着一个毫无变化的线上网站,纳闷为什么什么都没变。
一个部署目标能否覆盖多个域名？
可以，而且一旦你上手过第一个站点，这一点能真正节省时间。一个部署目标对应一台服务器和一组凭据——并不绑定于单个域名。在域名管理中，你可以把每个域名附加到某个部署目标上，并单独覆盖其网站根目录。用一台配置了 Nginx server block 的 VPS 运行三个站点？
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
一个部署目标，三次绑定。你不需要重复输入三次 SSH 密码，也不需要维护三个几乎一样、却会在你轮换密钥忘了其中一个时逐渐失步的部署目标。点击这三个域名中任意一个的部署按钮，它已经知道对应的服务器和文件夹——部署时无需再做选择。
代理连接后实际会做什么？
首先，它会先察看情况——只读，不会写入任何内容。这次检查主要核实以下几点：
- 一个空文件夹
- 此构建的一个先前版本
- 一个旧的 WordPress 安装
- 主机默认放置的“即将上线”占位页面
这决定了发布策略。空的网站根目录会直接上传;已经存在内容的网站根目录则会被更谨慎地处理,因为很多真实环境中,网站旁边往往存放着不该消失的内容:
- A
.well-known用于 SSL 验证的文件夹 - 一个
uploads没人加入 git 的目录 - A
wp-config.php没人希望被动到的
这里的工作更像是“弄清楚发生了什么变化并加以协调”,而不是“清空并替换”。
然后,在任何一个字节被覆盖之前,现有的网站根目录会被作为一个版本捕获并保存在你自己的主机上。这不是数据库记录,也不是我们计算出来、寄希望于准确的差异对比——而是当时实际存在内容的真实快照。这一点在首次向任何目标进行发布时最为重要,因为那次发布总是会覆盖在某些内容之上,即便那“某些内容”其实什么都没有。空文件夹,对应空快照。一个没人记得是怎么搭建的、已经五年之久的静态网站——在被改动之前,原封不动地免费保留下来。而首次发布恰恰也是你最没把握的一次,所以这一点在此时格外重要。
它上传的是我的源代码,还是构建好的网站?
永远是构建产物,而非源代码。对静态网站来说,就是生成好的页面。对于框架构建——Next.js、Vite,或该站点类型所需的任何工具——是编译输出,即 dist 或 build 文件夹,绝不是源码树。我认为这个判断是对的,即便这意味着你无法 SSH 登录服务器,对服务器上的内容运行 npm run dev 命令。上传源码意味着你的生产环境网站根目录需要一个 Node 运行时和一整套构建工具链才能提供 HTML 服务——把一台从未打算运行构建流水线的共享主机变成了一台需要运行的机器,还让每一次部署都变成"祈祷服务器有足够内存跑完 npm install"。只发布编译产物,让网站根目录保持静态文件服务器所期望的样子。枯燥。而枯燥正是凌晨两点出问题、你盯着那个文件夹想搞清楚到底在提供什么服务时,你最想要的东西。
我怎么知道发布是否真的成功了?
上传完成后,智能体会访问线上 URL 检查是否能正常解析——不是 500 错误,也不是空白页。无论它发现了什么,再加上它在检查过程中注意到、希望你确认的任何情况("这个网站根目录里有一个 wp-content 文件夹,我没有动它,请确认这符合预期"),都会出现在该构建的聊天线程里。这是整个平台的一贯模式:没有静默的成功,也没有静默地失败为一张支持工单。智能体会在你请求构建的同一线程里,告诉你它看到了什么、又做了什么决定。
版本历史中到底保存了什么?
每一次发布都会新增一个版本——不仅仅是第一次。因此,版本历史并不是把你的构建绘制在一条抽象的时间线上;而是从那个网站根目录实际提供服务的内容按顺序记录下来的真实序列,从你出现之前存在的内容开始。第一个版本永远是那个平台接入前的状态,会被自动捕获。你完全不需要为此操心。
回滚实际恢复的是什么?
是之前正式上线的版本,精确到每个文件——不是重新运行一次旧的构建,也不是近似还原。是那些真正在为流量提供服务的实际文件。这是一个比大多数我用过的"回滚"功能更强的保证,那些功能通常意味着"从旧提交重新部署",并默默假设你的构建过程是确定性的,而且环境从那以后没有发生漂移。这里的回滚是恢复一个已知良好的快照,这就是为什么在压力之下使用它是安全的——你不需要去思考回滚的结果是否会与它要回滚到的目标行为不一致。
而你真正需要它的那一刻从来都不是平静的时刻;通常是"新构建把结账流程搞坏了,而流量现在正实时涌入"。
点一下,恢复到上一个版本,完成。把这当作核心功能而不是事后补充来对待的理由,写在《无畏迭代》里——值得在你真正用到它之前读一遍。历史记录和恢复控件都位于构建卡片和目标自身的历史视图中。
这会同时备份我的数据库吗?
不会,与其让人误以为如此,我宁愿直说清楚。主机上的版本历史涵盖的是这条部署流水线写入网站根目录的内容。如果你的网站有数据库,或者用户上传内容,或者任何在部署之外发生变化的东西,那完全是另一个问题——回滚不会碰这些内容,也不应该被误认为一种能覆盖它们的备份策略。
