bknd: a self-hosted Firebase alternative that runs inside your framework

What bknd replaces, and who it is actually for

Most backend-as-a-service products make you choose between hosting your data with them or rebuilding auth, media handling and an admin panel yourself. bknd sits in the middle. The README describes it as a general purpose backend system that implements the primitives almost any backend needs, and lists content management systems, AI agent backends, multi-tenant SaaS products, prototypes, API-first applications and IoT devices as intended uses.

The target reader is a TypeScript developer who already has a database and a deploy target in mind. bknd does not sell you storage. It ships adapters for SQLite variants (LibSQL, Node SQLite, Bun SQLite, Cloudflare D1, Durable Objects SQLite, SQLocal) and for Postgres (vanilla, Supabase, Neon, Xata), plus storage backends including S3 and S3-compatible services, Cloudflare R2, Cloudinary, the filesystem and OPFS. You bring the infrastructure; bknd brings the API layer, the admin UI and the SDK.

The framing in the README is explicitly anti-lock-in: functionality is modular and opt-in, and infrastructure access is adapter-based with direct access to the underlying drivers. That matters if you have been burned by an abstraction that hides the query planner or the connection pool. It also means you own the operational work that a hosted service would absorb.

The four packages and how requests flow through them

The repository splits the published package into four import paths, and the README documents each one. `bknd` and `bknd/adapter/*` contain the backend and its adapters. `bknd/ui` holds the admin UI components for React frameworks. `bknd/client` is the TypeScript SDK and React hooks for the API endpoints. `bknd/elements` provides React components for authentication and media.

A request path is straightforward. The backend is mounted as a route in whatever runtime you deploy to, whether that is a standalone process or a route inside Next.js, React Router, Astro, Vite or Waku. It exposes a REST API under `/api/`. The README shows the shape of a data read as `curl -XGET <your-endpoint>/api/data/entity/<entity>`, so entity access is namespaced under `/api/data/`. The admin UI is a React component that talks to the same API, and the SDK wraps it for typed clients.

The design constraint behind all of this is the WinterTC Minimum Common Web Platform API. Building on that subset is what allows the same code to run on Node, Bun, Deno, workerd and Lambda. The trade-off is real: anything outside that common surface has to be reached through an adapter rather than imported directly.

The README also notes an MCP server, client and UI built in, which lets an agent drive the backend. It does not document the MCP transport or its tool surface, so treat that as something to inspect in the source before you depend on it.

Installing bknd and serving a first API route on Node

The README points to https://docs.bknd.io for documentation and examples, and the repository carries runnable examples under `examples/` for node, bun, deno, astro, nextjs, react-router, cloudflare-worker, aws-lambda and others. The Node path is the shortest.

First, confirm your runtime. The package.json sets `"node": ">=22.13"`, and the README repeats the warning that Node.js 22.13 or higher is required because of `node:sqlite`. Install the package:

npm install bknd

Then create an entry file that starts the standalone server. The README's Node example is exactly this:

import { serve } from "bknd/adapter/node"
serve();

Running that file starts the backend and its REST API. From there, the README shows how to read an entity over HTTP, which is the first call worth making to confirm the server is up:

curl -XGET <your-endpoint>/api/data/entity/<entity>

Replace the placeholder with your own host and an entity name you have defined. If you would rather work in a browser, the README links a live demo hosted on StackBlitz with the path `/data/schema`, which is the schema view of the admin UI.

For a React framework, the admin UI mounts as a component. The README gives this Vite example, including the stylesheet import:

import { Admin } from "bknd/ui"
import "bknd/dist/styles.css";

export default function AdminPage() {
   return <Admin />
}

What you should see is the admin interface rendering against your configured backend. The README does not document the configuration keys for connecting a database or a storage adapter, so the next step is the docs site or the matching example directory.

Bundle size, the pre-1.0 warning, and where bknd is the wrong choice

The README is unusually candid about size. The npm badge is described as misleading, because the `bknd` package contains the backend, the UI components and the whole backend bundled into the CLI including static assets. The README states that the minimal size of a full bknd app as an API is around 300 kB gzipped, for example deployed as a Cloudflare Worker. That is the floor, not the ceiling: the README notes that size rises as additional dependencies are pulled in depending on what you use.

The harder constraint is versioning. The README carries a warning block stating that bknd is still under active development and that full backward compatibility is not guaranteed before reaching v1.0.0. The most recent release listed is v0.20.0 from 2026-01-09, with v0.19.0 before it in October 2025. A minor-version bump in a pre-1.0 project can move things, and nothing in the README promises otherwise.

bknd is the wrong tool when you need a frozen API contract across a long-lived product with no appetite for migration work, or when your runtime is not on the supported list. It is also a poor fit if you want the vendor to run the database: bknd assumes you have one, and choosing the wrong adapter is your problem, not theirs. The README's own framing, that you might not be aware of a backend system's limitations until you encounter them, applies to bknd too.

How bknd differs from Supabase and PocketBase

Supabase and bknd both give you Postgres, auth and a REST layer, but the deployment model is the opposite. Supabase is a platform you run or subscribe to, with its own dashboard, its own connection pooling and its own set of services. bknd is a library and a CLI. You add it to an existing application, mount it as a route, and it uses the database and storage you already have. There is no separate control plane to operate.

PocketBase is closer in spirit: a single binary with an embedded SQLite database, an admin UI and auth. The difference is the embedding model. PocketBase runs as its own process next to your app. bknd runs inside the app, which is why the README can list Next.js, React Router, Astro, Vite and Waku as frameworks and Cloudflare Workers, Vercel, Netlify, Deno Deploy and AWS Lambda as deploy targets. If your frontend and backend need to ship as one artifact, that distinction decides the choice.

The cost of bknd's approach is that you assemble more of the stack yourself. PocketBase hands you a binary; bknd hands you a package that needs a database adapter, a storage adapter and a runtime that satisfies Node 22.13 or the Web Standards subset. Whether that is a feature or a chore depends entirely on how much you want to own.

Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-23, so the codebase is being touched. That does not change the versioning situation: the README's own warning about backward compatibility before v1.0.0 is the number that governs your upgrade budget. Plan for reading release notes between minor versions rather than assuming a drop-in bump.

bknd is licensed under Apache-2.0, with the licence text in `LICENSE.md` at the repository root. Apache-2.0 is a permissive licence that includes an explicit patent grant, which is generally friendlier to corporate adoption than a bare MIT licence. It does not, however, cover the services you connect bknd to. If you use Supabase, Neon, Xata, Cloudinary, AWS S3 or Cloudflare R2 as adapters, those terms apply separately on top of bknd's. Nothing here is legal advice; check the terms of each provider you wire in.

The repository is a Bun workspace, with `packageManager` set to `[email protected]` and workspaces declared for `app` and `packages/*`. If you plan to contribute rather than consume, that is the toolchain you need, and `CONTRIBUTING.md` is the entry point.

Editorial conclusion

Adopt bknd if you are building a prototype, CMS or API-first app on Node 22.13 or newer and you want the admin UI, REST API and TypeScript SDK in one Apache-2.0 package you control. Do not adopt it if you need a stable API surface: the README warns that full backward compatibility is not guaranteed before v1.0.0, and the latest release listed is v0.20.0 from 2026-01-09. Before committing, check that your target runtime is on the supported list, confirm your database adapter exists for the driver you actually use, and read the release notes for the version you pin.

Frequently asked questions

Official sources

1. bknd-io/bknd on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases