The headless CMS,
on your terms.

bincms gives your team a TypeScript-first schema, per-field localization, and full multi-tenancy — running entirely on infrastructure you own. No vendor lock-in. No per-seat pricing. No trade-offs.

Read the docs
Schema
TypeScriptdefineType / defineField
Runtime
Node + Honoedge-compatible
Studio
React + ViteTailwind v4 · Radix
License
MITfork it, ship it
01 · Schema

Your schema lives in your repo.

Content types are defined in TypeScript — no proprietary schema language, no YAML, no GUI-only configuration. Refactor it like any other code, review it in PRs, ship it with your build.

app/cms/types/product.ts TS 
// content types are TypeScript — reviewed in PRs, refactored like code
import { defineType, defineField } from 'bincms'

export default defineType({
  name: 'product',
  type: 'document',
  title: 'Product',
  fields: [
    defineField({ name: 'title',    type: 'string',   localize: true  }),
    defineField({ name: 'sku',      type: 'string',   localize: false }),
    defineField({ name: 'body',     type: 'richtext', localize: true  }),
    defineField({ name: 'gallery',  type: 'image',    array: true     }),
    defineField({
      name: 'category',
      type: 'content',
      options: { type: 'category' },
    }),
  ],
})
Per-field localization

Translate what you mean to translate.

One localize flag per field. Title varies per language; SKU stays global. The delivery API composes them automatically.

Clean lifecycle

Drafts are drafts. Published is published.

The delivery API only ever returns published data. No accidental leaks, no "preview mode" footguns.

Pluggable

Custom field types are React components.

Register a manifest in your workspace; it's bundled at build. No fork required.

02 · Capabilities

Built for teams that take content seriously.

Multi-tenancy, localization, custom fields, and clean API namespaces — not bolted on as paid add-ons, but designed in from the first commit.

F.01

You own your data

Runs wherever you want. No third party. No SaaS dependency. No per-seat pricing tied to a platform you can't leave.

self-hostedMIT
F.02

TypeScript schema, end-to-end

defineType / defineField — in your repo, in PRs, in your build. No proprietary DSL, no YAML, no GUI-only state.

type-saferefactorable
F.03

Per-field localization

One flag per field. Translate titles, share SKUs and media. The delivery API composes shared and localized fields for you.

localize: trueshared media
F.04

Multi-tenancy, built in

Every piece of data — content, media, globals, users, languages — scoped to a tenant. Hostname routing, role-based membership.

data isolationRBAC
F.05

Clean content lifecycle

Drafts are drafts. Published is published. Edit drafts freely; publish each language variant independently. No accidental leaks.

draft / publishedper-language
F.06

Three clean API namespaces

/management, /delivery, /workspace. No collisions, no backdoors. OpenAPI generated automatically.

OpenAPIScalar in dev
F.07

Pluggable by design

Custom field types and sidebar apps register as React components. Live in your workspace, bundled at build, no forking.

field pluginssidebar apps
F.08

Database-agnostic contracts

Storage is defined as TypeScript interfaces validated by a shared contract test suite. Swap drivers without rewriting.

contract testszero coupling
F.09

No bloat

Biome for lint & format. Hono for the server. React + Vite + Tailwind v4 for the studio. One sharp tool per job.

fast devsmall bundle
03 · Architecture

A monorepo of sharp, small packages.

Your application sits on top of a thin orchestration layer that picks the right storage driver at runtime. Storage contracts are interfaces — drivers implement them and pass a shared contract test suite.

Your workspace app/
Your schema, plugins, custom APIs, middleware. A single cms.config.ts declares types, globals, languages, and feature flags.
contracts    runtime selects driver
packages/ 11 packages · pnpm workspace
cms-studio Hono server + React SPA. The admin interface.
cms-ui Component library. Radix + shadcn + Tailwind v4.
cms-runtime Selects the right storage driver at runtime.
cms-storage Storage contracts. Interfaces only, no implementation.
cms-storage-sqlite SQLite driver. Default; passes the full contract suite.
cms-storage-postgres PostgreSQL driver.
cms-storage-mysql MySQL driver.
cms-storage-mssql MSSQL driver.
cms-utility Shared logging and env utilities.
cms-create Scaffold CLI — create-cms.
··· Each package is independently versioned and published.
04 · Comparison

How bincms stacks up.

The honest version. We're not trying to be every CMS — we're trying to be the right CMS for teams who care about owning their stack.

Feature bincms Sanity Contentful Strapi Payload Umbraco
Self-hosted Yes Cloud only Cloud only Yes Yes Yes
TypeScript schema First-class Yes No — Partial Yes No
Per-field localization Built in — Partial — Partial — Plugin — Plugin Yes
Multi-tenancy Built in — Enterprise — Enterprise — Plugin — Manual — Partial
Database choice SQLite + drivers Proprietary Proprietary Several PostgreSQL SQL family
No usage-based pricing Yes No No Yes Yes Yes
Plugin system React-native Yes Yes Yes Yes Yes
Delivery API REST + OpenAPI GROQ REST REST REST REST
05 · Storage

One contract. Multiple drivers.

Storage is defined as a set of TypeScript interfaces validated by a shared contract test suite. Pick your database with one environment variable.

SQLite Default driver. Zero-config. Perfect for single-node deployments and local development. cms-storage-sqlite Supported
PostgreSQL For teams scaling out across multiple nodes. Driver package available. cms-storage-postgres Driver available
MySQL Drop-in for stacks already running MySQL or MariaDB. cms-storage-mysql Driver available
MSSQL For Microsoft-shop deployments and existing SQL Server estates. cms-storage-mssql Driver available
env BINCMS_STORAGE_DRIVER=sqlite | BINCMS_SQLITE_FILE=app/cms/data/cms.sqlite
06 · Quick start

From zero to studio in three commands.

The scaffold sets up the workspace, installs the studio, and seeds an example schema so you can hit the ground running.

Step 01

Scaffold a new project

Creates the workspace, installs dependencies, and seeds an example schema.

Step 02

Run the studio

Starts the Vite dev server and the Hono API. Hot reload across schema, plugins, and UI.

Step 03

Build for production

Builds all workspace packages in dependency order. Output is a single Node app.

Ship the CMS
your stack deserves.

One command. Your schema, your database, your infrastructure — ready to ship in minutes.

Star on GitHub