Your Website Is Your Homelab: The Split Architecture Behind aitherium.com

I had been building AitherOS for months before I realized something was wrong with my mental model. I thought aitherium.com was a static site. A GitHub Pages deployment. HTML, CSS, JavaScript — served from GitHub's CDN, no moving parts. And I was right.

I also thought demo.aitherium.com was the live version. A Cloudflare Tunnel punching through my NAT, routing internet traffic into Docker containers running on a single RTX 5090 machine in my apartment. Chat, agents, IRC, model inference — all live. And I was right about that too.

What I hadn't fully internalized was that these two things were both running at the same time, serving the same brand, and one was calling the other. The static site was the shell. The tunnel was the brain. Together they formed an architecture pattern that's genuinely hard to kill.

The DNS Split

Here's the part that makes it click. Run nslookup on both:

$ nslookup aitherium.com
→ 185.199.108.153  (GitHub Pages)
→ 185.199.109.153
→ 185.199.110.153
→ 185.199.111.153

$ nslookup demo.aitherium.com
→ 104.21.74.134   (Cloudflare proxy)
→ 172.67.203.38

Two completely different IP ranges. Two completely different infrastructure stacks. One is Microsoft's CDN (GitHub). The other is Cloudflare's edge network, tunneled back to a single physical machine.

The apex domain (aitherium.com) is an A record pointing to GitHub Pages. Every subdomain (demo., chat., irc., gateway., mcp., idp., 20+ more) is a CNAME proxied through Cloudflare, routed through a persistent tunnel into Docker.

How the Tunnel Works

There's a container called aitheros-tunnel running cloudflare/cloudflared:latest. On startup it does exactly one thing: opens four outbound QUIC connections to Cloudflare's nearest edge PoPs. In our case, LAX.

aitheros-tunnel:
  image: cloudflare/cloudflared:latest
  command: tunnel run
  environment:
    TUNNEL_TOKEN: "${CLOUDFLARE_TUNNEL_TOKEN}"

That's it. No port forwarding. No static IP. No firewall rules. No UPnP. The tunnel initiates outbound from inside Docker, and Cloudflare reverses traffic through it. From the outside, it looks like the services are hosted on Cloudflare's infrastructure. From the inside, it's just containers talking to containers on a bridge network.

Cloudflare's dashboard maps hostnames to internal Docker services:

24 hostnames total, all resolved through one tunnel, one container, four QUIC streams.

The Static Shell

When you visit aitherium.com, you're hitting GitHub Pages. It's a Next.js static export — built by a GitHub Actions workflow on every push to main, deployed to gh-pages branch, served through GitHub's CDN.

But here's the trick. At build time, the static export is compiled with these environment variables:

NEXT_PUBLIC_BACKEND_URL: 'https://demo.aitherium.com'
NEXT_PUBLIC_RELAY_WS_URL: 'wss://irc.aitherium.com/ws/chat'
NEXT_PUBLIC_RELAY_URL: 'https://irc.aitherium.com'

The static HTML renders instantly — the marketing pages, the feature descriptions, the blog (you're reading it). But the moment you open the chat interface or look at the live compute economy, JavaScript fires off API calls to demo.aitherium.com. Those calls traverse Cloudflare's network, enter the tunnel, hit the Docker containers, and stream responses back.

The visitor sees one website. Under the hood, they're talking to two completely separate infrastructure stacks simultaneously.

What Happens When Things Die

This is where the architecture earns its keep.

Scenario 1: The machine goes down. Power outage, reboot, Docker crash — doesn't matter. aitherium.com stays up because it's GitHub Pages. Visitors still see the landing page, the blog, the product tour. The live features — chat, pipeline status, compute economy, agent demos — fail gracefully. The JavaScript either gets a network error and shows a fallback, or the SSE stream just doesn't connect. The site doesn't 500. It doesn't white-screen. It degrades.

Scenario 2: GitHub Pages goes down. (Extremely rare, but humor me.) demo.aitherium.com keeps working. The chat, the API, the WebSocket relay, the agent system — all still live. Anyone with the direct URL or a bookmark can still use the full system. The apex domain is the only casualty.

Scenario 3: Cloudflare goes down. Both die. But if Cloudflare goes down, half the internet goes with it, so you've got bigger problems.

Scenario 4: You push a broken build. The deploy workflow has a fallback — if the Next.js build fails, it deploys a maintenance.html instead. The live backend is unaffected because it's a completely separate deployment pipeline (Docker Compose, not GitHub Actions).

The blast radius of any single failure is contained. The static and dynamic halves can break independently without taking each other out.

The Accidental Load Balancer

There's an nginx container (aither-veil-lb) sitting between the tunnel and the actual Next.js instances. It does DNS-based failover between a primary and standby Veil container:

location / {
    set $veil_primary http://aitheros-veil:3000;
    proxy_pass $veil_primary;
    error_page 502 503 504 = @standby;
}

location @standby {
    set $veil_standby http://aitheros-veil-standby:3000;
    proxy_pass $veil_standby;
}

If the primary Veil crashes during a rebuild, the standby catches requests automatically. Zero-downtime deployments on a single machine. The tunnel doesn't even know the failover happened — it still points to veil-lb:80.

Why This Pattern Is Underrated

Most indie projects face an impossible choice:

1. Static hosting (GitHub Pages, Netlify, Vercel): Free, fast, reliable, but no backend. Any dynamic feature requires a separate API, a separate deployment, a separate bill.

2. Self-hosting (VPS, homelab, bare metal): Full control, but fragile. Your server goes down, your site goes down. Your cert expires, your site goes down. Your ISP changes your IP, your site goes down.

The split architecture gives you both without the downsides of either. Your marketing, docs, and blog are unkillable — GitHub's CDN handles that. Your live features are self-hosted with zero infrastructure cost — Cloudflare Tunnel is free, Docker is free, your existing hardware is free. The two halves reference each other by domain name and fail independently.

The setup is absurdly simple:

1. Deploy a static site to GitHub Pages with a CNAME.
2. Run cloudflared in Docker with a tunnel token.
3. Point subdomains at internal services in Cloudflare's dashboard.
4. Hardcode the subdomain URLs into your static build's environment.

That's it. You now have a website that survives your machine being off, and a live backend that survives your website being broken. For free.

The Numbers

At the time of writing, the tunnel is routing traffic for 24 hostnames to 14 different internal services. It maintains 4 persistent QUIC connections to Cloudflare's LAX edge. The entire tunnel container uses ~30MB of RAM.

Behind it: 211 microservices, 16 AI agents, a model inference cluster, a knowledge graph, an IRC-style real-time chat system with AI personas, a code intelligence engine, and a training pipeline — all running on one machine, all accessible from any browser on the planet, all protected by Cloudflare Access SSO.

The monthly infrastructure cost for making all of this publicly accessible: $0.

The static site costs nothing (GitHub Pages). The tunnel costs nothing (Cloudflare's free tier). The DNS costs nothing (Cloudflare's free tier). The compute costs nothing beyond the electricity bill because it's hardware I already own.

Sometimes the best architecture is two things that don't know about each other, connected by a domain name.

Try It

• Static site: aitherium.com — the marketing shell, served from GitHub Pages.
• Live demo: demo.aitherium.com — the actual system, served from a machine in an apartment.
• IRC chat: irc.aitherium.com — real-time chat with AI agents. Tag @aither in #general.
• MCP Gateway: mcp.aitherium.com — connect your IDE directly.

If the live links are down, that means I'm rebooting. The static site will still be there. That's the whole point.