How This Site Works (and Why I Built It)

Every site like this seems to eventually publish a post about itself, so here's mine. If you've ever wondered what this thing actually is, how it works, or why I bothered building it instead of using something off the shelf, this is the post for you.

What this site is

At its core, The Default Gateway is a place for me to dump my notes.

I work in IT, and I'm constantly learning things — how to configure a service, how to set up a piece of hardware, how a protocol actually works once you get past the textbook definition. For years those notes lived in scattered text files, a note-taking app, the back of my brain, and the occasional sticky note I immediately lost. When I needed something six months later, I could never find it.

So I built a home for them. Everything you see here — the homelab guides, the certification notes, the longer project write-ups — started life as a plain note I wrote for myself. The site is really just those notes, cleaned up a little and made public in case they're useful to someone else. If you've ever solved a problem by stumbling onto some stranger's blog post at 2 a.m., you already understand the spirit of it.

The core idea: I write Markdown, it becomes a website

Here's the part I'm most happy with, and it's genuinely simple.

I write everything in Markdown. If you haven't come across it, Markdown is just plain text with a few lightweight symbols for formatting — a # for a heading, asterisks for *emphasis*, dashes for lists. It's the same format a lot of note-taking apps use under the hood. It's fast to write, it stays readable even as raw text, and it doesn't lock me into any particular app.

When I want to publish something, I write a Markdown file, drop it into the right folder, and that's basically it. The site picks it up and turns it into a proper web page — with the navigation, the styling, the code blocks, all of it — automatically. There's no admin panel I have to log into, no "new post" button, no copy-pasting into a text box in a browser. I write a file, and a page appears. Writing a new note genuinely feels the same as writing any other note; the website part happens on its own.

That was the whole goal. I wanted the friction between "I learned something" and "it's published" to be as close to zero as possible, because the moment publishing feels like a chore is the moment I stop doing it.

How it's put together (the light version)

I'll keep this part brief and mostly jargon-free, since this is a blog post and not a manual.

The site is what's called a static site. That's worth explaining because it's the single decision that shapes everything else.

A lot of websites build each page on the fly, the moment you visit — there's a server somewhere running code and talking to a database to assemble the page just for you. That's powerful, but it's also more moving parts, more that can break, and more that needs looking after.

A static site works differently. Every page is built ahead of time into plain, finished files — the web equivalent of printing a document once and handing out copies, rather than rewriting it fresh for every person who asks. When you visit, you're just handed a page that already exists. It's faster, there's far less that can go wrong, and there's no database sitting around for me to maintain or worry about.

The "turn my Markdown into finished pages" job is handled by a tool called Next.js, which is a popular framework built on React (the technology a huge chunk of the modern web is built with). I don't want to oversell my own involvement here — I'm not doing anything clever. Next.js reads my notes, applies the design I built, and spits out the finished site. I mostly just had to wire it up and then get out of its way.

The design itself I built from scratch rather than using a pre-made theme, mostly because I wanted the site to feel like mine and because building it myself was half the point — I learn a lot more from making something than from downloading it finished.

Where it lives

Once the site is built into those finished pages, it needs to live somewhere the internet can reach. I host it on a service that specializes in serving static sites quickly and cheaply, sitting behind a layer that handles the domain, the security certificate, and some protection against the usual background noise of the internet.

The nice practical upshot: I make a change, save it, and a couple of minutes later it's live. No manual uploading, no fiddling. I've wired it up so that publishing is genuinely just "save the file."

The little extras

A few things on the site exist purely because they were fun to build rather than because anyone needed them:

• There's a small terminal tucked into the interface. If you find it, you can poke around with a handful of commands, browse the site's content the way you'd navigate a folder on a real machine, and — if you go looking — turn up a couple of hidden things. It started as a "could I even do this?" experiment and I liked it too much to remove it.
• The whole thing has a bit of a command-line, terminal-inspired look, which felt right for a site that's mostly about the kind of work that happens in a terminal anyway.

None of it is essential. But a personal site should have a little personality, and these are mine.

Why not just use an existing platform?

Fair question. There are plenty of services that would let me publish notes without building anything, and honestly, for a lot of people those are the right call.

I went the build-it-myself route for two reasons. The first is that I wanted to own the thing end to end — my notes are plain text files in a folder, not locked inside someone else's app, and if any single piece of this ever goes away I can pick everything up and move it elsewhere. The second, and the bigger one, is that building it taught me an enormous amount. Nearly every guide on this site about web technologies, hosting, and the surrounding tooling exists because I had to learn that exact thing to get this site working. The site is, in a real sense, a byproduct of learning to build the site.

What's next

Right now the project lives privately, but I plan to put the whole thing out in the open before too long, so anyone curious can see exactly how it's wired together — or lift the parts of it they find useful for their own site. When I do, I'll write a follow-up walking through it properly.

Until then: thanks for reading. If something on this site helped you out, that's precisely what it's here for.