Keeping a vibe-coded site alive: whether quotas stop or bill, and D1 row costs

Key points

• The author says the key question for every cloud service and API is whether running out of quota stops the service or keeps charging. In his summary, Cloudflare’s free tier stops and recovers at 00:00 UTC, while the paid tier has no spending cap and only sends alert emails. He suggests listing every service the project uses, confirming the behavior on each official pricing page, setting budget alerts on every paid service and spending caps on AI APIs.
• His advice by stage: projects without revenue should prefer services that stop when the quota runs out and set caps on paid tiers; products with paying users, where downtime may cost more than the bill, should set budget alerts plus a cap well above normal usage that they can afford, and add abuse protection.
• On D1, he explains that cost follows rows scanned and written rather than the number of queries, so a query that misses an index scans the whole table every time, and repeated writes are worse; he cites Nathan Schram’s January 2026 bill. His steps: confirm the most frequent queries use indexes and index only those, since indexes add write cost; batch instead of querying in loops; make reprocessing the same data idempotent, especially in scheduled jobs; and set D1 usage notifications in the dashboard.
• For health-check endpoints that query the database, he advises read-only checks with timeouts, run every 30 to 60 minutes so a read-billed database does not accrue cost. He also recommends human verification and rate limits on signup, email, SMS and AI endpoints, which scripts can otherwise hammer overnight.
• Official docs (rechecked 2026-10-15): D1 bills rows read (scanned) and rows written, an index adds a written row when indexed columns are written, Free limits reset daily at 00:00 UTC, and D1 offers usage-based billing notifications on Rows Read and Rows Written. Budget alerts do not pause or cap usage.

Original sources

1. Published2026-10-15

   Original post

   Read on 𝕏

   Ren (@Ryrenz) sorts the ways a vibe-coded site “dies” into downtime, a blown bill and silent breakage; the billing sections cover what each platform does when a quota runs out and why D1 bills by rows scanned and written.

   Ren

   @Ryrenz · Original 𝕏 post

   https://t.co/PlFwilPqsk

   2026-10-15 00:10:54 UTC

   Read originalArchived 2026-10-15

   Ren · @Ryrenz

   This archive does not contain the complete text.

   如何避免 Vibe Coding 网站暴死

   现在很多人 vibe coding 做网站，代码和配置几乎全交给 AI，大多数时候确实能用，可“能用”和“一直能用”之间还有一段距离。 练手的 demo 挂了也就挂了。网站一旦有了用户、开始收钱，某天早上突然宕机，用户不会关心背后是什么原因，只会觉得这个产品不靠谱。 “暴死”有三种可能：网站宕机；账单爆了；网站看似正常，但核心服务坏了。 下面我把自己踩过的坑和网上真实发生过的事故整理出来，分析一下常见事故，以及解决方案。 文末提供一段 prompt，可以直接复制给 coding agent ，给网站做体检。 一、网站背后的过期时间 网站像一辆车，背后压着一沓证件，行驶证、年检、保险，每张都有到期日，哪张过期车都上不了路。网站背后的这沓证件是这些： 域名 HTTPS 证书，有了它浏览器才不会提示网站不安全 各种 API key 和登录凭证，你的网站靠它们调用别人的服务 绑在云服务上的信用卡 免费试用期和预充值额度，比如 OpenAI 的预付额度，买了一年后就作废 域名反而最不用担心，注册商会提前好几周发邮件提醒。证书放在 Vercel、Cloudflare 这类平台上的，平台会自动续，基本不用管；只有自己租服务器装证书的人要自己盯，而 Let's Encrypt 从 2025 年 6 月起已经不发到期提醒邮件了。证书一旦过期，访客会看到浏览器整页的安全警告，几乎没人会点进去，等于网站打不开。 最容易出事的是各种 key 和凭证。它们有的会提醒，但提醒发到你注册时用的、早就不看的邮箱；有的干脆不提醒。 我自己就栽过一次。我有一条自动化流水线靠一个登录凭证运行，凭证寿命一个月。到期那天流水线停了，连着挂了四天我才发现。到期日精确到哪一天都是可以知道的，只是没有任何东西在看着它。 防这件事，按这个顺序来： 能自动续的，全部打开自动续。 能让机器查到期日的，交给监控工具去查。证书和域名的到期日都能自动读出来，开源的 Uptime Kuma 自己部署就能免费做到；UptimeRobot 这类现成服务，这个功能要付费。 剩下那些查不到到期日的 key，拿到的那一刻就记下来。 最简单的记法是一张表格加提醒：写清楚每个 key 用在哪、哪天拿到、哪天到期，在到期前 30 天和 7 天各设一个提醒。它不花钱，缺点是全靠自觉，哪天新加一个 key 忘了登记，它就等于不存在。 我自己是把所有 key 存进密钥管理工具 Bitwarden，在每个 key 的备注里写上签发日期和有效期，再让程序每天读一遍，快到期时给我发邮件。这对个人项目够用。 二、额度用完：网站停，或者钱包爆炸 云服务的额度很像手机流量套餐。有的套餐流量用完就断网，有的用完了自动按量扣钱。 云服务也分这两种。用完就停的，网站报错，但账单不会涨；用完继续扣钱的，网站照常运行，账单跟着流量一直涨。 新手选平台时几乎不看这一项，可它决定了出事的时候，你丢的是一天的生意，还是一大笔钱。 几个常用平台的情况： Cloudflare 的免费档用完就停，到 UTC 零点自动恢复。升级付费档以后没有花钱上限，只会发提醒邮件。 Vercel 的免费档用完会被限制功能。Pro 档超出部分按量扣钱，默认只发通知，想超额自动停，要自己去后台打开暂停开关。 Supabase 的免费档不会扣钱，超了先通知，再限制服务。Pro 档默认开着花费上限。 OpenAI、Anthropic 这类 AI 接口大多是预充值的。余额用完，网站上的 AI 功能当场失效；开了自动续充，钱就会一直扣下去。这两家都能在后台设消费上限。 2026 年 2 月，一家三人小公司的 Gemini API key 被盗，48 小时内被刷了 82,314 美元，他们平时每月只花 180 美元左右，Google 拒绝减免。 用完就停也有代价，它把“账单被刷爆”换成了“网站被刷停”。突然爆火的时候也一样。2024 年，插画社区 Cara 一周之内用户暴涨，在 Vercel 上欠下约 9.6 万美元。如果当时设了上限，这笔账单不会有，但网站会在最火的那几天宕机。 所以按阶段选。还没收入的个人项目，宁可停一天，优先选用完就停，付费档也把上限设上。已经有付费用户的产品，停机可能比账单更贵，那就设预算提醒，再设一个远高于平时用量、但你付得起的上限，同时做好防刷，第八节会讲。 具体要做的： 把项目用到的每个云服务和 API 列出来，逐个去官方定价页确认，额度用完是停还是扣 每个付费服务都设预算提醒，AI 接口额外设消费上限 烧钱的数据库：D1 Cloudflare 的数据库 D1 收费方式很特别：它不按你查了几次算钱，按查询翻过了多少行数据算钱，写入也按行算。 这像一个按翻页收费的图书馆。有目录，你直接翻到要找的那一页；没有目录，就得把整个图书馆从头翻一遍，每一页都算钱。数据库里的目录叫索引。AI 写的查询如果没用上索引，每查一次就把整张表翻一遍。 更要命的是重复写入。2026 年 1 月，独立开发者 Nathan Schram 平时每月在 Cloudflare 上只花 5 美元左右。他的程序里有两个 bug，让同一批数据被反复处理、反复写进数据库。主要的那个 bug 跑了四天才被发现，那个月一共写了约 48 亿行，账单约 4,600 到 4,900 美元。他申诉了 18 天，最后拿到一次性减免。这种运气你不能指望。 用 D1 的话： 让 AI 找出最常用的几条查询，确认它们用上了索引。只给常用的查询建，别每个字段都建，索引会让每次写入多算钱 别让程序在循环里一条一条地查，改成一次批量查 同一批数据处理两遍，结果应该和处理一遍一样，不能多插一份。定时任务尤其要注意 在 Cloudflare 后台给 D1 设用量提醒 三、数据库休眠 Supabase 的免费项目，如果连续 7 天没人碰数据库，会被自动暂停，暂停前会发邮件。数据还在，但网站连不上数据库，要你登录后台手动恢复。 这个坑专坑两种人：网站访问量很低的，和做好了先放着、过段时间才推广的。你什么都没改，某天打开网站，发现它坏了。 有两条路。一是写一个每天跑一次的定时任务，去查一下数据库，让它保持活跃。这个任务自己也会悄悄停掉，比如 GitHub Actions 的定时任务，公开仓库连续 60 天没有任何活动就会被自动关掉，所以最好配上第九节监控告警里讲的打卡。二是升级 Pro，每月 25 美元起，付费项目不会被暂停。已经在收钱的产品，直接选这条。 四、数据库备份 网站挂了，重新部署就回来了，像房子塌了还能照着图纸重建。数据丢了，就是图纸和家具一起烧了。 丢数据的方式五花八门，包括 AI 自动删除。2025 年 7 月，SaaStr 的创始人 Jason Lemkin 在 Replit 上用 AI 写代码，AI 无视他“不经允许不许改动”的指令，删掉了正式环境的数据库。 我自己也差点删过。迁移平台时，我判断一个邮件订阅服务“从来没上线过”，准备把它的数据库当空库删掉。后来翻了修改记录才发现，那个订阅表单上线过六周，库里有 40 个真实订阅者。而那台机器上，当时没有任何备份。 先搞清楚平台默认给了你什么。D1 自带时光回溯，默认开启，免费档能回到 7 天内任意一个时间点，付费档是 30 天。Supabase 免费档没有自动备份，Pro 档每天备份一次，保留 7 天。Neon 免费档可恢复至 6 小时以内。 然后补上属于你自己的那一份： 定期把数据自动导出一份，放到另一个平台。平台自带的备份和数据在同一个地方，账号被封、项目被删的时候会一起没 至少真的恢复一次，把备份导进一个新库，确认数据都在。没试过的备份，出事那天很可能用不了 删除任何数据库之前，先导出一份 五、AI 改一处坏一处 vibe coding 有个很常见的节奏：让 AI 加一个小功能，它顺手改了好几个文件，你测了一下新功能没问题，就上线了。几个小时后才发现，登录坏了，或者付款开通不了了。AI 改的范围经常比你以为的大，你测的范围经常比它改的小。 三步预防这种情况： 第一样是回滚，像玩游戏读档。Vercel 和 Cloudflare 都能在后台一键回到上一个版本。出事的第一反应是先回滚，让网站恢复，再慢慢查原因。有两点要知道：这个档只存了代码，数据库里的数据不会跟着回去，所以让 AI 改数据库结构之前，先备份；Vercel 回滚之后会暂停自动发布，修好以后要去后台手动恢复。 第二样是预览，像正式演出前的彩排。Vercel 和 Cloudflare Pages 会给每个分支生成一个预览地址，先在预览上点一遍，没问题再发布。要先确认预览连的是测试数据库和支付的测试模式，别在彩排的时候动了真钱和真数据。Cloudflare Workers 的预览默认用的就是正式数据，要格外小心。 第三样是测试。每次上线前，至少把注册登录、付款、核心功能这三样走一遍。更省事的是让 AI 写成自动测试，每次改完自动跑。不会写也没关系，Playwright 这个工具能把你在网页上的点击录下来，自动生成测试。Anthropic 在 Claude Code 的官方最佳实践里说过，给 AI 一个检查自己工作的办法，是你能做的最管用的一件事。有测试，AI 改坏了东西会自己发现；没有测试，它只会告诉你“改好了”。 最危险的故障，看起来一切正常 有一类故障不会报错，它只是让某个环节安静地失效。 我的邮件订阅服务就出过这种事。它需要一个发邮件服务的 key，可部署的时候这个 key 是空的。用户填完表单，页面显示订阅成功，数据也正常存进了数据库，只是欢迎邮件一封都没发出去，前后持续了大约六周。 付款是另一个重灾区。用户付完钱，Stripe 这类支付平台会主动给你的网站发一条付款通知，开通订单要靠这条通知。如果只靠付款后跳回来的那个页面开通，用户付完钱顺手关了页面，钱收了，订单却没开。 防这件事： 缺了关键配置（比如那个空的 key）时，让部署直接失败，别带病上线。这一条可以直接让 AI 加 程序出错要报出来，接上 Sentry 这类错误监控，别让错误被悄悄吞掉 付款流程让 AI 按 Stripe 官方要求查一遍：靠付款通知开通，确认通知是真的，同一条通知只处理一次 隔一段时间对一次账，看 Stripe 收到的钱和系统里开通的订单能不能对上 六、密钥管理 说到网站安全，很多人想到的是黑客专门盯上你。新手的网站更常碰到的，是自动化脚本在扫描整个互联网，专找没锁的门。安全公司 Escape.tech 在 2025 年 10 月扫描了 5,600 多个用 vibe coding 平台做的公开应用，找到 400 多个暴露在外的密钥，还有 175 处个人隐私数据泄露，其中包括医疗记录和银行账号。 API key 相当于你在某个服务商那里的银行卡加密码，谁拿到谁就能花你的额度。AI 为了让功能尽快能用，经常把 key 直接写进网页代码，而网页代码会原样发到每个访客的浏览器里，任何人打开开发者工具都能看到。Next.js 里名字以 NEXT_PUBLIC_ 开头、Vite 里以 VITE_ 开头的变量，都会被这样公开。 另一种情况，是把存着 key 的 .env 文件传到了公开的 GitHub 仓库。有研究者故意把 AWS 的 key 放进公开仓库做测试，1 分钟之内就被盗用了。 花钱的 key 只放在服务端，网页通过你自己的后端去调用 后端接口本身也要限制谁能用、用多快，不然别人不用偷 key，直接刷你的接口，烧的一样是你的钱 .env 一开始就写进 .gitignore，不让它被传上去 key 一旦公开过，哪怕只有几分钟，第一件事是去服务商后台作废它、重新生成一个。只删提交记录没用，它可能早被抓走了 至于 key 平时怎么存，记住这几条就够了： 存在部署平台自带的密钥设置里。Vercel 的环境变量记得勾选 Sensitive，Cloudflare 用 Secret 类型，存进去之后连后台都看不到原值 代码里只写 key 的名字，运行时再去读取，值本身不进代码，也不进聊天记录。别把 key 直接贴给 AI，让它帮你配好 开发用的 key 和正式网站用的 key 分开，能限制权限和额度的，只给够用的那一点。哪把泄露了，影响范围也小 项目多了、好几台机器要共用一批 key 的时候，再上专门的密钥管理工具，我自己用的是 Bitwarden Secrets Manager 从 key 散落在各处到统一管理，我自己踩了不少坑，以后会专门写一篇文章分享这段经验。 七、数据库门禁 用 Supabase 的人要特别注意一个叫 RLS 的设置。Supabase 允许网页直接读写数据库，用的是一把本来就公开的 key。真正决定谁能读写哪些数据的，是每张表上的门禁规则，也就是 RLS。没开门禁，任何人拿着那把公开的 key，都能读写你的整张表。 坑在这里：在 Supabase 后台点按钮建的表，默认开着门禁；写代码建的表默认不开，而 AI 帮你建表，几乎都是写代码。 研究者 Matt Palmer 扫描了 1,645 个用 AI 建站工具 Lovable 做的公开应用，发现其中 170 个的数据表任何人都能读写，泄露了用户的姓名、邮箱、手机号和付款记录。Lovable 的回应是，数据安全应该由每个应用的开发者自己负责。平台不会替你担这个责任。 防法很直接：每张表都开 RLS，然后打开 Supabase 后台的 Security Advisor，它会把没开门禁的表标出来。最后切换成未登录的身份试一下，确认读不到别人的数据。 八、接口限制 注册、发验证码、发邮件、调 AI 的接口，只要不加限制，就可能被脚本刷一整夜。刷 AI 接口，烧的是你的额度和钱。刷邮件更隐蔽：脚本用一堆假邮箱注册，你的网站挨个给这些地址发验证邮件，结果大量退信，邮件服务商会因此暂停你的发信（Resend 要求退信率低于 4%），正常用户也收不到邮件了。短信更贵，有一种诈骗专门让你的网站往高价号码狂发验证码，攻击者从中分成。 还有管理后台。很多人的 /admin 页面只是没在首页放链接，并没有真的要求登录，而扫描程序专门会去试这种常见地址。 注册、登录、发送类的表单接上人机验证，比如免费的 Cloudflare Turnstile，网站不在 Cloudflare 上也能用。记得让 AI 确认服务端也做了校验，只在网页上放个验证框等于没装 给接口限制频率，先用你所在平台自带的功能，Cloudflare 和 Vercel 的免费档都能设 1 条限流规则 发短信验证码的，只开你真正需要的国家和地区 管理后台必须真的要求登录 只给自己用的工具，干脆别放到公网上，放进内网，或者在门口加一道邮箱验证 至于 DDoS 这种大流量攻击，Cloudflare 所有套餐都带防护，免费档也有，Vercel 也会自动拦。真正要担心的，是自己租服务器、把服务器地址直接暴露在公网的情况，最简单的办法是把网站放到 Cloudflare 后面。 九、监控告警 前面八个问题各有各的防法，但总有漏的时候。监控告警是为了在出事的第一时间知道它出事了。 首页能打开，不代表网站健康 最基础的监控叫存活检查：一个外部服务每隔几分钟访问一次你的网站，打不开就通知你。它像量体温，能发现发高烧，可发现不了半死，也发现不了第五节里那种看着正常其实已经坏了的情况。首页能打开，不代表登录能用、数据库能连。 所以最好再让 AI 写一个健康检查接口，相当于定期体检，它会真的去数据库查一次，再确认关键配置都在。让 AI 写的时候交代清楚四点：只读不写；每一步都设超时；出了问题只回答“不正常”，不暴露内部细节；检查频率放低到 30 到 60 分钟一次，免得按读取量收费的数据库白白花钱。 告警要发到你真的会看的地方。只发邮件很容易被淹没，最好推送到手机上。 告警太多，等于没有告警 这是我自己踩过的坑。我给服务器和网站配了 41 项检查，4 天里收到 22 封故障邮件，真正的故障一个都没有。后来真有一台机器重启了，那唯一一封真实的通知和十几封假警报躺在同一个收件箱里，差点被我当成噪音划掉。 假警报最大的危害，是让你不再相信告警。Google 讲网站运维的 SRE 手册里有一条原则：每一次告警，都应该是需要人去处理的。 网站好好的时候也会响的告警规则，就该删除 偶尔失败一次先别报，连续失败或者从别的地点复核过再报，UptimeRobot 这类工具自带复核 宁可少监控几项，也要让每一封告警都值得点开 监控自己挂了，你也不会知道 监控程序自己挂了，它不会告诉你。你只会以为一切正常，因为没收到任何告警。 解决办法像值班打卡。让监控程序每次正常跑完，去一个外部服务打一次卡，超过约定时间没打卡，外部服务就给你发告警。备份脚本和定时任务也一样，跑完就打卡，哪天没打，就说明它悄悄停了。 背后的道理很朴素：负责报告故障的东西，不能和可能出故障的东西一起倒下。 十、免费工具推荐 给新手推荐它们是因为免费档够小网站用、允许商用、注册就能用，不用自己架服务器，并不代表它们是各自领域唯一的选择。 UptimeRobot：网站打不开时通知你。免费档有 50 个监控，每 5 分钟检查一次，条款允许商用，还能推送到手机 App，不会淹没在邮箱里 Sentry：网站代码出错时通知你，并告诉你错在哪。它是错误监控里最常用的工具，官方直接支持 Next.js 和 Cloudflare Workers，让 AI 接入很容易。免费档每月 5,000 个错误，一个人用够了 healthchecks.io：给备份和定时任务打卡，哪天没打卡就通知你。数据库保活、自动备份、监控程序本身，有没有悄悄停掉，都靠它来发现。免费 20 个检查 另外，Cloudflare、Vercel、Supabase 和各家 AI 接口后台的用量提醒也是免费的，，记得一起设上。 十一、出事之后，先止血再排查 真出事了，按这个顺序来： 先把相关的日志导出来存好。平台日志留得很短，回滚之后再去找可能就没了 回滚到上一个能用的版本，让网站先恢复 数据坏了的话，先把备份恢复到一个新库，核对没问题再切换过去，别直接覆盖原库 出事过程中就告诉受影响的用户，别等修好再说。UptimeRobot 的免费档带一个状态页，可以用来发通知 恢复之后复盘：怎么发生的，为什么没早点发现 把这段 prompt 交给 AI 把下面这段 prompt 复制给 Claude Code、Cursor 或者其他 AI 编程工具，让它把你的项目从头查一遍： 做了这些，网站仍可能会有风险，但下一次出事的时候，你不会手足无措。