这篇是怎么来的
站上原来有十几篇关于 claw 免费容器的短文，每篇只讲一个服务怎么搭，最短的那篇不到一百字。这种情况在搜索引擎眼里很难看：十几个页面在抢同一个词，内容又都很薄，最后谁也没排上去。
所以我把它们合成了这一篇。注册、额度规则、控制台怎么认、六个常跑的服务怎么部署、存储怎么挂、服务睡着了怎么叫醒、以及免费额度的边界在哪。看完不用再翻别的。
下面所有配置都是我自己在 claw 上跑了大半年验证过的，额度消耗的数字也是从 Billing 页里抄的。
claw 是什么，$5 到底能跑几个服务
claw（Claw Cloud Run）是个 PaaS，思路和 Railway、Render 一样：你给它一个 Docker 镜像或者一个 GitHub 仓库，它负责跑起来。不用管服务器、不用装 Nginx、不用申请证书。
它被用得多的原因就一条：用 GitHub 账号注册，每月送 $5 额度，长期有效。
$5 乍看不多，但 PaaS 是按实际用量计费的，一个轻量常驻服务一个月可能只花几毛钱。
我现在的实际开销是：Uptime-Kuma、图床、青龙、new-api 四个服务同时在线，一个月合计 $3 出头。还剩一块多，但没往上加服务，因为加一个就得重新观察一周资源曲线，不值得。
💡 赠送额度跟 GitHub 账号的注册时长挂钩。账号越老越稳，新注册的小号可能拿不到，或者拿到的额度下调。这是平台的风控，不是故障。
注册只要三步，但第一步就有门槛
打开 claw 官网，右上角 Sign in，选 Continue with GitHub。
授权时会读你的 GitHub 基础信息：用户名、头像、邮箱、账号创建时间。只读，不需要仓库权限，这点可以放心。
进控制台后切到 Billing，确认本月额度到账。
额度是 0 的话基本就两个原因：GitHub 账号注册时间太短（常见的门槛是 180 天），或者这个 GitHub 账号已经绑过另一个 claw 账号了。第二种无解，一个 GitHub 账号只能对一个 claw 账号。
控制台只要记住四个地方
| 位置 | 用途 |
|---|---|
| App Launchpad | 部署和管理服务的主界面 |
| Region | 选机房，直接决定延迟 |
| Storage | 持久化存储，数据不丢全靠它 |
| Billing | 看剩余额度和消费明细 |
机房我选的是 AP-Southeast（新加坡）。国内访问延迟在 60—90ms 之间，比 US West 快一截。欧洲机房绕路太明显，不建议。
部署前先分清两种来源
claw 的 App Launchpad 支持两种部署来源，用途不太一样。
填 Docker 镜像名 —— 比如 louislam/uptime-kuma:1。官方有现成镜像的服务走这条，我大部分服务都是这么部署的。
绑 GitHub 仓库 —— claw 自己去构建。适合改过代码，或者需要自定义构建参数的场景。这条路的坑在于构建失败时日志比较难看懂，第一次用建议先走镜像。
不管走哪条，要填的配置项是同一套：
图床：我最推荐第一个部署的服务
图床是我觉得 claw 最值的用途。容器本身只做转存，图片实际存到 Cloudflare R2 或者 Telegram，几乎不占容器资源。
要填的东西：
- 镜像地址：用项目公开镜像，或者拿自己的 GitHub 仓库构建
- 端口：项目默认，通常是 8080
- 环境变量：按项目文档填 R2 的
ACCOUNT_ID、ACCESS_KEY、SECRET_KEY、BUCKET - 挂载存储：必须挂，挂到项目自己的数据库目录
最后一条我吃过亏。第一次部署时觉得图床只是转存，数据应该不重要，就没挂存储。结果重新部署之后上传记录、密钥配置全部清空，图片还在 R2 里但后台一张都列不出来，只能重新配一遍。
部署完先拿到的是临时域名，绑上自己的域名之后就能直接用了。
Uptime-Kuma：最简单的一个，适合练手
开源、界面干净、支持 HTTP/TCP/Ping/DNS/关键词检测/证书到期，告警能发 Telegram、邮件、Webhook。
要填的：
镜像：louislam/uptime-kuma:1
端口：3001
存储：挂载到 /app/data
CPU：0.2 Core
内存：256 MB/app/data 是硬要求。Uptime-Kuma 的 SQLite 数据库和全部配置都在这个目录里，不挂载就等于每次重启从零开始配。
部署完先进后台 → 设置 → 通知，配一个通知渠道。我用的 Telegram Bot，比邮件可靠不少，邮件通知进垃圾箱这件事真的会耽误事。
new-api：把多个平台的 key 合成一个入口
new-api 是 one-api 的分支，做多模型 API 聚合分发，对外是 OpenAI 兼容格式。跑在 claw 上的用处是把手上几个平台的 key 收拢成一个入口，换模型不用改代码。
配置要点：
- 端口 3000
- 存储挂到
/data，数据库在里面 - 环境变量：
SQL_DSN（用外部数据库时填）、TZ=Asia/Shanghai - 内存给到 512 MB，渠道多了内存会涨
部署完第一件事是改密码。 默认账号密码是 root / 123456，公网上的实例真的会被扫，我的面板日志里能看到持续不断的登录尝试。
青龙面板：轻，但你的脚本不一定轻
青龙用来跑签到和各类定时脚本。
端口：5700
存储：挂载到 /ql/data
CPU：0.2 Core
内存：256 MB青龙本身占用很低，问题出在它跑的任务上。如果你的脚本经常把 CPU 打满，claw 是按实际用量计费的，那个月的额度会消耗得比预期快很多。我的做法是新脚本先跑几天，看 Billing 里的曲线再加。
Alist：把网盘挂成一个 WebDAV
Alist 能把几十种网盘挂载成统一的 WebDAV，配合 Infuse、nPlayer 这类播放器很好用。
端口：5244
存储：挂载到 /opt/alist/data
内存：256 MB5244 是默认端口。首次启动要生成管理员密码，Docker 部署的话在容器终端里执行 ./alist admin random。
持久化存储：这步漏了，前面全白干
容器是无状态的。你在容器里新建的文件，重启、重新部署、平台迁移之后一律不存在。
具体做法是在 claw 控制台的 Storage 里建一块卷，然后在 App 配置里挂到服务的数据目录。各服务的数据目录：
| 服务 | 必须挂载的路径 |
|---|---|
| Uptime-Kuma | /app/data |
| 青龙面板 | /ql/data |
| new-api | /data |
| Alist | /opt/alist/data |
| 图床项目 | 项目自身的 data/ 目录 |
卷的大小按需给就行。claw 的存储也计费，但占额度很小，我给几个服务各分了几百 MB，一个月加起来不到一毛钱。
服务为什么会睡着，怎么叫醒
免费 PaaS 普遍有资源回收策略。claw 算宽松的，但有两种情况会让服务停。
额度耗尽。 月初到账，月中就用完的话，服务会被暂停到下次结算。建议在 Billing 里开一个用量告警，到 80% 就提醒你。
长时间零请求。 部分平台会对完全没有流量的应用做缩容。如果你跑的是纯自用的服务，比如个人图床，加个定时请求就能保持活跃。
我用的是 Cloudflare Worker 的定时任务，每十分钟请求一次服务地址，成本为零。
六个服务怎么分这 $5
我的策略是资源按最小值起步，别一次给满。
先给 0.1 Core / 128 MB 跑起来，观察两三天，在控制台指标里看实际 CPU 和内存峰值，然后按峰值往上调一档。CPU 一直很低就保持最小值，内存经常贴近上限再加。
一个我觉得比较合理的分配：
| 服务 | CPU | 内存 | 原因 |
|---|---|---|---|
| Uptime-Kuma | 0.1 | 256 MB | 监控本身很轻 |
| 图床 | 0.1 | 128 MB | 只做转存 |
| 青龙 | 0.2 | 256 MB | 任务执行时吃 CPU |
| new-api | 0.2 | 512 MB | 并发高时吃内存 |
四个加起来大约 $3 到 $4。先按这个跑一段时间，确认额度够用，再考虑加第五个。
免费额度的边界在哪
有几句话得说在前面，免得你踩了才发现。
它不是 VPS。 没有 root 权限，装不了系统级软件，改不了内核参数。开端口只能通过平台映射，自己配 iptables 是不行的。需要完整系统权限的场景，老老实实买 VPS。
额度是共享池。 每个服务都从同一个 $5 里扣。想跑一个吃资源的服务，就得砍掉别的。
平台政策会变。 免费 PaaS 的商业模式就是拿免费额度引流，调整政策是常态。别把唯一一份关键数据放在上面，定期导出到自己的存储。
别拿它跑需要长期稳定在线的业务。 个人服务、玩票项目、内测环境都很合适，生产环境还是上正经服务器。
常见问题
注册后额度是 0？
GitHub 账号时长不够，或者已经绑过账号了。前者等账号变老，后者换不掉。
部署成功但页面打不开？
九成是端口填错。claw 要你显式声明容器暴露的端口，声明 8080 但容器实际监听 3000，就会一直 502。先去容器日志里确认实际监听端口。
重启后数据没了？
没挂持久化存储。回去看上面那一节。
能绑自己的域名吗？
能。在 App 配置里填上域名，然后去 DNS 加一条 CNAME 指向 claw 给的地址。顺序是先加域名再验证，反了会卡住。
能跑数据库吗？
技术上可以，我不建议。数据库对 IO 和稳定性要求高，容器化 MySQL 在额度受限的环境里容易出问题。轻量数据用 SQLite 就够，真要上数据库还是买个便宜 VPS。
我的部署顺序建议
先上 Uptime-Kuma。它最简单，只需要挂一个目录，而且部署完立刻就有用：你可以拿它去监控 claw 上其他服务的可用性。
跑通之后再上图床和 new-api，这两个都涉及环境变量和外部服务对接，是配置项最多的。别一上来就挑最复杂的。
另外提醒一句：claw 上跑的监控面板，最好别用来监控 claw 自己。面板和被监控对象在同一平台上，平台出问题时你收不到告警。我另外用了一个 Worker 探针从外面盯着 claw，具体怎么选可以看 VPS 探针怎么选。
claw 这种免费容器和 VPS 是互补的，不是替代关系。如果你的机器需要做性能调优，Cloudflare Cache Rules 实战 那篇讲的是怎么把边缘这一层压到最省。