CapRover 咨询服务
CapRover 是一套自建 PaaS：你出机器，它出「Heroku 那一层」—— Web 面板、官方 CLI、Nginx 反代、Let's Encrypt 自动 HTTPS，以及 100+ 一键应用。我们帮助独立开发者和小团队，把一台空白 VPS 收成可以长期自己跑的生产平台。
这不是 Kubernetes 项目。如果你已经需要多可用区弹性伸缩、完整 RBAC，或把 Docker Compose 当一等公民，我们会在第一次沟通里直接劝退，并帮你判断该换哪条赛道。
和官方支持的关系
CapRover 自己的 Help and Support 把帮助分成三条路。我们走的是第三条：
我们不是 CapRover 项目组，也不代售官方 Pro 许可证。产品缺陷仍然应该开在 GitHub 上。
服务对象
- 独立开发者、小团队：侧项目、内部工具、内容站要放在自己的 VPS 上
- 成长型企业：希望有 Heroku 式上线体验，数据和账单留在自己控制的机器里
- 栈比较复杂、或有一批应用要整体迁到 CapRover 的团队
- 已经装过 CapRover，但卡在 HTTPS、自动部署、磁盘、备份，或面板已经打不开的团队
- 机器到不了 Docker Hub、GitHub 或官方一键应用目录的团队
服务周期
- 按小时咨询（共享屏幕、单次事故、方案评审）：按小时计费
- 仅做选型评估（CapRover / Coolify / Dokploy / 1Panel / Kubernetes）：1–2 天
- 故障救援：1–3 天
- 单个模块：3–7 天
- 完整落地（安装 → 应用 → CI → 备份 → 加固）：2–4 周
服务内容
1. 按小时咨询
官方支持页把第三方「Hourly Consultation」单独列出来。适合还不到一个项目的体量：一次发不绿的部署、买机器之前先审方案、或对着面板结对点一遍。
结束后你会拿到一份书面记录：改了什么、排除了什么、下一步可以安全执行的命令——不是一段聊天记录。
2. 平台落地
常见翻车：:3000 打不开；国内机器拉 Docker Hub 超时；泛解析没配好，后面每个应用都签不出证；面板还停在默认密码；域名未备案，或 Cloudflare 橙色云挡住 Let's Encrypt 的 HTTP-01。
我们先选路（国内轻量云还是海外 VPS），按官方方式装 Docker、加 swap、配镜像加速，绑好根域，Enforce HTTPS，关掉安装口，并按需做成隐藏根域，避免面板被扫到。
3. 应用上架与存量迁移
这就是官方第三方列表里写的那件事：栈比较复杂，或有一批应用，要迁到 CapRover。
常见翻车：一键应用没挂持久化目录，重启后数据全没；WordPress / n8n / MinIO 拆成两个 App，数据库主机名抄错；同一台机器上又跑了 docker compose up，两套编排抢端口；Compose 原样贴进去，一半字段被静默丢掉。
每个应用统一走三件套——自定义域名、HTTPS、持久化目录；服务之间用 srv-captain-- 内网互访；把手里的 Compose / Heroku / 裸 Docker 收成 CapRover 应用和 TEMPLATE。
4. 持续交付与私有仓库
常见翻车：1G 机器在服务器上构建前端，直接 OOM Killed；GitHub Webhook 打不进国内 443；ghcr / ACR / Harbor 报 pull access denied；Image Prefix 大小写不对；只读仓还开着 Default Push；面板密码被写进 GitHub Secrets。
同一时期只走一条路：Gitee Webhook，或 GitHub / GitLab 构建再推、caprover deploy -i。按官方四元组登记私有仓，CI 改用 App Token，留下可重复执行的 captain-definition。
5. 生产加固
常见翻车：旧镜像或容器日志把盘写满；部署是绿的、页面是 502——Container Port 还是 80，进程却听在 3000，或应用绑了 127.0.0.1；MySQL 映射了公网端口；手改 Nginx 把面板改黑；没有健康检查，每次发布都闪断。
我们把日常规程装上：面板 Disk Cleanup、日志轮转、CPU / 内存限额、公网只留 80/443、数据库只走 overlay、过一遍安全清单（HTTPS、关掉 :3000、SSH 上 fail2ban、隐藏根域）。无状态应用补上健康检查、start-first 更新和失败自动回滚。
6. 备份、恢复与整机迁移
常见翻车：下了一份 backup.tar 就以为可以砸旧机器。内置备份仍是 experimental，只覆盖 /captain/data，镜像和持久化卷不在包里。先 docker run 再拷 tar，空实例不会再吃这份备份。库不在 1/1 时跑 volume prune，数据会没。
我们按 3-2-1 铺三层：配置 tar 定时进对象存储，库用 mysqldump / pg_dump / mongodump 每日导出，镜像放进第三方 Registry。然后在测试机演练一次换机：先准备空的 /captain → 放入 backup.tar → 再启动 CapRover → 改解析 → 拉镜像 → 灌回 dump。
7. 团队一键应用市场
常见翻车：每换一台机器就重新粘贴 TEMPLATE；公司内部栈、钉死的镜像标签、中文说明不该推进官方公共仓；Connect 填成了 git 地址而不是静态站点 origin；面板所在的国内机器打不开 GitHub Pages。
我们用仓库模板发布一份私有目录，把你们测通的 1–3 个栈收进去，连到现有 CapRover 实例；Pages 不合适时，把 dist/ 挂到面板能 GET 到的机器上。
8. 受限网络与隔离环境
官方 CapRover 默认要能访问公网：拉代码、拉镜像、健康检查、一键应用目录（GitHub、Docker Hub 等）。Netdata 这类插件、不少一键应用，也可能会打自己的后端。官方把「完全断网的 airtight」归为他们自己的 private support。
我们覆盖贴在旁边的那些情况：
- 到不了 Docker Hub / GitHub 的国内 VPS
- 只能从 Harbor / ACR 拉镜像的内网
- 自建一键应用目录，面板不必去拉官方市场
- 镜像包 + 私有仓，发版不再等公共 Hub
- 不能接受外联时，关掉或替换会打电话回家的组件
一台机器必须永远没有任何出站——没有镜像加速、没有私有仓、没有例外——那是官方 airtight。如果这才是你的真实约束，我们会在第一小时里告诉你。
流程
1. 初步调研
收到需求后，我们安排工作访谈：现有托管方式、为什么看 CapRover、国内 / 海外约束、谁来运维这台机器，以及怎样算做完。按小时的事故处理可以直接进入共享屏幕。
需要你提供的：
- 现有架构，或一台空白 VPS
- 域名和 DNS 权限
- 将会碰到的各系统对接人
2. 方案确认
我们写出机器路线、DNS 布局、应用清单、CI 路径、备份分层，以及明确的不做清单。例如：加第二台机器 不会 让 MySQL 变成高可用——有持久化的应用仍然钉在当初那块盘上。
需要你确认的：
- 方案和验收标准
3. 落地实施
按平台真实依赖顺序实施你购买的模块：先安装和 HTTPS，再上应用；先登记仓库，再接 CI；先有 dump，再做磁盘清理。
需要你提供的：
- 目标机器的 SSH 或云控制台
- 应用源码或镜像；私有仓还要凭据
4. 演练验收
只部署成功，不算交付。按范围演练其中一件：一次带 bug 的发布自动回滚、一次配置 + 数据恢复，或搬到第二台机器。
需要你提供的：
- 能点开应用做验收的业务人员
- 若搬正在跑的机器，需要一个维护窗口
5. 加固收口
关掉多余端口，写上日志和内存上限，确认数据库没有公网映射，对照安全清单把正在跑的这台收完。
6. 完成交付 & 培训
留下一份短 runbook——怎么发版、怎么看日志、怎么恢复——并培训实际操作的人。完整落地含 15 天答疑。
联系方式
写信到 hi@thematrixcrop.com。说明你要的是一小时事故处理、第一次安装、存量迁栈，还是生产加固。