Appaloft 最先要做完的事没变：把当前目录变成能打开的地址。git 可以在旁边，但不是输入。
站点上曾经让人复制 appaloft deploy。这个拼写还在，它是受支持的 1.x 兼容名。新用户现在该粘贴的是：
appaloft up这条动词随公共 v1.10.0 和 appaloft/appaloft#1373 落地。下面写的是它周围的产品约定，不是一份 changelog。
输入就是你所在的文件夹
多数托管 PaaS 从已连接的仓库讲起。平台同时拥有机器时，这说得通。开发者手里已经有目录、runtime 和一台能连上的服务器时，再把 git remote 当成前提，就会多绕一圈。
Appaloft 的 Deploy 门读取当前工作目录。本地可以带 appaloft.yml。已经构建好的静态目录也可以直接传路径。这些步骤都不要求 git remote。
appaloft up --config appaloft.yml
appaloft up ./dist --as static-site目录里如果已经有 public/index.html，CLI 可以自己选 static。那是识别细节，不是第二套产品。
我们让人判断的结果很窄。成功是这个应用的 live URL。失败必须非零退出。这里不放演示网址，因为我们没有一条可供陌生人打开、复用的公开 folder→URL。部署页上的占位符是 https://<public-url>。编一条更好看的，就是营销谎言。
两扇门，只有一扇改运行状态
appaloft up 会改共享运行状态。appaloft setup agent 不会。
Agent 门把 skill 和 MCP 写入这台机器上已有的 Cursor 或 OpenCode。装完之后，agent 每次部署前仍要先问人，再运行 appaloft up，并返回 live URL。setup 是本机说明书。部署才是发布动作。
这和把部署能力装进 Cursor 和 OpenCode说的是同一条边界。两扇门如果挤在第一屏变成一条故事，人很容易把「agent 装好了」听成「应用已经上线」。
如果还没登录，第一次部署会要求登录。你还需要一台可用的 Server。这些是前提，不是第二条英雄命令。不要把 login、project create 或 server enroll 堆在 appaloft up 旁边。
对照轴停在哪里
Appaloft 是 Railway 替代方案，不是 1:1 替换。Railway 的 railway up 属于托管云，默认故事是 git 连接的 service。Appaloft 的 appaloft up 跑在你带来的 Server 上。动词看起来像，计算所有者不一样。
开发者 CLI 仍然是 npm i -g @appaloft/cli 或 brew install appaloft/tap/appaloft。curl -fsSL https://appaloft.com/install.sh | sudo sh 安装的是服务器上的自托管控制面，不是把这个文件夹部署出去的命令。
进程干净退出也不够。健康检查和公网路由落地之前，命令不能说应用已经可访问。证据边界是观察到的事实——digest、runtime、routing、health、access——不是应用正确或安全的证明。
从哪开始
人类走 /zh-CN/deploy。编程 Agent 从 /zh-CN/llms.txt 开始：机器还没教过就先 appaloft setup agent，每次部署前先问，然后再 appaloft up。
如果你已经从这条路径拿到真实的公开 URL，留着。如果还没有，就不要为截图、README 或 Show HN 编一条。文件夹够用来开始。网址必须是跑出来的。