Stackdome

一句话定位

一个开源、可自托管的部署平台，把"整个应用（服务 + 数据库 + 存储）"描述成一个 Stackfile 一次部署出去，人能用的 Canvas/CLI 和 agent 能用的 skills 走的是同一套应用模型—— Railway 的开源自托管替代品。

做这个东西的人

Stackdome 团队（主作者 akshaysasidrn），主仓 AGPL-3.0，另有 stackdome-cli（MIT）、 stackdome-skills（Apache-2.0）、cluster-agent（K8s operator）。 仓库 2025-05-20 创建，至今约 1,470 次提交。

判断：一年多的持续提交说明是认真做的，不是 Show HN 一日游。但同期只有 20 star， 说明营销和社区都没起来——这种"工程先行、冷启动失败"的形态在产品里很常见， 要小心区分"没人知道"和"没人需要"。

它到底能做哪几件事

• 一个应用 = 一个 Stackfile → 服务、数据库、存储、网络、可观测性一次性描述， 三端（agent/Canvas/CLI）读写同一个模型
• Git push 到上线 → 集群内构建、内置镜像仓库、发布可回滚 （整个 stack 一起回滚，不是单个 deployment）
• 托管 Postgres → HA、自动备份、时间点恢复
• 无限 preview 环境 → 每个分支一套完整环境，编码 agent 可以并行开很多个
• 自带算力 → 接你自己的 K8s 集群（v1.27+，EKS/GKE/AKS/k3s）或 2 vCPU / 4GB 的裸 VPS
• Agent 一等公民 → stackdome-skills 加 agents.stackdome.com， agent 能从提示词直接创建、部署、调试；MCP server 在开发中
• 每次变更都是 diff → 发布前 UI 显示改了什么，先验证健康再算上线

它在替代什么旧行为

想自己部署应用、不把命脉交到 Vercel/Railway 手上的人，过去有几条路，都别扭。

一是用 Railway/Render/Heroku 这类托管 PaaS。省事，但你的基础设施逻辑锁在别人家， 成本随用量非线性上涨，数据合规和私有化没得谈。

二是自建 PaaS：Coolify（Docker 单机）或自己拼 K8s + Helm + CI + 镜像仓库 + Postgres operator。Coolify 撑不起多服务编排和团队场景；K8s 这条路光是"跑通"就要一个 专职平台工程师，堆出来的还未必有托管 PaaS 的体验。

三是 agent 时代的新问题：让编码 agent 帮你部署，等于让 agent 去操作一堆你手工拼的、 没有统一模型的基础设施——它不知道 stack 里有什么，只能猜。

Stackdome 替代的是第二和第三条的合体：把"自托管 PaaS"打包成开箱即用， 同时给 agent 一个可以编程式操作的统一应用模型。这是它区别于 Coolify 和原始 K8s 的关键—— 所有入口写同一个模型，人类和 agent 可以接力。

商业模式

双轨：官方云（alpha 阶段，容量有限、环境临时）加自托管免费（AGPL-3.0）。 云定价未披露。

判断：这是 Supabase/Coolify 模式——开源做信任和分发，云做收入。 但云还在 alpha、"容量有限"字样直接写在首页，说明商业模式本身还没跑起来。 AGPL 的用意也明显：防止大厂直接拿代码做托管竞争。

硬数字

• 20 star / 0 fork（主仓），创建于 2025-05-20，约 1,470 次提交
• HN：21 分、6 条评论（2026-08-13 前后）
• 生态仓库：cli（MIT）、skills（Apache-2.0）、cluster-agent（K8s operator）
• 支持 K8s v1.27+ 或 2 vCPU / 4GB 单 VPS
• 云用户数、付费收入：未披露

四维评估

判断

这是"自托管浪潮 + agent 交付"两条趋势的交点产品，方向几乎必然成立，但执行证据还很薄。 自托管 PaaS 的需求已被 Coolify 证明，K8s 层缺一个现代实现也是真的； 而"让 agent 直接部署"正在成为刚需。把三者放在一起是聪明的定位。

可迁移的规律：当两条趋势交汇时，做那个"交点产品"——比单押一条曲线更容易起势。 但要小心：交点产品的天花板是两条曲线的最小值。自托管用户和 agent 优先用户是两个人群， Stackdome 试图同时服务，可能两头都不够深。

最大的疑问是执行：14 个月、20 star。要么是作者闷头做产品不做营销 （README、文档、架构都像真的），要么是市场对"又一个自托管 PaaS"已经不兴奋了。 还有一个信号值得注意：commit 里混有大量 Claude 的提交——这本身符合"用 agent 开发" 的叙事，但也要问：这是不是一个人的副业项目，能扛多久。

它的差异化赌注：agent 从提示词到上线全程可操作，且有人类可审查的 diff 和回滚。 这个设计对，因为 agent 部署的信任问题（"agent 改坏了怎么办"）只能用"可审查 + 可回滚" 回答。但它需要先证明"人类真的会用它"。

下一步看什么

① 云 alpha 结束时的定价和 GA 时间——商业模式从免费 alpha 到付费的跨越是否顺利 ② 星数和社区三个月内是否涨——1,470 次提交的工程能力若配上营销，涨星会很快； 不涨就是没人要 ③ MCP server 和 agent 集成是否被真实 agent 工作流采用（有公开案例比有广告更有用）

可借鉴的做法

产品逻辑：给 agent 做操作入口时，先定义"统一应用模型"，所有入口（人类 UI、CLI、 agent）读写同一个模型，再谈功能。这样 agent 和人类可以接力同一个工作流， 这是 agent 时代产品的关键架构决策。

定价结构：云 + 自托管双轨是标准结构，值得注意的是 AGPL—— 自托管产品用 AGPL 保护托管业务的模式正在成为默认。

结论

持续观察。 定位是三条趋势的正确交点，架构也立得住，但 14 个月 20 star 的执行结果 不支持任何乐观结论。这是本批里最值得三个月后回访的项目——因为它的赌注 （agent 部署 + 自托管）要么是零，要么是很大的东西。