二进制安装
最适合单机测试、个人开发者或先验证产品能力的运维人员。
curl -fsSL https://raw.githubusercontent.com/miounet11/llmfit/main/install.sh | sh自托管
将运行时工具与品牌站点分开部署，会更稳妥。
运营 LLMFit 最清晰的方式，是把它拆成两个交付物来理解： 一部分是运行时工具（`llmfit`、`llmfit serve`），另一部分是静态品牌/文档站。 它们可以在同一台机器上，也可以完全分离。
源码构建
适合需要自定义修改、深度集成，或已经基于 Rust 工作流的团队。
git clone https://github.com/miounet11/llmfit.git
cd llmfit
cargo build --release节点侧 API 服务
在目标主机上运行 `llmfit serve`，让上层系统通过轮询节点获取适配分析，而不是重复实现逻辑。
llmfit serve --host 0.0.0.0 --port 8787完整本地栈
开发阶段可直接使用仓库内的 Compose 定义，同时启动 API 和静态站点。
docker compose up --build生产部署模式
站点应该走隔离发布路径。
更稳妥的上线方式，是在确认新域名映射、证书覆盖和健康检查全部正常之前， 不要让新站点直接干扰现有应用服务。
静态目录模式
把 `site/` 输出到独立的 Nginx 或 Caddy 文档根，让反向代理直接服务静态资源。
容器模式
先在未使用的内部端口启动独立静态容器，验证完成后再接入线上反向代理。
证书模式
对所有对外域名都单独确认 TLS 覆盖，包括 apex 和 `www` 两类主机名。
仓库管理的远程发布
scripts/deploy-site.sh user@host /opt/llmfit这个辅助脚本会在目标主机上克隆或更新仓库，并启动站点部署定义。
容器化站点发布
docker compose -f deploy/site.compose.yml up -d仓库内置的站点 compose 文件使用独立端口，方便在切流前先做隔离验证。
生产检查清单
域名切换前至少做到这些。
备份旧站点
- 保留当前 docroot
- 备份正在使用的虚拟主机配置
- 记录证书路径和已有 server_name
验证代理栈
- reload 前先执行 `nginx -t`
- 确认实际运行中的 nginx 二进制和配置路径
- 检查是否存在重复站点定义
验证主机路由
- DNS 切换前使用 `curl --resolve`
- 确认 `robots.txt` 与 sitemap 可访问
- 同时检查 apex 与 `www` 的跳转链路
切流后观察日志
- DNS 变更后立即跟踪访问日志和错误日志
- 确认所有公网主机名都被证书覆盖
- 保留回滚所需的配置与站点备份
下一步