跳到主要内容

在 Hugging Face Spaces 上部署 SkillFlaw

SkillFlaw 可以打包到 Hugging Face Spaces 上运行，但并未提供一个可直接复制并开箱即用的官方 Space。

过去那种“复制一个预构建 SkillFlaw Space” 的做法，不属于当前受支持的部署路径，不应继续被视为受支持方案。

Spaces 需要提供什么​

即使在 Hugging Face Spaces 上，SkillFlaw 当前的部署契约仍然成立：

  • 在 7860 端口运行的 backend
  • 用于持久化应用数据的 PostgreSQL
  • 当 SKILLFLAW_CACHE_TYPE=redis 时所需的 Redis
  • 用于 SKILLFLAW_CONFIG_DIR 的可写存储
  • SKILLFLAW_SECRET_KEY_FILE 所需的真实文件

这意味着：一个有意义的 Space 部署，必须被当成自定义容器部署来设计，而不是把它看成某个上游 demo 的复制品。

推荐的 Spaces 使用边界​

如果你确实要用 Spaces，建议把目标收窄在：

  • 内部演示
  • 短生命周期验证环境
  • 对数据与流量画像都可控的实验环境

如果你要运行长期编辑器环境，或承载真实生产流量，更推荐使用更贴合 SkillFlaw 多服务运行模型的平台，比如带反向代理的 VM 或 Kubernetes。

谨慎选择部署形态​

仅 backend 是最简单可行的形态​

如果你的 Space 只是用来暴露 API 或 MCP 功能，那么仅 backend 形态是最不容易出意外的选择：

  • 公开 backend 服务
  • 连接外部 PostgreSQL 与 Redis
  • 为 SKILLFLAW_CONFIG_DIR 挂载持久化存储
  • 提供 SKILLFLAW_SECRET_KEY_FILE 所需的 secret key 文件

完整编辑器部署并不适合“单个复制 Space”​

SkillFlaw 分别发布了 backend、frontend 与 docs 镜像。

如果你需要完整浏览器 UI、docs 与 backend，并希望对齐仓库中的参考部署，那么把所有东西挤进一个被复制的单体 Space，通常并不是正确的运维形态。更合理的方式，是使用可以有意识承载多服务的平台，而不是把它硬塞进一个伪一键部署里。

自定义 Space 的最低检查清单​

在把某个 Space 部署视为有效之前，请确认：

  • 该 Space 使用的是自定义 Docker 运行时
  • PostgreSQL 已外置
  • 如启用 Redis，Redis 已外置
  • SKILLFLAW_CONFIG_DIR 对你的使用场景来说是可写且足够持久的
  • SKILLFLAW_SECRET_KEY_FILE 指向运行时中的真实文件
  • /health 能成功响应
  • 任何公开 API 或 MCP 端点都已启用合适的认证控制

如果你需要的不只是 demo，更好的替代方案是什么​

如果你的真实需求是“可靠地对外提供一个有 URL 的环境”，而不只是“找个地方跑起来”，建议优先使用这些方案：