DEV Community: Gerwin Weiher

Building a standalone CMS admin with Hono and vanilla CSS glassmorphism

Gerwin Weiher — Sat, 16 May 2026 15:17:39 +0000

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.

I built a CMS that fits in one file — here's why and how

Gerwin Weiher — Tue, 14 Apr 2026 13:15:59 +0000

Every CMS I've tried for Astro comes with the same overhead: a database to provision, a media CDN to configure, an auth service to wire up. For small sites and personal projects, that's a lot of ops for not a lot of content.

So I built Orbiter — a CMS where everything lives in one .pod file. Content, media, schema, users, sessions. All of it.

The idea

your-site/
├── astro.config.mjs
├── content.pod    ← your entire CMS
└── src/pages/

The .pod extension is just SQLite. You can open it with any SQLite browser. Copy it, your whole site moves with it. Back it up with cp.

Setup

npm install @a83/orbiter-integration

// astro.config.mjs
import orbiter from '@a83/orbiter-integration';

export default defineConfig({
  output: 'server',
  integrations: [orbiter({ pod: './content.pod' })],
});

That's it. Orbiter injects a full admin UI at /orbiter using Astro's injectRoute — no files added to your src/pages.

Reading content

The virtual module mirrors Astro's own content collection API:

---
import { getCollection, getEntry } from 'orbiter:collections';

const posts = await getCollection('posts');
const post  = await getEntry('posts', 'my-first-post');
---

For multilingual sites there are getLocaleCollection and getLocaleEntry helpers using a slug--locale convention.

What's in the admin

Collection editor — rich text (Markdown + live preview), all common field types
Schema editor — add or change fields without migrations
Media library — stored as BLOBs directly in the pod
Version history — every save creates a snapshot
JSON API — GET /orbiter/api/[collection] with optional Bearer token
Import — WordPress WXR and Markdown files
GitHub sync — for serverless environments where the filesystem is ephemeral
PWA — the admin is installable on mobile

The tradeoffs I'm honest about

SQLite BLOB storage is convenient but not for large media libraries. If you have thousands of high-res images, this isn't the right tool. For a typical content site it's fine.

Serverless filesystems are ephemeral. Netlify and Vercel don't persist writes between deploys. The GitHub sync mode works around this — pack your pod and media into a git commit, rebuild on push — but it adds steps. I'm still not 100% happy with this DX.

WAL mode helps with concurrent reads but SQLite is still SQLite. For a site with hundreds of simultaneous admin users this is the wrong choice. For a team of 1–5 editing content, it's perfectly fine.

Why not Keystatic / Decap / Tina?

All great tools. The difference: they store content as files in your git repo, which means your database is your git history. That's a valid approach but it means every content change is a commit, and media files bloat your repo fast.

Orbiter's approach is the opposite: one binary blob, no git history for content, trivial to move.

Try it

git clone https://github.com/aeon022/orbiter.git
cd orbiter && npm install && npm run seed && npm run dev

Admin at http://localhost:8080/orbiter — login: admin / admin

Or scaffold a new project:

npm install -g @a83/orbiter-cli
orbiter init my-site
cd my-site && npm install && npm run dev

GitHub: https://github.com/aeon022/orbiter