Kedge：一条 SSH 命令发布应用，缩容到零仍 1.2ms 唤醒的全球云

Kedge 是一个面向网站、应用与数据库的云平台。它的宣传语极简：“Give it code or content and it goes live on a public HTTPS URL”——给它代码或内容，它就以公网 HTTPS 地址上线。最具辨识度的动作是这条命令：

ssh kedge.dev publish '# Hello, world!'

你的 SSH 公钥就是账号。 你可以发一个文件、一个目录、一次 Git push、一个 Dockerfile 或一个容器镜像，Kedge 都会把它跑起来。Koala 周报把它定位为”对标 Fly.io 的轻量应用云”，本文基于 Kedge 官网与官方文档，拆解它的机制、数字与口径。

一、背景动机：部署平台的竞争转向”少学概念”

过去几年，Fly.io、Render、Railway、Vercel 这类轻量应用云打得不可开交。Koala 的点评很到位：竞争已从”功能是否齐全”转向”是否简洁稳定，谁能让开发者少学几个概念谁赢”。Kedge 的选择很讨巧——直接复用所有人（包括 AI Agent）早就会的 SSH，而不是让你再学一套 YAML 配置或专有 CLI 语义。

同时它明显服务那批喜欢单体、不想上托管数据库的独立开发者：每个应用自带一个复制的 SQLite 数据库和共享文件系统，本地卷持久化并自动备份到对象存储，闲置时实例缩到零。

二、技术机制：硬件隔离 VM + 温池快照

Kedge 和常见的共享容器平台不同，关键机制有四层：

1. 硬件隔离的虚拟机：每个实例、handler、沙箱、CI 任务都拿到自己独立的 Linux 内核（不是共享内核的容器），这是它安全模型的基础。
2. 温池（warm pool）快照：Kedge 预先把干净的沙箱运行时、以及初始化好的应用实例以暂停状态停在温池里。请求来了直接唤醒，不重新开机、不重新启动应用。
3. 快照冷恢复：温池空了，就从部署快照恢复一个已初始化的实例，冷启动也不重复跑应用启动流程。
4. 每应用自带数据库：复制的 SQLite 放在普通本地路径，外加共享文件树，无需单独 provision。

应用响应头里会告诉你这次请求是否等了实例：x-kedge-restore: warm|cold，并附 x-kedge-restore-ms（恢复耗时毫秒数）。这是一种少见的透明度——把伸缩行为直接暴露在响应头里。

三、关键数字与定价（官方口径）

计费按秒级、按实际消耗计量：CPU 只计被调度的毫秒数、内存只计活跃驻留页、存储只计实际字节；闲置缩到零后只付存储费。

四、口径偏差：这些毫秒数该怎么读

这一节是客观看待 Kedge 的关键，官方自己在文档里写得很坦白：

1. 毫秒数是”生产主机本地请求”测量值。性能页明确：“These are production-host measurements from local requests. They exclude client network latency and application response time.” 也就是说，1.2ms/1.5ms/16ms 是实例在服务器本地被唤醒的时间，不含你的用户到数据中心的网络往返，也不含应用自身处理时间。用户真实感受到的冷启动，要再加上跨洋 RTT。
2. 1.2ms 与 33ms 是两个不同口径：首页说”resumes in 1.2 ms”指温池恢复；33ms 是”cold restore from a snapshot”的 fleet 中位数；性能页又给出冷扩容约 16ms。三者测的是不同路径（温池唤醒 vs 快照恢复 vs 空池扩容），不能混为一谈。
3. 延迟地图是第三方历史数据，不是实时保证。coverage 页用的是 WonderNetwork 城市间 ping 数据，“Color between sampled cities is estimated… This is network geography, not a live browser test or latency guarantee.” 图上颜色是采样点之间插值估计，稀疏处标”no data”。
4. 定价是预览期估算。官网写明”The rates below are estimates for future paid service and may change”，当前公开预览只有有限免费试用。
5. “每应用一个数据库”是复制 SQLite，不是托管 Postgres；要 Postgres 得用持久卷自己跑。

五、适用 / 不适用场景

适合：

• 独立开发者与小团队：$5/月免费层够跑一个小站或开发箱；
• 喜欢单体、SQLite、文件系统的应用：不用单独管数据库；
• 间歇性流量的工具/Demo/Agent 工作区：缩到零只付存储钱；
• 重度使用 AI Coding Agent 的人：持久 dev machine 保留 checkout、工具和构建缓存，断线后继续跑。

不适合：

• 需要 SLA 兜底的核心生产业务：它仍在公开预览、定价未定、无延迟保证；
• 需要强一致分布式数据库、复杂 SQL 扩展的业务：内置是复制 SQLite；
• 对跨洋 RTT 敏感且不在十区域覆盖内的用户（注意中国大陆不在列）。

六、客观分析：优势与局限

优势： 部署心智极简单（SSH 即账号）、硬件隔离比共享容器更安全、缩到零的唤醒速度确实快、按秒计量闲时几乎免费、内置数据库省去运维。

局限： 预览期产品成熟度待观察、毫秒数不含网络与应用延迟、区域不含中国大陆、高级数据库需自行用卷部署、商业定价尚未定稿。

它意味着什么： Kedge 代表了轻量云的一个新方向——把部署接口退回到工程师最熟悉的 SSH，把数据层塞进应用本地，把闲置成本压到接近零。它赌的是 Agent 时代应用数量爆炸、单应用流量微小的未来：你不需要为每个小应用学一套云原生概念，ssh publish 一下就够。对想脱离 Docker/VPS 手工运维、又被托管 PaaS 账单劝退的开发者，Kedge 值得放进观察清单——但鉴于其预览性质，关键业务仍应等 GA 与正式定价落地后再迁移。

参考来源

• Kedge 官网
• Kedge 性能文档：instant sandboxes & scale-out
• Kedge 全球覆盖与延迟地图
• Kedge 计费文档
• Koala 项目库条目：Kedge