Building
UPLINK.

UPLINK started as a technical experiment. I wanted one small, clean platform that could combine a real website with the infrastructure behind many of my network experiments.

But the more I worked on it, the more obvious it became that the useful part wasn't the infrastructure itself. It was everything I was learning while building it.

So instead of leaving another server running somewhere with no context attached to it, I decided to turn it into a place where I can document the things I actually work with.

01. Why build another site?

Most of my notes traditionally end up scattered between terminal history, screenshots, chats, configuration files and documents.

That works surprisingly well until I need to reproduce something six months later.

UPLINK is an attempt to create that documentation without turning it into a formal knowledge base.

The idea is simple: write about real projects, including the decisions, failed approaches and small details that are usually missing from finished tutorials.

02. The idea

The site sits at the intersection of several things I work with every day: digital marketing, analytics, AI and infrastructure.

Those subjects may look unrelated, but in practice they increasingly overlap.

Modern analytics depends on infrastructure. Advertising depends on measurement. AI is becoming part of everyday workflows. And reliable networks sit underneath almost everything.

That's why UPLINK isn't intended to be exclusively a networking blog or a marketing blog.

It's a collection of practical experiments around technology I actually use.

03. Architecture

The first version deliberately uses a very small stack. There is no CMS, database or application server involved.

The public website itself is simply static HTML and CSS served by Nginx.

This is intentional. For a personal site there is very little reason to introduce a database and a large application stack before they're actually needed.

04. The website as part of the system

Initially the web server existed only as a minimal endpoint. A page saying “It works” was enough to prove that everything around it was functioning.

Technically that solved the problem. Practically it wasn't very interesting.

Turning the endpoint into an actual website made the whole project more useful. The same infrastructure can now host documentation, experiments and notes while remaining extremely lightweight.

The design follows the same idea. There are no large frameworks on the client, no tracking scripts and no unnecessary dependencies.

For now, the browser mostly receives HTML and CSS. That's enough.

05. Things I've learned

One recurring lesson from infrastructure projects is that individual components are rarely the difficult part.

DNS works. TLS works. A web server works. Network services work.

The interesting problems appear at the boundaries between them.

A configuration can be perfectly valid by itself and still fail because another service owns the same socket, expects a different transport or handles the connection in an unexpected way.

The most useful troubleshooting method has therefore been surprisingly boring: reduce the system to small pieces and verify each boundary independently.

It's slower than guessing for the first five minutes and considerably faster than guessing for the next five hours.

06. What's next

The current site is intentionally simple. The next step is turning the static pages into a small publishing system.

Articles should eventually live as Markdown rather than hand-written HTML, while the final site remains static and lightweight.

I also want to document some of the other systems I'm currently working with: server-side analytics, small ARM servers, home networking and practical AI workflows.

UPLINK itself will probably continue changing as those experiments evolve.