For a while the Orbiter admin lived inside the Astro integration. It was convenient — one package, one deploy, no extra process to manage. It was also wrong.
The admin ran as Astro SSR routes under /orbiter on the same domain as the public site. That meant every time you rebuilt the site, the admin routes were part of the bundle. It meant you couldn't deploy the admin separately from the content. It meant the admin's session cookies were scoped to the same origin as your public pages. And it meant anyone who wanted to run the admin on a subdomain, a separate VPS, or a Docker container couldn't.
So I extracted it. The admin is now @a83/orbiter-admin — a standalone Hono server that reads and writes a .pod file, runs on its own port, and has no dependency on Astro at all.
This is how it works.
Architecture: one file, two processes
The core abstraction in Orbiter is the .pod file — a SQLite database with a .pod extension that holds everything: content entries, media BLOBs, schema definitions, users, sessions, site config. The file is the CMS.
content.pod ← the entire CMS in one file
├── _collections schema definitions
├── _entries content entries (slug, data as JSON, status)
├── _media files stored as BLOBs
├── _users admin accounts
├── _sessions auth sessions
└── _meta site config (name, url, etc.)
Two processes share this file:
┌─────────────────────────┐ ┌──────────────────────────────┐
│ Orbiter Admin │ │ Astro Site │
│ @a83/orbiter-admin │ │ @a83/orbiter-integration │
│ Hono · port 4322 │ ←── │ Vite virtual module │
│ reads + writes pod │ pod │ reads pod at build time │
└─────────────────────────┘ └──────────────────────────────┘
The admin writes. The Astro integration reads — once, at build time — and inlines the content as a JS module. No runtime fetch, no API calls from the browser. The public site is static.
This separation means you can run them anywhere:
admin.mysite.com ← Orbiter Admin (Docker, Railway, your VPS)
mysite.com ← Astro site (Vercel, Netlify, static host)
They just need to share the pod file. On the same server that's trivial. Across services it means a shared volume or periodic rsync.
Hono as the API server
I chose Hono for two reasons: it's fast, and its API is simple enough that the entire server fits in one file without boilerplate.
The server is about 80 lines. Here's the core:
import { serve } from '@hono/node-server';
import { serveStatic } from '@hono/node-server/serve-static';
import { Hono } from 'hono';
import { cors } from 'hono/cors';
import { authRoutes } from './routes/auth.js';
import { entryRoutes } from './routes/entries.js';
import { mediaRoutes } from './routes/media.js';
import { collectRoutes } from './routes/collections.js';
import { metaRoutes } from './routes/meta.js';
const app = new Hono();
const POD = process.env.ORBITER_POD;
if (!POD) { console.error('ORBITER_POD not set'); process.exit(1); }
app.use('*', cors({ origin: process.env.ADMIN_ORIGIN?.split(',') ?? '*', credentials: true }));
app.use('*', async (c, next) => { c.set('podPath', POD); await next(); });
app.route('/api/auth', authRoutes);
app.route('/api/collections', collectRoutes);
app.route('/api/media', mediaRoutes);
app.route('/api/meta', metaRoutes);
app.get('/health', c => c.json({ ok: true, pod: POD }));
app.use('/*', serveStatic({ root: './public' }));
serve({ fetch: app.fetch, port: Number(process.env.PORT ?? 4322) });
The pod path is injected into every request via c.set('podPath', POD) and read in route handlers via c.get('podPath'). No global state, no singleton database connection — each request opens and closes the pod. better-sqlite3 is synchronous, so there's no async connection pool to manage.
Route handlers look like this:
// GET /api/collections/:name/entries
entryRoutes.get('/:name/entries', requireAuth, (c) => {
const db = openPod(c.get('podPath'));
const entries = db.listEntries(c.req.param('name'));
db.close();
return c.json(entries);
});
Simple, predictable, no surprises.
Why not Express?
Express would have worked, but Hono's Context API makes it easy to pass state through middleware without globals, and its built-in serveStatic handles the admin's HTML/CSS/JS files without extra packages. The edge-native design also means the same code could run on Cloudflare Workers someday if the pod were replaced with a D1 database.
CSS glassmorphism without a build step
The admin UI has no build step. No Tailwind, no PostCSS, no Vite processing the CSS. The styles are a single style.css file loaded directly by the HTML pages — changes are instant, and anyone can read the CSS without a sourcemap.
The glassmorphism effect uses three CSS features: backdrop-filter, color-mix(), and CSS custom properties.
backdrop-filter
.card {
background: color-mix(in srgb, var(--surface) 72%, transparent);
backdrop-filter: blur(18px) saturate(1.4);
-webkit-backdrop-filter: blur(18px) saturate(1.4);
border: 1px solid color-mix(in srgb, var(--line) 60%, transparent);
border-radius: 16px;
}
backdrop-filter blurs everything behind the element. Combined with a semi-transparent background (color-mix with transparent), you get the frosted glass effect. saturate(1.4) punches the colors through the blur slightly.
Browser support is now good across the board. Safari has supported it since 2015 (with the -webkit- prefix), Chrome and Firefox since 2019.
color-mix()
color-mix(in srgb, #fff 60%, transparent) is the native CSS way to create semi-transparent colors without writing rgba() values. It's particularly useful for theming because you can mix theme variables:
.glass-border {
border-color: color-mix(in srgb, var(--accent) 25%, transparent);
}
As the theme changes (via data-theme attribute), var(--accent) resolves to a different color, and color-mix automatically produces the right semi-transparent version. No JavaScript needed to update the border.
The animated orb background
The glass layout has animated radial gradient orbs behind the cards. They're ::before / ::after pseudo-elements on the body:
body.glass::before {
content: '';
position: fixed;
inset: 0;
z-index: 0;
background:
radial-gradient(ellipse 60% 50% at 20% 30%,
color-mix(in srgb, var(--accent) 18%, transparent) 0%,
transparent 70%),
radial-gradient(ellipse 50% 60% at 80% 70%,
color-mix(in srgb, var(--accent-2) 14%, transparent) 0%,
transparent 70%);
animation: orb-drift 12s ease-in-out infinite alternate;
pointer-events: none;
}
@keyframes orb-drift {
from { transform: translate(0, 0) scale(1); }
to { transform: translate(3%, 2%) scale(1.04); }
}
Pseudo-elements keep the markup clean — no wrapper divs, no JS-managed canvas.
The theme system
The theme is controlled entirely by three attributes on <html>:
<html data-theme="space" data-scheme="dark" data-style="glass">
-
data-theme—space|zen|catppuccin -
data-scheme—dark|light -
data-style—glass|classic
CSS custom properties are scoped to attribute selectors:
/* Space dark */
[data-theme="space"][data-scheme="dark"] {
--bg: #0a0e1a;
--surface: #111827;
--text: #e2e8f0;
--accent: #38bdf8;
--accent-2: #818cf8;
--line: #1e293b;
--muted: #64748b;
}
/* Space light */
[data-theme="space"][data-scheme="light"] {
--bg: #f0f6ff;
--surface: #ffffff;
--text: #0f172a;
--accent: #2563eb;
--accent-2: #7c3aed;
--line: #e2e8f0;
--muted: #94a3b8;
}
Every component uses the variables — color: var(--text), background: var(--surface), border-color: var(--line). Changing the theme is just changing two attributes. No JavaScript class toggling, no re-rendering, no flash of wrong theme.
Persistence is three lines:
const theme = localStorage.getItem('orbiter-theme') ?? 'space';
const scheme = localStorage.getItem('orbiter-scheme') ?? 'dark';
const style = localStorage.getItem('orbiter-style') ?? 'glass';
document.documentElement.setAttribute('data-theme', theme);
document.documentElement.setAttribute('data-scheme', scheme);
document.documentElement.setAttribute('data-style', style);
This runs synchronously in a <script> tag in <head> before the body renders, so there's no flash of the default theme on load.
The theme switcher writes to localStorage and sets the attributes:
function applyTheme(theme, scheme, style) {
const h = document.documentElement;
h.setAttribute('data-theme', theme);
h.setAttribute('data-scheme', scheme);
h.setAttribute('data-style', style);
localStorage.setItem('orbiter-theme', theme);
localStorage.setItem('orbiter-scheme', scheme);
localStorage.setItem('orbiter-style', style);
}
3 themes × 2 schemes × 2 layout modes = 12 combinations from one function call and a few hundred lines of CSS.
Animated SVG favicon and orbit logo
The orbit logo is an SVG with two rotating ellipses — one tilted slightly left, one tilted slightly right — around a central circle:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 40 40">
<!-- Central dot -->
<circle cx="20" cy="20" r="3" fill="currentColor" opacity=".9"/>
<!-- Outer ring — horizontal ellipse -->
<ellipse cx="20" cy="20" rx="17" ry="6"
fill="none" stroke="currentColor" stroke-width="1.5" opacity=".7"
transform="rotate(-15 20 20)">
<animateTransform attributeName="transform" type="rotate"
from="-15 20 20" to="345 20 20" dur="4s" repeatCount="indefinite"/>
</ellipse>
<!-- Inner ring — vertical ellipse -->
<ellipse cx="20" cy="20" rx="17" ry="6"
fill="none" stroke="currentColor" stroke-width="1.5" opacity=".5"
transform="rotate(75 20 20)">
<animateTransform attributeName="transform" type="rotate"
from="75 20 20" to="435 20 20" dur="6s" repeatCount="indefinite"/>
</ellipse>
</svg>
Two <animateTransform> elements drive the rotation — one at 4s, one at 6s, so the rings drift in and out of phase. The rings share currentColor so they inherit whatever color the surrounding context sets — in the nav it's the accent color, on the login screen it's white.
The favicon is the same SVG served at /favicon.svg. Modern browsers support animated SVG favicons. The tab icon actually spins.
For the login screen the logo is scaled up to about 60px and centered. The animation has more visual weight at larger sizes — the rings appear to orbit each other, which is the point.
What's next
The standalone admin shipped in v0.1.x. v0.2.0 added a real block editor — inline image blocks with float alignment, video embedding (YouTube/Vimeo/mp4), and server-side cloud URL import (Dropbox/Google Drive/OneDrive). See the v0.2.0 release notes for the full details, and this article for the block editor implementation.
v0.3.0 is focused on infrastructure:
- Build webhook — publish an entry → Orbiter fires a webhook → Astro rebuilds. The missing link between the admin and the static site.
-
Pluggable media backends —
local,github(files in a GitHub repo, served via jsDelivr CDN),s3(Cloudflare R2, Backblaze B2, AWS). The BLOB-in-SQLite default stays for simple setups; the backends are the escape hatch.
Further out: a demo instance at demo.orbiter.sh, a documentation site, and potentially a hosted version for teams who don't want to self-host.
The full source is at github.com/aeon022/orbiter.
git clone https://github.com/aeon022/orbiter.git
cd orbiter && npm install && npm run seed
ORBITER_POD=$(pwd)/apps/demo/demo.pod npm run dev --workspace=packages/admin
# → http://localhost:4322 username: admin password: admin
Issues and PRs welcome.