Most developers outsource their web presence to platforms like GitHub Pages, WordPress, or Wix. But I wanted more. I wanted full control over every aspect of my site, from the design and features to the hosting and security. So I built it myself, from the ground up.

Why?

Well, to understand why, you also need to understand a little bit about me. I’m an avid self-hoster, with a passion for building and managing my own services. I’ve been doing it for years, and I’ve learnt a ton from it. Due to my love for self-hosting, I have managed to amass a large collection of self-hosted apps, resulting in a ton of URLs stored in my browser’s bookmarks.

This was a problem. But it also sparked an idea. An idea that spiraled into many more…

What if I had a single dashboard that I could use to access all my self-hosted apps?

A dashboard that was not only functional, but also looked good and reflected my personal style?

A dashboard that was secure, so that only I (and anyone else I choose) could view internal apps?

A dashboard that was more than just a dashboard, but also a portfolio and a blog, where I could share my thoughts and showcase my projects?

What if I could build my own platform?

What?

A platform. A hub that I can do anything public-relations related. Blog posts, project showcases, a portfolio, contact information, and much, much more. It gives me a framework in which I can share my thoughts easily and effectively, and display my skillset.

It is:

A Portfolio — A curated summary of my experience, projects, and skills. The heart of the site.
A Blog — A Markdown-powered blog where I can write about projects, tech, and whatever else catches my interest.
A Projects showcase — A Markdown-powered projects section where I can give a targeted summary of my work with descriptions, tech stacks, links, and any supporting blog posts.
A Dashboard — A unified view of all my self-hosted apps, with dynamic access control powered by Authelia.
Secure — Powered by Authelia’s OIDC component, allowing me to control exactly who can see what through group-based filtering. The authentication API is designed to be reusable, but right now the dashboard is the main protected surface so that internal service links are only shown to the people who actually need them.

How?

So, that’s the idea, and that’s what it became. But how did I actually build it? What does it look like under the hood?

The Architecture

At a high level, my platform is built as a containerised, modular web app:

A Vue + Vite frontend for speed and flexibility
A Node.js backend acting as a lightweight server and auth layer
Docker to tie it all together into a portable and easily deployable package

This keeps it clean, scalable, and maintainable, whilst also being easy to deploy whether it’s on my homelab or somewhere else entirely.

Content and Markdown

One of the nicest parts of the project is that most of the written content lives in Markdown files. Blog posts and project pages are turned into generated manifests at build/dev time, which means the frontend can load content quickly without hardcoding metadata all over the app.

The Markdown pipeline is intentionally a bit conservative:

Frontmatter is parsed from each file and validated when manifests are generated
Invalid dates, duplicate slugs, and malformed metadata are warned about early
Rendered Markdown supports the features I actually use most, like code blocks, footnotes, task lists, and tables
Raw HTML is intentionally disabled in rendered Markdown for safety, so content stays predictable and doesn’t quietly expand the app’s XSS surface

That last point matters more than it sounds. Since the site renders Markdown into the page, being strict about what the renderer accepts is a really easy way to avoid security problems later.

Runtime Configuration

Another important design choice is that the website isn’t configured purely at build time. A lot of the site can be changed through runtime JSON config:

portfolio details
dashboard items
theme values
background behaviour
debug options

That means I can tweak the content and presentation without rebuilding the whole frontend every time. For a self-hosted project, that makes the site much nicer to operate.

Authentication and Access Control

The authentication setup is also more self-contained than a typical reverse-proxy-only solution.

Instead of relying on proxy-injected headers, the backend validates bearer tokens itself using the OIDC provider’s JWKS. In practice that means:

the frontend handles the login redirect flow with PKCE
the API receives a bearer token from the client
the API verifies the token cryptographically
protected dashboard items are filtered per-user based on group membership

That makes the backend more portable, because it doesn’t depend on a very specific proxy auth setup to remain correct.

Where It Is Now

What started as “I need a better way to open my services” turned into something much broader:

a portfolio
a writing platform
a project showcase
a private dashboard
a reusable authentication pattern
a space to experiment with UI, infrastructure, and self-hosting ideas

And honestly, that’s what I like most about it. It’s not just a website. It’s a platform that reflects how I build things: carefully, curiously, and with a strong preference for understanding the whole stack.