bknd

Backend-as-a-service, honestly reviewed. Built for developers who want Firebase primitives without the vendor lock-in or the recurring bill.

TL;DR

• What it is: Open-source (Apache-2.0) backend-as-a-service that embeds directly into your existing JavaScript framework — data, auth, media, and workflows, without spinning up separate services [1][2].
• Who it’s for: TypeScript developers building MVPs, prototypes, or AI-agent backends who want Firebase-style primitives on infrastructure they own, including edge and serverless environments [1].
• Cost savings: Firebase’s Blaze plan charges per read, write, and storage byte. Supabase Pro is $25/mo. bknd self-hosted on a $6/mo VPS with your own SQLite or Postgres database costs effectively nothing beyond the server [1][2].
• Key strength: Runs inside your Next.js, Astro, or React Router app as an npm package — no separate backend service, no extra Dockerfile, no cross-service networking [1].
• Key weakness: Pre-v1.0 with an explicit no-backward-compatibility warning, cloud offering is waitlist-only with no published pricing, and there are no independent production case studies — this is simply a very new tool [1][2].

---

What is bknd

bknd is a backend system you install as an npm package. The GitHub description says it plainly: “Lightweight Firebase/Supabase alternative built to run anywhere — incl. Next.js, React Router, Astro, Cloudflare, Bun, Node, AWS Lambda & more” [1]. The homepage homepage puts it as: “Build Anything, Deploy Everywhere” [2].

What makes it architecturally unusual is the deployment model. Supabase self-hosted means running PostgreSQL, PostgREST, GoTrue, MinIO, and a Realtime service as separate Docker containers that your frontend calls over HTTP. bknd runs inside the same process as your application. You import it, configure it, and it handles the database layer, auth sessions, file storage, and workflow triggers as part of your framework’s runtime [1].

The four building blocks are Data (schema definition, REST API, row-level security), Auth (multiple strategy support, session management), Media (file management with pluggable storage adapters), and Flows (workflow automation — the UI is listed as “coming soon”) [1][2].

Runtime support is broad by design: Node.js 22+, Bun 1.0+, Deno, Browser (via SQLocal), Cloudflare Workers/Pages, Vercel, Netlify, AWS Lambda, and Valtown [1]. Database support covers SQLite variants (LibSQL, Node SQLite, Bun SQLite, Cloudflare D1, Cloudflare Durable Objects) and Postgres variants (vanilla, Supabase, Neon, Xata) [1]. All of this works because the project is built on the WinterTC Minimum Common Web Platform API, which provides the universal compatibility layer rather than per-environment shims [1].

Numbers as of this review: 3,707 GitHub stars, Apache-2.0 license, “Tech Preview” badge on the homepage [1][2]. The copyright on the website reads ”© 2026 Dennis Senn” — meaning this is, at present, a single-maintainer project [2].

---

Why people choose it

The honest answer is that published third-party reviews of bknd are nearly nonexistent. The tool appears in BaaS category listings alongside tools like Supabase and Appwrite [3], but there are no Trustpilot ratings, no head-to-head comparison articles, and no production post-mortems. The absence of third-party coverage isn’t inherently a negative signal — the tool is simply too new to have accumulated them. It means this review is evaluated primarily on design intent rather than demonstrated track record.

What does emerge from the README’s use-case framing:

Versus Firebase: Firebase is fast to start with but expensive at scale and structurally locked in — your data lives in Google’s infrastructure with no straightforward export path, and every read, write, and storage operation is metered. bknd’s Apache-2.0 license and adapter-based architecture are a direct answer to both problems. You own your data in a Postgres or SQLite database you control; switching underlying providers is an adapter swap, not a migration project [1].

Versus Supabase: Supabase is also open-source and self-hostable, but the self-hosted stack is heavyweight. The typical Docker Compose setup runs six or more services. bknd’s entire footprint as a deployed Cloudflare Worker is around 300 kB gzipped [1]. For a prototype or small product that doesn’t need Supabase’s full surface area, bknd’s minimal approach is a genuine advantage in time-to-deploy and infrastructure cost.

Versus PocketBase: PocketBase occupies the closest niche — single-binary, embeddable, self-hosted, no external dependencies. The difference is runtime: PocketBase is a Go binary running as a separate process; bknd is an npm package that lives inside your JavaScript framework. If your stack is TypeScript end-to-end, bknd shares types and tooling in a way PocketBase cannot.

The target use cases from the README: CMS, AI agent backends (with a built-in MCP server for state persistence), SaaS products with multi-tenant RLS, MVPs, API-first applications, and IoT devices where footprint matters [1].

---

Features

Based on the README and official documentation:

Data:

• Schema definition with a visual admin interface
• Full REST API auto-generated from schema [1]
• TypeScript SDK with type-safe queries [1]
• Row-level security (RLS) for multi-tenant data isolation [1]
• SQLite and Postgres adapters with direct driver access — no ORM abstraction forcing you into its limitations [1]

Auth:

• Multiple authentication strategies
• OAuth/OIDC via web platform standards [1][2]
• Session management integrated with the data layer for RLS [1]

Media:

• File upload, storage, and serving [1]
• Storage adapters: AWS S3, S3-compatible (Tigris, R2, Minio), Cloudflare R2 (native binding), Cloudinary, Filesystem, Origin Private File System [1]

Flows:

• Workflow engine for running automation [1]
• Can inject into system events [2]
• UI integration listed as “coming soon” [2] — the engine exists, the interface does not

AI / MCP:

• Built-in MCP server for AI agent state management [1]
• Explicitly designed as an AI agent backend for managing persistent state across runs, regardless of hosting environment [1]

Developer experience:

• npx bknd@latest run quickstart — local backend in under a minute [2]
• OpenAPI/REST API as the primary external integration surface [1]
• Modular and fully opt-in — only ship the pieces you use [1]
• Framework-native hot reload in dev servers [1]

Deployment targets: Standalone, Docker, Cloudflare Workers/Pages, Vercel, Netlify, Deno Deploy, AWS Lambda, Valtown [1].

What’s notably absent compared to Supabase: no real-time subscriptions, no database branching, no built-in edge functions beyond what your deployment platform provides.

---

Pricing: SaaS vs self-hosted math

bknd Cloud: Waitlist-only. No pricing published. The website promises “global scale with affordable prices” [2]. There is nothing to evaluate here yet.

bknd self-hosted (Apache-2.0):

• License: $0 [1]
• SQLite: $0 — a file on your server
• Managed Postgres: $5–20/mo on Neon, Supabase, or Xata free/starter tiers
• Hosting on Cloudflare Workers: $0 on the free tier for low-traffic apps
• Hosting on a VPS: $5–10/mo on Hetzner or Contabo

Firebase (Blaze, pay-as-you-go) for comparison:

• $0.06 per 100K Firestore reads
• $0.18 per 100K Firestore writes
• $0.026/GB storage/mo
• A project with 500K reads/day and 100K writes/day runs roughly $25–40/mo in database operations alone, before storage or bandwidth

Supabase for comparison:

• Free tier: 500MB database, 1GB storage, paused after 1 week inactivity
• Pro: $25/mo — 8GB database, 100GB storage, no pausing
• Team: $599/mo

Concrete math for an early-stage SaaS: Ten thousand monthly active users, a few hundred MB of data, regular file uploads. Supabase Pro: $25/mo. Firebase Blaze at meaningful read volume: $30–50/mo. bknd on a $6 Hetzner VPS with SQLite: $6/mo, no per-operation ceiling. The savings over twelve months are modest in absolute terms ($228–$528/year) but the absence of a scaling cliff is the point — your infrastructure cost doesn’t spike when a product hunt drives a traffic spike.

---

Deployment reality check

The quickstart is genuinely fast. npx bknd@latest run gives you a working backend locally in under two minutes [2]. Framework integrations for Next.js, React Router, Astro, and Vite mean you add bknd to an existing project like any other npm dependency [1].

For a production deployment, you need:

• Node.js 22.13+ (non-negotiable — the package uses node:sqlite requiring this version exactly) [1]
• A database: SQLite file for simple deployments, Postgres for anything with concurrent writes at scale
• A deployment target: Docker on a VPS, or a serverless platform
• Storage provider config if you need file uploads
• SMTP for email-based auth flows

What to watch for:

The README includes this warning in a yellow callout block: “bknd is still under active development and therefore full backward compatibility is not guaranteed before reaching v1.0.0” [1]. This is the most load-bearing sentence in the documentation. It means a minor version bump could change an API you depend on. For a prototype you’re happy to maintain: acceptable risk. For a production system serving paying customers: a real concern that doesn’t disappear because the README mentions it politely.

The Node 22.13+ requirement will surface on some managed platforms still running Node 18 or 20 LTS. Check your deployment target before you build.

The single-maintainer structure is visible in the copyright notice [2]. At 3,707 stars the project has community interest but hasn’t yet reached the contributor density that makes abandonment risk negligible. This isn’t a criticism — it’s the normal state for a tool at this stage — but it belongs in a production risk assessment.

Realistic time estimates: a developer with Docker experience can be running in production in 1–2 hours. A non-technical founder cannot meaningfully self-host this today — there’s no click-to-deploy wizard, no point-and-click admin setup, and no managed cloud offering to fall back on.

---

Pros and cons

Pros

• Apache-2.0 license. Genuinely permissive — no commercial licensing restrictions, no “fair-code” ambiguity. Embed it in a SaaS product you sell, fork it, rebrand it [1].
• Runs inside your framework. Not a sidecar service — lives in your app’s process. No cross-service networking, no extra Dockerfile, no proxy configuration [1].
• Universal JavaScript runtime support. Cloudflare Workers, AWS Lambda, Node, Bun, Deno, browser — if it runs JavaScript, bknd likely runs there. The 300 kB gzipped footprint makes edge deployments viable [1].
• Adapter-based architecture. Switch from SQLite to Postgres, from local filesystem to Cloudflare R2 — by swapping an adapter, not migrating your application code [1].
• MCP server built in. AI agent backends with persistent state work out of the box, without a separate integration layer [1].
• Fast to start. One npx command and you have a running backend locally [2].
• $0 licensing. Apache-2.0 means no license cost at any scale.

Cons

• Pre-v1.0, breaking changes possible. The README states this explicitly [1]. Treat it as beta.
• No managed cloud today. The cloud offering is a waitlist with no pricing, no SLA, and no launch date [2].
• Single maintainer. Bus-factor risk is real for a tool you’d build infrastructure on [2].
• No independent production reviews. No Trustpilot, no comparative benchmarks, no “we ran this in prod for a year” articles. Too new.
• Flows UI is missing. The workflow engine exists; the interface doesn’t [2].
• No real-time subscriptions. Firebase’s most-copied feature — live client sync — is not mentioned in the README or website.
• Node 22.13+ floor. Limits deployment options on platforms still running older LTS versions [1].
• Not for non-technical founders. No GUI installer, no managed option, no support tier. You need a developer.

---

Who should use this / who shouldn’t

Use bknd if:

• You’re a TypeScript developer building an MVP, prototype, or AI-agent backend and you want Firebase-style primitives on infrastructure you own.
• You’re deploying to Cloudflare Workers or another edge runtime where a full Supabase stack is too heavy to run.
• You want a backend that embeds in your framework rather than running alongside it — one codebase, one deploy, one process.
• You’re comfortable with pre-v1.0 software and can absorb breaking changes between minor versions.
• You need Apache-2.0 licensing to embed the backend in a product you commercialize.

Wait (or pick Supabase) if:

• You need real-time subscriptions — Supabase has mature Realtime support; bknd doesn’t mention it.
• You need a managed cloud option today. Supabase has a stable free tier and a Pro plan. bknd’s cloud is still a waitlist.
• Your team includes non-developers who manage data through a GUI. Supabase’s dashboard is production-grade; bknd’s admin story is less clear.
• You’re making a multi-year infrastructure commitment for a production app with real users. Wait for v1.0 and a larger contributor base.

Skip it (use PocketBase) if:

• You want a single-binary self-hosted backend with a polished admin UI, strong documentation, and a track record of production use. PocketBase is further along on all three.

Skip it (stay on Firebase) if:

• You need mobile SDKs, offline sync, push notifications, or Google Cloud integrations. bknd doesn’t compete on ecosystem breadth — only on portability and cost.

---

Alternatives worth considering

• Supabase — the obvious comparison. Managed cloud with a generous free tier, real-time subscriptions, excellent dashboard. Self-hosted stack is heavyweight (six+ Docker containers). Pro is $25/mo. Mature and production-proven.
• Firebase — Google’s BaaS. Unmatched mobile SDK support, offline sync, push notifications. Pay-as-you-go pricing that gets expensive at scale. Zero portability once you’re in.
• PocketBase — Go binary, embeddable, ships with a polished admin UI, excellent documentation, and production deployments in the wild. Not JavaScript-native, but further along than bknd for teams that just want it to work.
• Appwrite — more complete open-source Firebase alternative with auth, databases, functions, storage, and real-time. Larger self-hosted footprint (Docker Compose), but more mature and with a managed cloud tier.
• Directus — if your primary use case is a CMS or non-developer admin interface over a database, Directus is better suited. It’s production-proven and has a commercial cloud offering.
• Convex — TypeScript-native backend with reactive queries and ACID transactions. Managed-only (no self-host), but if you need real-time reactivity in TypeScript and are willing to pay for managed infrastructure, worth evaluating.

---

Bottom line

bknd is a genuinely interesting architectural bet: a backend that lives inside your JavaScript framework rather than beside it, with Apache-2.0 licensing, a 300 kB edge footprint, and a clean adapter system that means you’re never locked into a specific database or storage provider. For a TypeScript developer building a prototype or an AI-agent backend that needs to run on Cloudflare Workers, there’s a real case for it.

The “Tech Preview” label isn’t marketing copy — it’s a warning. No v1.0, no backward compatibility guarantee, no managed cloud, no third-party validation, no real-time subscriptions, and a single maintainer. For a personal project or a prototype you’re comfortable maintaining, none of that is disqualifying. For a production application with paying customers and a team that can’t absorb surprise breaking changes, this is a tool to watch closely over the next year, not one to bet on today. Check back when v1.0 ships and the cloud offering goes live with actual pricing.

---

Sources

1. bknd GitHub README — bknd-io/bknd, Apache-2.0, 3,707 stars. https://github.com/bknd-io/bknd
2. bknd Official Website — “Build Anything, Deploy Everywhere”. https://bknd.io
3. OpenAlternative — Open Source Projects using Deno — bknd listed under Backend-as-a-Service (BaaS) Tools. https://openalternative.co/stacks/deno