I knew self-hosting was a thing, but I had never really looked into it.

That started to change after I moved to the United States and replaced my old HP Pavilion Gaming 15 with a Lenovo Legion 7. The Pavilion was around eight years old, slower than I wanted for daily use, and mostly sitting unused. Around the same time, I started working as a student technician in Network Operations. Some of the full-time staff would occasionally mention the services they hosted at home, which made me curious about what I could run myself.

YouTube picked up on that interest pretty quickly. My feed filled with homelab tours, Docker tutorials, self-hosted app recommendations, and people building full racks at home. I did not have the money, space, or hardware for anything like that. What I did have was an old laptop, so I decided to see how far I could get with it.

Starting with the hardware I already had

The Pavilion has an Intel i5-8300H, a GTX 1050, 16GB of DDR4 RAM, and a 512GB NVMe SSD for the operating system. It also had a separate 1TB hard drive for storage, which I later replaced with a 2TB drive.

It is not impressive hardware by modern standards, but that was part of the point. I wanted to find out whether I could make something useful from a computer I already owned instead of waiting until I could afford a better setup.

I named the server Olympus. I have used ZEUSGMJ as a username for a long time, so the name felt like a natural fit.

Installing Ubuntu was the easy part

I started by installing Ubuntu 24.04. That part was straightforward. Once the system was running, though, I realized I did not have much of a plan beyond turning the laptop into a server.

I began with SSH, firewall rules, and Samba for file sharing. They sounded like simple starting points, but each one introduced details I had not thought about. A configuration could look correct and still fail because of a permission, a path, or something else one layer away from the thing I was trying to fix.

At first, I would keep rereading the same instructions and checking the same file because I assumed I had missed a step. Usually, the better question was what the service depended on and whether that part of the system was working. That change in how I approached problems became more useful than any single command I learned.

How Olympus became useful

Olympus started as a place to experiment, but over time I began depending on some of the services I installed. It now handles media, file storage, personal productivity tools, and whatever else I want to test.

The stack still changes, but these are the main pieces:

Not every service matters in the same way. Some are tools I use regularly. Others are experiments that stayed around because I wanted to keep learning how they worked.

I currently keep the whole setup private instead of exposing services to the public internet. When I am away from home, Tailscale lets a trusted device connect to Olympus without opening public ports. Once the request reaches the server, Nginx Proxy Manager sends it to the correct service. That gives me clean internal URLs instead of making me remember a different port for every app. Cloudflare handles DNS and SSL.

The firewall follows the same approach. Devices connected through Tailscale are allowed, local network access is enabled where I need it, and everything else is blocked by default.

Docker made the setup manageable

I chose Docker Compose because I did not want to install every application and its dependencies directly on Ubuntu. Each service could have its own container, configuration, and storage while the host stayed relatively clean.

The basic workflow did not take long to learn:

docker compose up -d
docker compose logs -f <container-name>
docker exec -it <container-name> sh

Starting a container was rarely the difficult part. What confused me was understanding what the container could see and how that differed from the host. One of my early mistakes was not planning volume mounts carefully. A wrong path could make an application write data somewhere I did not expect, and then I had to trace through what the container thought its filesystem looked like.

Networking had a similar learning curve. Some services worked fine on Docker's default bridge network. Others needed a different setup depending on which containers they had to reach. Docker networking was not impossible, but every application seemed to make slightly different assumptions about its environment. I had to understand those assumptions before the configuration started to make sense.

A failing drive changed how I thought about storage

The first major problem with Olympus was not Docker or networking. It was the original 1TB hard drive beginning to fail.

Replacing it forced me to rebuild parts of the setup and move the data to a new 2TB drive. I already understood why backups mattered in theory. Dealing with a failing drive in the middle of the project made the risk much less abstract.

It also made me more deliberate about where data lives. The exact layout has changed over time, but it currently follows this general structure:

/mnt/olympus/
├── docker/      # container configs and compose files
├── media/       # media libraries
└── data/        # app-specific persistent data

There are still things I want to improve, especially around backups. But having a predictable layout means I can usually tell where a service keeps its configuration and persistent data. When something breaks, I have a better starting point than searching the whole system and hoping I recognize the right file.

Most of the learning happened when something broke

Before building Olympus, I assumed most of the learning would come from installing services. I ended up learning more from debugging them.

Most problems were small on their own: a wrong path, a missing permission, a firewall rule, or two services that could not reach each other. The commands I returned to were usually basic ones:

docker compose logs -f <container-name>
grep "something" file.log
sudo ufw status verbose
docker exec -it <container-name> sh

The harder part was figuring out which layer was actually failing. I might assume an application was broken when the real issue was its volume mount. Another time, I might blame the network when the problem was inside the container configuration.

Going slower helped. Instead of changing several things and hoping one of them worked, I started checking one layer at a time: is the service running, can it see its files, can it reach what it depends on, and is the firewall allowing the connection? That process saved me more time than repeatedly starting over.

How I understand self-hosting now

Olympus did not turn me into a sysadmin overnight. It gave me a system I cared enough about to understand.

Linux became less intimidating once I used it to run something I depended on. Docker started to make sense when I stopped treating containers like black boxes and paid attention to their files, networks, and processes. Networking became easier to picture once local access, Tailscale, the reverse proxy, ports, and firewall rules all had to work together.

I also understand the responsibility behind self-hosting better now. Running an application is only one part of it. I am also responsible for its storage, permissions, updates, backups, network access, and recovery when something fails. In my case, maintaining those surrounding pieces is where most of the useful learning has happened.

Olympus later became part of Mind Your Stack, a cybersecurity project where I explored outbound network behavior in self-hosted application stacks. Having a real environment made the security questions more concrete. Even a small home server has containers, networks, configuration files, background services, and external connections. Running my own stack made me look more carefully at what those applications were doing beyond the interface I could see.

What I want to improve next

Olympus is still a work in progress. The next things I want to explore are:

• better backup planning
• monitoring and alerts
• security hardening with tools like Fail2ban or CrowdSec
• possibly trying Proxmox
• eventually moving to a small, cleaner homelab rack

For now, the old Pavilion is still enough. It runs services I use, gives me a place to experiment, and keeps showing me which parts of Linux, Docker, and networking I do not understand as well as I thought.

Resources

These are some of the places I have found useful while learning about self-hosting:

• https://awesome-docker-compose.com/
• https://www.linuxserver.io/our-images
• https://selfh.st/apps/
• https://github.com/awesome-selfhosted/awesome-selfhosted
• https://trash-guides.info/