如何导出并自托管 AI 搭建的应用

要自托管一个 AI 搭建的应用，先把代码导出来（下载或同步到你自己拥有的 GitHub 仓库），然后把应用的密钥重新配置为环境变量，迁移或重建它的数据库，最后部署到与应用类型相匹配的托管平台：纯前端用静态托管，任何包含后端的应用则使用能运行服务器或容器的平台。代码通常是最简单的部分，真正的工作在于数据、密钥，以及搭建工具在背后默默为你运行的那些服务。

为什么要导出

把代码带走有一些很好的理由，也有一些不那么好的理由。

好的理由：

• 所有权与保险。 在你自己的仓库中保留一份代码副本，即使搭建工具改变了定价、功能或条款，你也有所保障。
• 交接给开发者。 工程团队会希望代码位于 Git 中，并接入他们惯用的工具和审查流程。
• 特定需求。 数据驻留、指定的云服务商、公司的安全政策，或搭建工具不提供的基础设施。
• 规模或成本。 当规模大到自建基础设施确实划算时。

**不那么好的理由：**为了每月省下一小笔费用，就迁移一个只有几个用户的小应用。自托管会把工作转移到你身上：更新、备份、监控、安全补丁。这可能是正确的取舍，只是要清楚地知道自己在做这个决定。

一个明智的折中方案是：继续在现有平台上构建和托管，但**从一开始就同步到你自己的 GitHub 仓库。**这样你既获得了保险，又无需承担运维工作。如果你还不熟悉 Git，可以先阅读什么是 GitHub。

导出内容包含什么，不包含什么

在依赖导出内容之前，先打开看看。通常情况如下：

密钥被有意排除在外——你可能会通过邮件发送或提交的压缩包，绝不应包含有效密钥。依赖之所以被排除，是因为它们会根据锁文件重新构建。

第一步：导出代码

两种常见的途径：

• 下载压缩包：快速，适合一次性迁移或备份。
• 同步到 GitHub：更适合长期维护的项目，包含完整历史记录，可以轻松克隆到任何地方，而且大多数托管平台都会在每次推送时直接从 GitHub 仓库部署。

无论采用哪种方式，都要在电脑（或云端开发环境）上解压或克隆，并查找 README 文件。如果没有，在离开搭建平台之前，请让平台中的 AI 为你编写一份：

为在本平台之外运行此项目编写一份 README：所用技术栈、所需的运行时版本、安装和构建命令、启动命令和端口、代码读取的每个环境变量（只写名称和用途，不写值），以及如何运行数据库迁移。

这一条提示词能节省数小时，因为它会把那些隐含在设置中的部分明确写下来。

第二步：先在本地运行

在部署到任何地方之前，先证明应用能够独立运行：

1. 安装 README 中指定的运行时，如 Node.js、Python、Java 或 .NET，并使用匹配的版本。
2. 安装依赖（npm install、pnpm install、pip install -r requirements.txt 或等效命令）。
3. 创建本地 .env 文件，填入环境变量，并尽量使用测试密钥。不要把它提交到 Git。什么是环境变量和密钥对这一概念做了解释。
4. 连接数据库：本地 Postgres，或托管服务商提供的免费开发数据库。
5. 运行迁移，然后启动应用，点击主要流程进行测试。

在这里出现的任何问题，部署到托管平台后同样会出现，而且在自己的机器上调试要容易得多。常见的意外情况包括：硬编码的搭建平台预览地址、搭建平台自动注入但你漏掉的环境变量，或者只存在于该平台上的服务（如文件存储、图片缩放）。

第三步：迁移数据

如果应用有真实用户，数据比代码更重要。

• **导出数据库。**对于 Postgres，pg_dump 会生成一个文件，可以通过 pg_restore 或 psql 恢复到新数据库中。如果你没有直接访问权限，可以让搭建平台的 AI 执行导出，并解释它生成了什么。
• **迁移上传的文件。**如果用户上传过图片或文档，这些文件保存在与数据库分开的对象存储中。把它们复制到你的新存储中（例如兼容 S3 的存储桶），如果已保存的 URL 中包含旧主机地址，还需要更新这些 URL。
• **规划切换过程。**对于正在运行的应用，简单的做法是设置一个短暂的维护窗口：停止写入，进行最后一次导出，在新主机上恢复，切换 DNS，然后重新开放服务。先把每一步写下来。
• **在正式迁移前测试恢复。**先将数据恢复到一个临时数据库中进行测试。

如果你对 Postgres 不熟悉，可以参阅什么是 Postgres了解基础知识。

第四步：选择托管平台

托管平台应与应用的类型相匹配。以下名称是截至 2026 年 9 月各类别中知名服务商的示例，并非排名；请到其官网查看最新的功能和价格。

你还需要：

• **托管数据库。**许多应用托管平台提供 Postgres，Neon 或 Supabase 等专用服务也单独提供。使用托管数据库是值得的：备份和更新由别人负责。
• 对象存储，用于应用中的上传功能（如果有的话）。
• 邮件发送、支付和 AI 服务商——这些通常只需要在新主机上设置相同的 API 密钥即可。

客观地看待其中的取舍：平台托管（前四行）设置和维护更快捷，但你的掌控力较弱，费用可能会随流量增长。虚拟服务器在流量稳定时通常更便宜，而且完全由你掌控，但补丁、TLS、备份、监控和故障恢复都要由你自己负责。如果团队中没有人愿意承担这些工作，就选择平台托管。关于托管的基础知识，请参阅什么是网站托管。

第五步：部署并切换

1. 将代码仓库连接到托管平台，或推送容器镜像。
2. 在托管平台的控制台中设置环境变量——README 中列出的每一个变量都要填入真实的值。
3. 设置构建和启动命令以及端口。许多平台通过 PORT 环境变量传递端口；应用应当监听该端口，并监听所有网络接口（0.0.0.0），而不只是 localhost。
4. 在新数据库上运行迁移。
5. 在修改 DNS 之前，先通过托管平台提供的临时地址进行测试。
6. 更新指向旧地址的外部服务：支付 Webhook、登录所用的 OAuth 回调地址、邮件中的链接、允许的来源。
7. 迁移域名：将 DNS 记录更新为新主机。如何连接自定义域名说明了这些记录的设置方法。
8. 短暂保留旧的部署，直到你确认一切正常，然后再下线。

第六步是最容易被忘记的：迁移后登录或支付悄无声息地失败，通常都是因为回调地址仍指向旧主机。

第六步：接管运维

一旦实现自托管，搭建平台原本处理的事务就都由你负责了。至少需要：经过恢复测试的自动数据库备份、错误追踪、可用性告警、依赖更新，以及记录每个账户的访问人员。如何把 AI 原型推进到生产环境对这份清单有更详细的说明。

导出检查清单

• 代码位于你自己拥有的仓库中，并有涵盖运行、构建和环境变量的 README
• 应用能从一个干净的克隆在本地运行
• 数据库已导出并测试过恢复；上传的文件已复制
• 已根据应用类型选定托管平台，并配备托管数据库和存储
• 新主机上所有环境变量都已填入真实的值
• Webhook、OAuth 重定向和邮件链接已更新
• DNS 已切换，旧部署短暂保留后已移除
• 备份、监控和访问名单已就位

从 Mythex 导出

在 Mythex 中，你所构建的代码归你所有。在 Pro 套餐中，你可以在 项目设置 → 导出 中将项目下载为压缩包，也可以连接 GitHub，与你自己的仓库进行推送和拉取；免费套餐只能以只读方式查看代码，无法导出或同步。导出内容不包含密钥和 node_modules，因此请在新主机上重新配置密钥。相关步骤可参阅导出并在其他地方运行以及GitHub、导出与导入。你也可以继续使用 Mythex 托管，把 GitHub 同步仅用作自己的代码副本和交接途径；如果你决定迁移，请在新主机上线后再下线 Mythex 上的应用。

常见问题