KechuAI

bknd：一个能嵌进前端、跑在 Cloudflare Worker 上的 Firebase 替代

开源
后端
TypeScript
BaaS
边缘计算
2026/9/30
·

阅读时间: 大约 9 分钟

bknd：一个能嵌进前端、跑在 Cloudflare Worker 上的 Firebase 替代

bknd 官方文档首页：自述"轻量、batteries-included、可嵌入前端"，并醒目提示仍处 beta

Firebase 把后端托管给谷歌，Supabase 把 Postgres 托管给第三方——两者都有供应商锁定的影子。bknd（仓库 bknd-io/bknd）走了第三条路：一个用 TypeScript 写、构建在 Web 标准之上的后端框架，把数据库管理、认证、媒体上传、工作流做成可模块组合的能力，让你能把整个后端”嵌进”自己的前端应用，连 Cloudflare Worker、Vercel、AWS Lambda 这样的边缘运行时也能跑。

一、它解决什么问题

做数字产品总要同时写后端（逻辑）和前端（界面）。从零写后端需要认证、数据库、媒体存储等深知识；用 Firebase/Supabase 又把数据和运行时绑给了一家厂商。bknd 的主张是：后端应该像前端依赖一样，用 npm 装上、跟着你的应用一起部署，而不是一个需要单独运维的服务。它的口号是”no more deploying multiple separate services”——一个进程/一个函数，前后端一起上线。

二、核心机制：Web 标准 + 适配器

从 README 与文档整理，bknd 的设计有几个关键点：

  • 全功能可视化后端：内置管理后台（admin dashboard）、REST API、认证、媒体、工作流（flows）；
  • 模块化、opt-in：data / auth / media / flows 都是可选插件，不要的不打包；
  • 基于 WinterTC Minimum Common Web Platform API：只依赖 Web 标准 API，换取跨运行时的可移植性；
  • 适配器式基础设施：不抽象底层驱动，直接对接你选的数据库与存储，保留完全控制权；
  • 内置 MCP server：可作为 AI Agent 的后端，用 MCP 协议控制后端状态。

把 MCP 当成一等公民内置，是 bknd 区别于传统 BaaS 的信号：它瞄准的不只是”人操作的后台”，还包括”Agent 调用的后端”。Agent 需要持久化状态、受控的数据读写与可审计的操作，而 bknd 把这些原语和一套协议（MCP）打包，理论上可以让一个跑在 Worker 上的小后端同时服务前端用户和外部 Agent。不过这部分与 flows 一样属于较新的方向，官方文档与实际生产案例都还在积累。

bknd README：功能清单与包结构（bknd 主包含后端与适配器，另有独立的 Admin UI 组件包）

它的兼容性矩阵相当宽：

维度支持范围
运行时Node.js 22.13+、Bun 1.0+、Deno、浏览器、Cloudflare Workers/Pages、Vercel、Netlify、AWS Lambda
数据库（SQLite）LibSQL、Node SQLite、Bun SQLite、Cloudflare D1、Durable Objects SQLite、SQLocal
数据库（Postgres）原生 Postgres、Supabase、Neon、Xata
前端框架React、Next.js、React Router、Astro、Vite、Waku
对象存储AWS S3、S3 兼容（R2、Minio、Tigris）、Cloudinary、文件系统、OPFS

最小用法是一条 CLI：npx bknd run，它会在本地生成 SQLite data.db 并在 http://localhost:1337 打开管理后台。官方称一个完整 bknd 应用作为 API 部署在 Cloudflare Worker 上时，gzipped 后约 300 kB。

这种”后端嵌进前端”的形态，和 PocketBase（Go 写的单文件服务器）、Supabase（托管 Postgres + 自动生成 API）形成有趣对照：PocketBase 追求的是一个独立的、开箱即用的小服务器，技术栈是 Go；Supabase 把你绑在它托管的 Postgres 上，换来成熟的实时订阅与权限体系；bknd 则刻意不做独立服务器，而是让后端代码成为你前端构建产物的一部分，跟着 SSR 应用或边缘函数一起发布。代价是它放弃了”一个稳定后端服务长期运行”的某些便利——比如长连接、后台常驻任务、跨请求的内存状态在无状态边缘函数上都要重新设计；收益则是部署单元极简、供应商切换成本极低。理解这个取舍，比记住它支持多少种数据库更重要。

三、必须看到的官方警告

这是本文最想强调的部分，全部来自官方原文：

  1. “We are in beta… don’t recommend production use yet”：文档首页黄色警告框明确说，在走向 v1 的过程中不建议生产使用；
  2. “full backward compatibility is not guaranteed before reaching v1.0.0”：README 警告，v1.0 之前不保证向后兼容，升级可能 break；
  3. Node 版本门槛极高：因为用了 node:sqlite，要求 Node.js 22.13 或更高，这把大量仍在 Node 18/20 的项目挡在门外；
  4. flows 的 UI 集成”coming soon”：工作流可视化编排界面尚未完成；
  5. 管理后台默认不设防：本地开发时后台默认开放且无认证（官方解释是为快速原型设计），一旦把它暴露到公网而忘记开启认证，就是典型的安全事故入口。

换句话说，bknd 的”灵活”和”轻量”目前主要兑现于原型与 MVP 阶段，而不是生产级托管后端。

四、优势与局限

优势：

  1. 真正跨运行时：从 Node 到 Bun、Deno 到 Cloudflare Worker，一份代码到处跑，这在 BaaS 里很少见；
  2. 不锁定数据库与存储：SQLite/Postgres 任选、S3 兼容存储任选，迁移自由；
  3. 体积小：约 300 kB gzipped，边缘部署友好；
  4. 为 AI Agent 时代预留：内置 MCP server，适合做 Agent 状态后端。

局限：

  1. 明确 beta、不建议生产：官方自己划的红线，企业落地需等 v1；
  2. 向后兼容无保证：版本快速迭代意味着升级成本；
  3. 运行时要求新：Node 22.13+ 在很多团队的 CI/容器镜像里尚未普及；
  4. 企业能力待验证：多租户 RLS、SSO、审计等在文档中是目标能力，成熟度与 Supabase 商业版有差距；
  5. 安全默认值需手动收紧：后台默认开放，生产部署必须显式开启认证并复查暴露面。

五、谁该用

  • 快速做 MVP / 原型的独立开发者：用 npx bknd run 几分钟拿到带后台的后端，非常顺手；
  • 想跑在 Cloudflare Workers / 边缘函数上的团队：它的体积与 Web 标准路线正中场景；
  • 需要为 AI Agent 搭状态后端的人：内置 MCP server 值得关注；
  • 正在找生产级、长期托管方案的企业：建议先用它做技术预研，正式产品请等 v1 或继续评估 Supabase/PocketBase。

参考来源