We Built This Website Ourselves

A question we get occasionally is what the website is built on. The answer is pretty unglamorous: it's hand-written HTML and CSS, served by a small Node.js HTTP server, proxied through Nginx, and hosted on our own infrastructure in a Pterodactyl egg. That's it. No framework, no CMS, no build pipeline.

That might sound like the hard way to do it, and in some respects it is — but it also means we have complete control over every pixel, every byte that gets sent to your browser, and how fast the page loads. There's no WordPress core, no plugin ecosystem, no database query slowing down your first paint. It's just files on disk being served over HTTP.

The stack

The actual serving layer is about as minimal as you can get. A Node.js script reads files from disk and responds to HTTP requests:

const http = require('http');
const fs = require('fs');
const path = require('path');

http.createServer((req, res) => {
  let file = req.url === '/' ? '/index.html' : req.url;
  fs.readFile(path.join(__dirname, file), (err, data) => {
    if (err) { res.writeHead(404); res.end(); return; }
    res.writeHead(200);
    res.end(data);
  });
}).listen(process.env.PORT || 3000);

That runs inside a Pterodactyl server using a custom egg. Nginx sits in front of it and handles SSL termination, compression, and proxying. The Pterodactyl egg means we can manage the website process the same way we manage game servers — start, stop, restart, file manager access, console output. It's a familiar interface for us and it works.

Why not just use a static host?

We could have used Netlify or Cloudflare Pages and it would have taken ten minutes. But we run our own infrastructure. Hosting our own website on it is partly a practical decision (we already have the hardware) and partly a point of principle — if we're going to tell customers that our infrastructure is reliable enough to run their servers on, the least we can do is run our own stuff on it too.

The site is hosted on the same nodes as our game servers. If you can reach this page, the infrastructure is up.

The CSS approach

The styling is a single stylesheet shared across all pages, built on CSS custom properties for theming. No preprocessor, no utility framework — just vanilla CSS with a clear naming convention. It keeps the codebase small and means any of us can make changes without needing a build step. The fonts are loaded from Google Fonts (Syne for headings, DM Sans for body) and that's the only external dependency the frontend has.

It's not the most sophisticated setup in the world, but it loads fast, it's easy to maintain, and it's ours. Sometimes that's enough.

← Back to Blog