Orbiter Documentation

A single-file CMS for Astro. Everything in one .pod file — content, media, schema, users, config.

What is Orbiter?

Orbiter is a headless CMS built around a single SQLite database. The database has a .pod extension and contains everything your CMS needs. Copy the file and your entire site moves with it. Back it up with cp. Move it between servers with rsync.

Two packages share the pod file:

@a83/orbiter-admin — a standalone Hono server that runs the admin UI on port 4322. Reads and writes the pod. Runs independently from your Astro site.
@a83/orbiter-integration — an Astro integration that reads published content from the pod at build time and makes it available via orbiter:collections. Zero runtime database access.

Packages

Package	What it does
`@a83/orbiter-admin`	Standalone admin server — Hono, port 4322, vanilla JS + CSS UI
`@a83/orbiter-integration`	Astro integration, `orbiter:collections` virtual module, media serving
`@a83/orbiter-core`	SQLite engine, pod management, auth, media backends
`@a83/orbiter-cli`	`orbiter init`, `add-user`, `export`, `pack`, `unpack`

How content flows

Edit in admin (port 4322)
       ↓
  content.pod   ← shared SQLite file
       ↓
Astro build reads pod
       ↓
Static HTML deployed anywhere

The admin writes. Astro reads once at build time and inlines all published entries as a JavaScript module. No database calls at runtime — the public site is fully static.

Tradeoffs

Orbiter is the right fit for content sites with a small team and a moderate media library. It is not the right choice if you need:

Live content without rebuilding (use SSR mode when available, or a headless CMS with a CDN)
Thousands of high-res images (use the GitHub, S3, or R2 media backend instead of the default BLOB storage)
Large editorial teams editing the same entry simultaneously (last-write-wins, no merge)