返回博客首页
free-for.dev 怎么用：用免费服务把 MVP 上线，而不是收藏 1,000 个工具
做一个还没有用户的产品，最容易犯的错不是技术选错，而是太早为“不确定会不会发生的增长”买单。域名、数据库、部署、邮件、日志、对象存储各订一套，功能还没开放，账单和配置已经堆起来了。
free-for.dev 的价值不在于替你挑出“最好的免费服务”。它把面向开发者的 SaaS、PaaS 和 IaaS 免费档按需求编成目录，让你先从“我缺什么能力”开始找，而不是从一长串产品名里盲选。适合正在做个人项目、内部工具、Demo 或第一个可用版本的人。
这篇文章给你一条更实际的用法：先写出 MVP 必须跑通的链路，再到目录里找每一环的候选服务；上线前把额度、数据导出和付费触发点写清楚。这样免费档会帮你缩短验证周期，而不会变成日后最难拆的技术债。
free-for.dev 不是“白嫖榜”，先读懂它收录什么
这个项目只收录面向开发者、以服务形式提供的免费档；不是自托管软件合集，也不把限时试用当作免费层。维护规则还要求服务能明确说明免费内容，若免费档按时间划分，持续时间需要足够长。它本身不是服务商，也不会替你承诺某个额度永远存在。
打开目录后，不要从第一条一路往下翻。左侧分类就是你的检索入口：需要“用户注册邮件”，先看 Email；需要“给网页保存图片”，先看 Storage and Media Processing；需要“出了错能知道”，先看 Monitoring 或 Log Management。每次只挑一个环节，顺着分类点进候选项目的官方定价页核对。
先写一张 MVP 能力表，再挑服务
在注册任何账号前，用十分钟写下这张表。它会把“我是不是还需要某个服务”变成可判断的问题。
| 产品环节 | 第一版必须做到什么 | 先不要做什么 | 你要去目录里找的分类 |
|---|---|---|---|
| 前端 | 用户能打开、提交一个表单 | 多地域性能优化、复杂 CMS | Web Hosting / CDN and Protection |
| API | 接收请求、校验输入、调用业务逻辑 | 微服务拆分、队列集群 | PaaS / IaaS / APIs, Data and ML |
| 数据 | 保存用户或业务记录，并能导出 | 一开始就做多库同步 | Managed Data Services |
| 文件 | 上传一张图片或导出文件 | 全量媒体处理管线 | Storage and Media Processing |
| 通知 | 发出注册、登录或状态邮件 | 完整营销自动化 | |
| 可观测性 | 发现报错、看到最少量关键事件 | 堆满大屏指标 | Monitoring / Log Management |
把“第一版必须做到”写成可以验收的动作。例如，不写“需要数据库”，而写“用户提交表单后，刷新页面仍能看到自己的记录；管理员能导出 CSV”。这句话能帮助你判断托管 PostgreSQL、SQLite 或 BaaS 哪个够用，也会让 Agent 在生成代码时少猜需求。
一套可以先跑起来的 MVP 组合
以一个“用户上传文件，后台生成摘要，再用邮件通知”的小产品为例，第一周不需要选十几家平台。先选一条能独立验证的链路：页面能访问、请求能处理、数据和文件能保存、出错能定位、通知能送达。
| 环节 | 可先考察的服务 | 选择时要问的问题 |
|---|---|---|
| 部署与 API | Cloudflare Pages + Cloudflare Workers | 能否用你现有框架部署？本地和生产环境变量是否分开？ |
| 关系型数据 | Neon 或 Supabase | 能否导出？连接数、休眠策略和分支能力是否符合当前开发方式？ |
| 边缘或轻量数据 | Cloudflare D1 或 Turso | 读写模式是否适合 SQLite？迁移和备份怎么做？ |
| 文件 | Cloudflare R2 或 Supabase Storage | 单文件大小、访问权限、删除策略和导出路径是否清楚？ |
| 事务邮件 | Resend 或 Brevo | 是否支持你的发件域名？免费档能否满足验证邮件和错误通知？ |
| 错误与日志 | Sentry 或 Better Stack | 发生异常时谁能收到通知？事件保留多久？ |
这不是一份“必须照抄”的技术栈。它的作用是提醒你：同一服务商能覆盖多个环节时，先减少账号和集成数量。比如你已经在用 Cloudflare 部署前端和 API，就先评估 D1、R2 是否够用；只有遇到数据模型、查询或团队协作的明确限制，再引入第二家服务。
这类清单页适合用来做候选池，不适合直接抄额度进产品方案。免费档会变，地区、账户状态、验证方式和公平使用规则也会影响可用性。点开服务商的官方页面后，把你真正会碰到的三个数字记下来：请求或计算上限、数据存储上限、超额后的处理方式。
从目录里挑候选项，按“可退出”排序
免费不等于成本为零。真正昂贵的是产品跑起来以后，发现数据无法导出、域名无法迁移、日志查不到、或者配额耗尽没有告警。筛选一个服务时，按下面顺序看，比先比较额度更有用：
- 数据能带走吗？ 数据库是否能导出，文件是否能批量下载，日志是否能保留到排查完成。
- 超额会发生什么？ 是请求被拒、降速、停服务，还是自动进入付费？把结果写到 README 或运维说明里。
- 能否接入自己的域名和身份体系？ 验证邮件、回调地址、登录跳转往往比部署本身更早暴露问题。
- 团队能不能接手？ 密钥放在哪里、谁有后台权限、账号能否转移，不能只存在一个人的浏览器里。
- 替换一项要动多少地方？ 先把存储、邮件、模型调用放进独立模块，别让业务代码到处直接调用供应商 SDK。
你可以把这段提示词交给 Code0，先整理自己的选择，而不是让它替你拍板：
我在做一个【产品描述】MVP，第一版只需要完成：【3 到 5 个可验收动作】。
候选服务如下：【粘贴链接或名称】。
请输出：
1. 每项服务覆盖的能力和缺口；
2. 哪些依赖可以先不引入；
3. 每项服务的退出方案：数据导出、替换模块、超额处理；
4. 上线前必须人工核对的定价、地区、域名和隐私项。
不要编造免费额度；不确定的内容标记为【待核】。
邮件、监控和 AI：最容易在“能跑”以后才发现缺口的三块
很多 MVP 的前端和数据库当天就能搭好，真正卡住发布的是邮件域名、错误通知和模型请求记录。不要等用户说“收不到验证码”才开始找服务。
邮件服务先做一封真实验证：从生产域名发到 Gmail、企业邮箱和一个备用地址，检查是否进入垃圾箱，再看退信和域名验证状态。监控同样至少做一次故障演练：故意让 API 返回 500，确认异常能在你选择的工具里出现，并且有人知道要处理。
AI 功能则单独记录四件事：模型供应商、每次调用的输入输出大小、超时和失败后的用户提示、每天可以承受的预算。若需要统一记录或路由多个模型，可以评估 Langfuse、Portkey 或 OpenRouter，但不要把“有免费入口”误写成“生产环境无需成本”。模型调用要设置上限、记录成本，并准备降级响应。
目录的收录规则，反而是一份供应商尽调清单
项目对新增条目的审查很严格：是否真有免费档、价格是否公开、服务是否有联系与隐私说明、免费档是否满足基础安全条件。这不只是维护社区质量的办法，也可以直接搬到你的采购清单里。
遇到任何新平台，先问：它能不能把免费档写清楚？隐私政策和服务状态页在哪里？域名、账号和数据归谁？若答案需要注册后再找销售才知道，就不要把它设为 MVP 的唯一关键依赖。
用一周验证，而不是花一周搭“完整架构”
| 时间 | 只做一件事 | 通过标准 |
|---|---|---|
| 第 1 天 | 写能力表，选 1 套最少服务组合 | 所有服务都有明确用途，没引入“以后可能用”的组件 |
| 第 2 天 | 部署最小页面和 API | 用自己的域名或预览地址完成一次真实访问 |
| 第 3 天 | 接入数据和文件 | 创建、读取、删除各成功一次，并记录导出办法 |
| 第 4 天 | 接入邮件和错误通知 | 真邮件送达；故意制造一次报错并收到告警 |
| 第 5 天 | 记录配额与成本触发点 | 每个服务都写明查看用量的位置与超额后果 |
| 第 6–7 天 | 找 3 个真实用户完成任务 | 只修阻碍任务完成的问题，不扩功能 |
这一周结束时，你要拥有的是一份能让人使用的链路和一张清楚的风险表，不是一张画满服务 Logo 的架构图。用户开始稳定使用以后，再根据真实的请求、数据和支持成本决定哪一项值得付费。
在 Code0 的多模型工作流里，把“选服务”变成可复用决策
当你需要比较文档、生成集成代码、整理上线清单或分析错误日志时，可以在 Code0 统一管理模型调用。建议把本文的能力表、候选链接、退出方案和上线检查清单放进同一个项目目录。下一次做新 MVP 时，先复制这四份输入，再替换业务需求；比每次从“有没有免费工具推荐”开始搜更快，也更容易留下可维护的决策记录。
free-for.dev 适合你在产品还没有证明自己之前，把钱和时间留给验证。它不会替你设计架构，也不能保证任何服务长期免费；它提供的是一张从需求出发的地图。带着能力表去找、带着退出方案去接入、带着用量告警去上线，免费档才会真的帮你把第一个版本推到用户面前。
