Skip to main content

Products · The Dracon team

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 catalogs are all checked in.

One VPS, one Caddyfile

Every request to dracon.uk terminates at a single VPS running Caddy, which auto-provisions Let's Encrypt TLS for the apex domain. The Caddyfile routes by path prefix. Five prebuilt SvelteKit apps (home, products, music, games, and books, the last re-listed on 2026-08-01) are served straight from their build directories as static files. Two dynamic SvelteKit apps, /ai-hub and the dashboard, run as Node processes behind unix sockets. That is the entire web tier: no containers, no orchestrator, no load balancer, because there is nothing to balance.

Behind the web tier, five Rust APIs listen on unix sockets in /run/dracon/: auth, billing, email, ai, and music. Caddy picks the socket by path: /api/v1/auth/* goes to auth-api.sock, /api/v1/billing/* to billing-api.sock, and so on down the file. They run as ordinary systemd units. When something breaks at 2 a.m., the debugging surface is one proxy config and five services, which is exactly what one person can hold in their head.

The short list of things that cost money

  • The VPS itself. One machine runs the proxy, the Node apps, and all five Rust services.
  • Paddle, for payments. The billing API owns subscriptions and receives Paddle webhooks at /api/v1/webhooks/paddle; Paddle is the merchant of record, so we never touch card data.
  • OVH object storage. One bucket (dracon-master, S3-compatible, UK region) holds game builds and music audio. Caddy reverse-proxies it at /_game-cdn and /_music-cdn, adding the CORS headers the bucket does not send on its own.
  • Notably absent: AI compute. Every AI feature runs browser-direct with the user's own provider key, so token spend never touches our infrastructure. That is why the subscription can be $10.

Deploys: a daemon with commit access

The strangest piece is the deploy pipeline, because there barely is one. A sync daemon (dracon-sync) watches the working tree on the development machine, auto-commits changes within seconds, and pushes to three remotes: GitHub, GitLab, and Codeberg. The production server then serves the static apps out of a plain git checkout on the host; the Caddyfile's root path points at that checkout. Caddyfile changes themselves go through one script that copies the file up, substitutes the root path, validates, and reloads. The consequence for anyone working in the repo: history is never rewritten, because a commit can be pushed to three remotes before you finish typing the amend command.

What one person actually maintains

The catalog data tells the scale story: 42 AI provider entries with prices and rate limits, 1,000 music tracks organized into 100 curated cooks, 16 game projects tracked from playable down to placeholder (one fully playable today, a pipeline pushing the rest up), five novels totaling 523,980 words generated by our own book pipeline, and 12 products in the tools catalog. No human maintains that by hand. The operating plan is explicit about the division of labor: AI agents do the production work (games, books, tracks, articles like this one), and the human's job is judgment. The roadmap's open-errands list makes the point dryly: release-quality calls on two games, choosing bookstore genres, and a Google OAuth verification are the items waiting on a person, not on compute.

If you want to inspect the result rather than take my word for it: /status shows the live service state, /docs holds the technical documentation, and the pricing page is the whole business model in one tier. The stack is deliberately boring. Boring is what one person can run.