The story of this website

I enjoy working close to infrastructure. Not because it’s fashionable, but because that’s where artificial limits tend to disappear. When you control the system, you stop adapting to tools and start shaping them to your needs.

This site was never meant to handle enterprise traffic, global scale, or run on managed platforms. It’s a simple static website, and in that context, self-hosting at home is a perfectly reasonable choice. The goal was never just to build a website. The goal was to build something small, controlled, and operationally simple.

I spent more time than expected deciding what to build it with. The requirements were intentionally modest. I wanted a static-first output, minimal runtime complexity, full control over the generated assets, and no framework-imposed conventions. Astro was the obvious choice. It stays out of the way, produces predictable output, and doesn’t force an entire frontend ecosystem on you.

The site itself runs in Docker. Nothing elaborate. A single container that builds and serves static assets. The original idea was straightforward: Docker, a reverse proxy like Caddy or NGINX, and public DNS pointing directly to my home IP. That setup works, but it never felt right. Exposing a residential IP, opening inbound ports, and treating a home network as a public service boundary is not something I wanted to normalize.

I already knew the alternative from past experience behind CGNAT. Cloudflare Tunnel fits this use case well. It runs in Docker, requires no inbound ports, and removes direct exposure of the host entirely. For a project like this, it’s the right trade-off.

The server hosting the site is deliberately locked down. SSH access is tightly restricted, there are no exposed administrative interfaces, and the attack surface is kept as small as possible. There are no quick fixes through remote logins. This approach worked well until it started getting in the way of development. The moment I wanted to make changes away from home, the setup became a productivity bottleneck. That’s usually a sign that the access model is wrong.

What was missing wasn’t more access, but better automation. A self-hosted GitHub Actions runner turned out to be the cleanest solution. Deployment is intentionally boring. The runner pulls the repository, resets to the main branch, and runs docker compose with a build. Everything happens directly on the server, without SSH sessions or manual intervention.

The result is exactly how I expect production systems to behave. I can push changes from anywhere, the server remains locked down, and deployments happen through a controlled and traceable process.

Cloudflare Pages would have been an excellent fit for this site. I chose not to use it, not because it’s inferior, but because convenience wasn’t the goal. The goal was to practice a full CI/CD workflow locally, end to end, without relying on managed cloud platforms. This setup is about operational discipline, not zero-maintenance hosting.

The only thing explicitly backed up is the repository itself. Everything else is disposable by design. There’s no dedicated monitoring for the website. If it goes down briefly, that’s acceptable. This isn’t a revenue-critical service, and it doesn’t pretend to be one.

This is my first public website. I intentionally went for a restrained, lightweight design, which turned out to be the hardest part. Most of the time wasn’t spent on infrastructure or automation, but on spacing, layout, and visual balance. There’s no framework magic here, just iteration until it felt right.

This setup optimizes for minimal operational risk, no exposed infrastructure, predictable deployments, and full ownership of the stack. It does not optimize for instant scale, zero maintenance, or convenience over control. That’s a deliberate choice.

The site is small, but it’s treated like a service. Automation comes first. Access is reduced rather than expanded. Boring, inspectable systems are preferred. Convenience is not confused with safety. That mindset scales better than any tool.