简体
RAILSHOT.
返回展厅

Railshot

AI deployment & operations platform

将在本机构建的 Web 应用部署到预先准备的云端与本地机房环境，并加以运维。

一个 AI 部署与运维平台：把在本机构建的 Web 应用部署到预先准备的云端或本地机房环境，并持续运行。

2026.09.28 — 2026.10.04 · 已结束

团队项目 · 我负责：CI 规划与实现、CSP 集群与 Ansible 接口、运维、团队代码审查与集成

SoftBank Hackathon 2026 powered by KOREC & Progate参加初赛 · 决赛入选名单预计 2026年10月26日公布（截至 2026年10月7日）

  • 网页已实现 · 黑客松
  • MCP 服务器已实现 · 远程 · 本地

Web 界面与自有智能体通过同一个产品 API 请求部署。

产品全程：从受理的部署请求出发，经 CI 检查与镜像发布，到已注册目标上的 Git 配置与 Argo CD 应用，以及公开 HTTPS 验证。只有同时具备已应用的 revision 和公开检查，才记录为成功；无法确知的结果保持为 unknown。

从 Web 界面，或从经 MCP 连接的自有 AI 智能体提交项目后，平台依次完成部署文件准备、失败修复、镜像发布、环境上线和公开 URL 验证；部署之后，同一界面显示历史与日志，并管理更新、停止、恢复和删除。团队项目。

赛事开发期 September 28, 2026 to October 4, 2026

黑客松期间构建的 Web 界面和 MCP 服务器。远程 MCP 通过 OAuth 登录后提交；本地文件夹经本地 MCP 提交。

产品架构 · 依据公开提交 645e28a 的代码路径绘制
Railshot 产品架构Railshot 产品的组件与连接。Web 界面、远程 OAuth MCP 和用户电脑上的本地 MCP 通过同一个产品 API 请求部署，API 登记源提交和 CI 运行。CI 以固定检查做出判定，并将检查过的镜像发布到 GHCR。只有当已注册目标与发布记录一致时，CD 适配器才通过 config Git 和 Argo CD 应用，随后检查已注册的公开 HTTPS 地址并记录结果。指标属于观测，与判定分开。浏览器用户文件夹 · ZIP · GitHub URLMCP 客户端ChatGPT · Codex · Clauderailshot-local MCP用户电脑 · stdioGHCR按 digest 指定的镜像AI SDK providerCodex · Claude SDKconfig Git 仓库已注册的 workload.json公开 HTTPS URL已注册的 health 路径Prometheus运维控制 VM · 读取apps/dashboardWeb 界面 · 历史 · Insightsagent/remote-mcp.jsOAuth MCP · deploy_repositoryapps/api校验 · 目标 · 202 受理部署队列 · 并发 3CI 运行绑定 · 观测cd.js · deployPublishedmetrics observerapi/product-store.jsoperation 状态 · run 绑定gitops/bridge.py可信 config · 已注册目标commit · push · 远程回读Argo sync · 观测公开 HTTPS 探针Argo CDApplication · AppProject 检查apps/<tenant>/<app>源提交 · trailerrailshot-deploy.yml循环 · 基线检查 L0–L3SDK 修复 · 仅限可修复的失败相同检查 → 已测试 bundlerelease · GHCR 发布 · 绑定K3s 应用集群workload · ServiceRailshot 平台运维集群 · AWSGitHub私有 apps 仓库 · Actions已注册目标按提供商的公开路径1 文件夹 · ZIP · GitHub URL · 浏览器用户 → Web 界面 · 历史 · Insights12同一产品 API · /api/v13 OAuth · deploy_repository · MCP 客户端 → OAuth MCP · deploy_repository34同一产品 API5 ZIP 上传 · deploy_local_project · railshot-local MCP → 校验 · 目标 · 202 受理56 记录为 queued · 202 · 校验 · 目标 · 202 受理 → operation 状态 · run 绑定67队列顺序8部署状态 · 历史1source commit2workflow_dispatch3提交的 commit4修复请求 · 有条件5发布已检查的镜像6运行 · 发布记录读取7 failed · publication_unverified · CI 运行绑定 · 观测 → operation 状态 · run 绑定71images.json · spec · verdict · manifest2应用 · 已注册目标3workload commit · push4revision5sync · 观测6应用7镜像 pull · digest8HTTPS health9 公开路径 · 公开 HTTPS URL → workload · Service910 succeeded · revision · URL · cd.js · deployPublished → operation 状态 · run 绑定1011 unknown · 需重新核对 · cd.js · deployPublished → operation 状态 · run 绑定111PromQL 查询2scrape · probe3部署状态 · 历史4HTTPS health

提交 → 受理

Web 界面、远程 MCP 和本地 MCP 调用同一个产品 API，API 将检查过的请求记录为 queued 并以 202 应答。

  1. 浏览器用户文件夹 · ZIP · GitHub URLWeb 界面 · 历史 · Insightsapps/dashboard

    在 Web 界面上选择源码与已注册环境。

  2. Web 界面 · 历史 · Insightsapps/dashboard同一产品 API · /api/v1校验 · 目标 · 202 受理apps/api

    Web 界面从同源调用产品 API。

  3. MCP 客户端OAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js

    远程 MCP 通过 OAuth 连接，以公开 GitHub 仓库作为输入。

  4. OAuth MCP · deploy_repositoryagent/remote-mcp.js同一产品 API校验 · 目标 · 202 受理apps/api

    远程 MCP 服务器通过内部 API 客户端调用同一部署 API。

  5. railshot-local MCPZIP 上传 · deploy_local_project校验 · 目标 · 202 受理apps/api

    用户电脑上的 stdio MCP 将文件夹打包为 ZIP 并上传。其会话不与远程 OAuth 会话共享。

  6. 校验 · 目标 · 202 受理apps/api记录为 queued · 202operation 状态 · run 绑定api/product-store.js

    检查输入、已注册目标、容量和幂等键后，将 operation 记录为 queued，并以 202 应答。202 表示已受理，而非已部署。

  7. operation 状态 · run 绑定api/product-store.js队列顺序部署队列 · 并发 3apps/api

    在并发部署上限（默认 3）内按受理顺序取出。

  8. operation 状态 · run 绑定api/product-store.js部署状态 · 历史Web 界面 · 历史 · Insightsapps/dashboard

    Web 界面和 MCP 工具读取同一份 operation 记录。最近一次尝试与当前已验证的部署分开显示，AI 任务完成并不等于部署成功。

CI 检查 → 镜像发布

固定的平台代码检查提交的 commit，只把可修复的失败交给 AI，并只发布再次通过同样检查的镜像。

  1. 部署队列 · 并发 3apps/apisource commit源提交 · trailerapps/<tenant>/<app>

    提交的源码在私有 apps 仓库中生成一个 commit（带 Railshot-Request 和 Railshot-Target trailer），分支以非 force 方式更新。

  2. 部署队列 · 并发 3apps/apiworkflow_dispatch循环 · 基线检查 L0–L3railshot-deploy.yml

    以 tenant、app、source_commit 和 target_id 请求一次运行。若响应丢失，不会重新发送，而是查找同一 commit 的运行。

  3. 源提交 · trailerapps/<tenant>/<app>提交的 commit循环 · 基线检查 L0–L3railshot-deploy.yml

    只检出提交的 commit 和固定的平台代码（PLATFORM_REF）。

  4. SDK 修复 · 仅限可修复的失败railshot-deploy.yml修复请求 · 有条件AI SDK provider

    仅在失败属于可修复类别时调用；同一失败重复出现或达到尝试上限时停止。通过与否由检查决定，而不是由 LLM 决定。

  5. release · GHCR 发布 · 绑定railshot-deploy.yml发布已检查的镜像GHCR

    核实通过检查的 bundle 后，将同样的镜像发布到 GHCR，不重新构建。

  6. CI 运行绑定 · 观测apps/api运行 · 发布记录读取railshot-deploy.yml

    只有 run id、源提交、目标和 app 与受理记录一致时，发布才被认可。

  7. CI 运行绑定 · 观测apps/apifailed · publication_unverifiedoperation 状态 · run 绑定api/product-store.js

    CI 失败或未经核实的发布连同诊断信息一起记录，不交给 CD。

应用 → 公开检查

仅当发布记录与已注册目标一致时，才通过 config Git 和 Argo CD 应用；只有在已注册的公开 HTTPS 地址检查通过后，才记录成功。

  1. release · GHCR 发布 · 绑定railshot-deploy.ymlimages.json · spec · verdict · manifestcd.js · deployPublishedapps/api

    CD 通过可信 loader 读取发布记录中的文件。CI 本身不创建集群资源或 URL，也不产生部署成功。

  2. cd.js · deployPublishedapps/api应用 · 已注册目标可信 config · 已注册目标gitops/bridge.py

    仅当已注册的 app 和 tenant 与发布记录一致时，才以可信 config 运行 gitops/bridge.py。

  3. commit · push · 远程回读gitops/bridge.pyworkload commit · pushconfig Git 仓库

    只将 workload.json 提交到专用分支的注册路径，先记录 push 意图，再 push，并读回远程 revision。结果不确定的 push 不会重复。

  4. config Git 仓库revisionApplication · AppProject 检查Argo CD

    Argo CD Application 指向的 config 仓库 revision。

  5. Argo sync · 观测gitops/bridge.pysync · 观测Application · AppProject 检查Argo CD

    检查 AppProject 后请求 sync；观测时只读取，不 sync。

  6. Application · AppProject 检查Argo CD应用workload · ServiceK3s 应用集群

    将 workload 应用到已注册的目标集群。

  7. workload · ServiceK3s 应用集群镜像 pull · digestGHCR

    拉取已发布的 digest。私有 GHCR 需要专用的 pull 凭据。

  8. 公开 HTTPS 探针gitops/bridge.pyHTTPS health公开 HTTPS URL

    只检查运维人员注册的 HTTPS health 地址，不跟随重定向，确认返回 200（如有设定，还需符合预期 JSON）。

  9. 公开 HTTPS URL公开路径workload · ServiceK3s 应用集群

    公开路径（LB、NodePort、证书）因提供商和已注册目标而异。

  10. cd.js · deployPublishedapps/apisucceeded · revision · URLoperation 状态 · run 绑定api/product-store.js

    只有同时具备 cd.deployed、revision、成功的公开 HTTPS 检查及其时间和有效 URL 时，才记录为 succeeded。

  11. cd.js · deployPublishedapps/apiunknown · 需重新核对operation 状态 · run 绑定api/product-store.js

    无法确知的结果保持为 unknown；同一应用操作既不重发，也不回滚。

观测 · 不作判定

指标与探针不决定部署是否成功。缺失、过期和采集失败的值按原样显示。

  1. metrics observerapps/apiPromQL 查询Prometheus

    读取 up、probe_success 和 Pod 序列。缺失、过期或采集失败的值按原状态显示，绝不转为 0。

  2. Prometheusscrape · probeworkload · ServiceK3s 应用集群

    exporter 抓取与 HTTP 探针。这些指标不用于判定部署是否成功。

  3. operation 状态 · run 绑定api/product-store.js部署状态 · 历史Web 界面 · 历史 · Insightsapps/dashboard

    Web 界面和 MCP 工具读取同一份 operation 记录。最近一次尝试与当前已验证的部署分开显示，AI 任务完成并不等于部署成功。

  4. 公开 HTTPS 探针gitops/bridge.pyHTTPS health公开 HTTPS URL

    只检查运维人员注册的 HTTPS health 地址，不跟随重定向，确认返回 200（如有设定，还需符合预期 JSON）。

所有连接以相同粗细显示。选择一个流程，即只突出显示其路径，并标出步骤编号。

  • 实线 · 源码、镜像与请求的流向
  • 虚线 · 运行请求、应用或同步
  • 长点划线 · 状态读取、探针与指标，独立于判定
  • 短虚线 · 已记录的失败或未知结果
  • 粗黑线 · 所选流程；数字表示顺序
  • 方框 · 所属边界，标题栏注明源码路径
  • 内层小框 · 该边界内的组件
  • 虚线框 · 平台之外
  • 橙色轮廓 · 模型作出判断之处
  • 产品 API
  • 部署记录
  • CD 执行边界
  • 入口 · CI · 目标

docs/architecture/README.md 中 10月2日（bc61a5a）的图是实现历史；本架构图依据 645e28a 的代码。提供商与网络路径因已注册目标而异，并不意味着所有提供商始终开启。