One person, one platform: how dracon.uk actually runs

dracon.uk looks like a small company: a games arcade, a music library, a bookstore, an AI hub, a paid subscription, a blog. It is one person and a rotating cast of AI agents. This is the machinery behind that, and everything here is verifiable in the public repo: the Caddyfile, the deploy scripts, and the catalog JSON.

Update (2026-08-24): the catalog snapshot numbers in this piece were accurate as of their publication dates but the music library has since grown — the wave-3 expansion took it from 100 cooks / 1,000 tracks (2026-08-01, when this was published) to 200 cooks / 2,000 tracks (2026-08-23) and now 250 cooks / 2,500 tracks (2026-08-24). Figures below are kept as written so the article stays reproducible against its own date; the closing platform callout is corrected to the current counts.

One VPS, one Caddyfile

Every request hits a single VPS running Caddy with Let's Encrypt TLS. The Caddyfile routes by path prefix. Five prebuilt SvelteKit apps (home, products, music, games, books) are served as static files from their build directories. Two dynamic SvelteKit apps — /ai-hub and the dashboard — run as Node processes behind unix sockets. No containers, no orchestrator, no load balancer, because there is nothing to balance. The file is infra/caddy/Caddyfile.prod, and changes ship through one script that validates and reloads.

Behind the web tier, five Rust APIs listen on unix sockets in /run/dracon/: auth, billing, email, ai, and music. Caddy picks by path: /api/v1/auth/* → auth-api.sock, /api/v1/billing/* → billing-api.sock, /api/v1/email/* → email-api.sock, /ai/* → ai-api.sock. They run as systemd units. At 2 a.m. the debug surface is one proxy config and five services — a surface one person can hold in their head.

The short list of things that cost money

• The VPS. One box runs the proxy, Node apps, and five Rust services. No autoscaling group — just headroom and a Caddyfile.
• Paddle for payments. Billing API receives Paddle webhooks at /api/v1/webhooks/paddle; Paddle is merchant of record, so we never touch card data.
• OVH object storage. One bucket (dracon-master, S3-compatible, UK) holds game builds and music audio. Caddy proxies it at /_game-cdn and /_music-cdn, adding CORS headers the bucket does not send.
• Notably absent: AI compute. Every AI feature runs browser-direct with your own key — see our pricing page — so token spend never hits our infra. That is why the sub can be $10 founding ($15 standard) with marginal cost ~$0.

The 12 products that prove the model

The product surface is the clearest test of solo scope. The catalog at web/products/src/lib/data/products-catalog.json lists 12 entries as of August 2026 — seven with dedicated service pages and five browser extensions. All are browseable at /products:

The seven detail pages — Tiles, SamAI, Folder Auto Banner, Dracon Warden, Dracon Sync, Kiki, and Dracon System — each explain the install and link to source. The five extensions share the /products index because their install lives in the Chrome Web Store and Firefox Add-ons. One catalog, one repo, no hidden SKUs.

Deploys: a daemon with commit access

The strangest piece is deploys, because there barely is one. Dracon Sync — dogfooded — watches the working tree, auto-commits within seconds, and pushes to three remotes: GitHub, GitLab, Codeberg. Production serves static apps from a plain git checkout; Caddy's root points at that checkout. The only special path is the Caddyfile itself, which ships via a script that validates and reloads. History is never rewritten — a commit can be pushed to three remotes before you finish typing amend, and auto-messages like '2 file(s) in src [...]' are expected, not noise to rewrite.

Why one person — and what stays human

Solo forces boring choices, and boring is maintainable. No team stands on call for the Rust APIs, no SRE owns the Caddyfile, no content team owns the catalogs — one person knows every socket and webhook. That is also a trust signal: the about page names the operator, the pricing page lists one tier without enterprise folds, and /methodology explains catalog capture. If you evaluate whether to trust a platform with a key or a repo, traceability matters more than headcount.

The division of labor is explicit: agents do production — games, books, tracks, articles like this — and the human does judgment. The roadmap's open errands waiting on a person are release-quality calls on two games, choosing bookstore genres, and a Google OAuth verification — not token wrangling or infra babysitting. Agents do not decide what ships; they make the decision possible.

What one person actually maintains

Catalog data tells the scale without varnish. The AI registry tracks 45 providers with prices and limits; the music library holds 2,500 tracks across 250 curated cooks (it was 1,000 tracks in 100 cooks when this was published); the games catalog tracks 16 projects from playable to placeholder; the bookstore holds five novels totaling 523,980 words from our pipeline; the products catalog lists 12 tools. No human curates daily churn by hand. The games arcade, music library, bookstore, and AI hub are all rendered from the same JSON the repo commits.

To inspect rather than take my word for it: /status shows live service state, /docs holds technical docs, /about is the one-person disclosure, and the pricing page is the business model in one tier. The stack is deliberately boring. Boring is what one person can run at 2 a.m., and what survives the next audit without a rewrite.

When solo breaks — and when it wins

• Solo breaks when judgment is needed asleep — a bad deploy can wait, a data-loss bug cannot. Mitigation is multi-remote push plus OVH streaming: even if the VPS dies, builds and audio survive in three git remotes and the bucket.
• Solo wins on coordination cost. No planning meeting, no ticket shuffle. A docs fix is one commit, one push, one checkout on prod — minutes, not a sprint.
• Solo wins on honesty. No 50-person roadmap to look fundable. The catch is the open errands list — games waiting on a quality call, genres waiting on a choice — and that list is shorter than a team would make it look.

What one person can and cannot promise

One person can promise craft and velocity. One person cannot promise 24-hour on-call, enterprise SSO next quarter, or a roadmap that satisfies every vertical. The honest pitch for a one-person platform is not 'we do everything' but 'we do a small number of things with unusual cohesion because they share a single taste.' Our surfaces reflect that: a games arcade that treats the browser as a first-class console, a music library where every track keeps its recipe, a bookstore where the AI label is on the tin, an AI hub that tracks 45 providers honestly, and products like Tiles, Warden, and Sync that solve problems the author had himself. The status page shows live service state without theatre, docs hold the technical documentation you can check before you pay, and the pricing page is a single tier because a one-person business cannot afford the support cost of tier logic — nor wants to.

Why the comparison site exists at all

Dracon builds comparison tools — VPS, domains, email, vector DBs, object storage — for a selfish reason: they are how we shop for ourselves. The catalogs behind them (384 domain rows, 12 VPS providers, 14 email APIs, 22 vector DBs) are captured from the same provider pages you would have to open manually, with provenance dates and per-row notes. Publishing them as tools is both a service and a discipline: if our own pricing is ever wrong, the same audit that catches a registrar's ICANN flag will catch ours. The editorial factory that produces this blog is the same idea at a smaller scale — articles are data in web/home/src/lib/data/articles so they can be regenerated when a catalog changes, rather than edited by hand until they drift. One person cannot out-staff anyone; one person can out-instrument the comparison.