Provenance:

This article was written with the assistance of Watson, my primary conversational AI assistant.

I occasionally use Watson to help transform project logs, research notes, conversations, and technical documentation into structured articles. For process write-ups, technical retrospectives, and documentation-heavy pieces such as this one, the challenge is often organizing large amounts of context into something clear, readable, and useful.

The project itself, the decisions, successes, mistakes, observations, and conclusions documented here are my own. Watson's role is editorial: helping synthesize information and present process-led work in a more coherent form.

I view AI much like I view an IDE, a compiler, or a calculator—a tool that extends my ability to think, document, and communicate, without replacing ownership of the underlying work.

In the interest of transparency, any article produced with substantial assistance from Watson or other AI systems will be explicitly marked as such.

There is a certain stereotype surrounding homelabs.

The moment someone says the words home server, most people imagine a rack full of blinking lights, thousands of rupees in networking equipment, and a middle-aged system administrator who spends weekends arguing about filesystems.

I certainly did.

Which is why it is mildly ironic that one Friday evening, my friend Avi and I ended up building one.

Not because we wanted to become system administrators.Not because we wanted to self-host our entire lives.And certainly not because we wanted to spend hours staring at terminal output.We built it because Avi wanted somewhere to keep his files.But hey, that's not all.

Why Do I Need A Home Server?

Avi is a music creator. Like most people who create things on computers, his digital life had slowly become a mess.

Courses lived on one device. Projects lived on another. Media files existed in duplicate. Some things were on cloud storage. Some things were on external drives. Some things were simply lost to history. Nothing was catastrophic.

Everything was mildly inconvenient. The problem was not storage. The problem was fragmentation. Every file existed somewhere. But the challenge? Remembering where.

For months I had been mildly obsessed with infrastructure, self-hosting, and the idea of building systems that reduced friction rather than adding more of it. Avi meanwhile, was a, well, normal human creating music.

So naturally, convincing him took some effort.

Convincing the Average Person to Setup a Homelab

Most homelab discussions begin with technology. This one didn't. It began with use cases.

Imagine uploading a file from your phone and having it available everywhere. Imagine opening a course on your tablet without transferring anything. Imagine having your own media library (in Layman terms, your own Netflix/YouTube with only your content) accessible across devices. Imagine not paying recurring subscriptions for functionality that you could host yourself.

The more we discussed it, the more obvious it became. This wasn't a project for enthusiasts. It was infrastructure for ordinary life. The irony lay in the fact that most people already own everything they need. The average laptop sitting in a drawer contains vastly more computing power than entire organizations possessed a few decades ago.

The problem isn't hardware. The problem is realizing that the hardware can do more than browse the internet.

Eventually Avi agreed, which immediately created a new problem. Now we actually had to build the thing.

What Really Takes to Build A Homelab

The machine itself was unremarkable. No rack. No enterprise hardware. No server chassis. Just a laptop. A perfectly ordinary laptop with roughly 400GB allocated for the project.

And that's one of the first lessons I learned through this process:

You don't need impressive hardware to build useful infrastructure. You need hardware that exists. The best server is often the one already sitting in your room.

Initially we considered Ubuntu Server. Like most people entering the Linux world, Ubuntu felt like the obvious choice. Predictably, we changed our minds halfway through.

Instead, we settled on Rocky Linux. Not because of an elaborate decision matrix nor it's enterprise requirement but mostly because it seemed stable, interesting, and different enough to justify trying. Sometimes curiosity is sufficient justification.

Getting Going

Installation went smoothly for approximately ten minutes and then we encountered partitions.

Like every beginner who discovers filesystem architecture for the first time, we immediately began overengineering things.

Custom mount points. Dedicated storage structures. Grand plans for future scalability.

For a brief period, I was attempting to create a storage topology more appropriate for a datacenter than a laptop sitting on a desk.

Thankfully reality intervened. The final partition structure was remarkably simple:

/boot/efi
/boot
/
/swap

And, unsurprisingly, it worked perfectly. This would become a recurring theme throughout the project. Every time we attempted sophistication, simplicity quietly won.

What We Were Actually Building

Before touching a single Linux installation image, it is worth understanding what the final system was supposed to look like.

One of the biggest mistakes beginners make when approaching homelabs is thinking in terms of software rather than systems.

At a high level, the architecture looked something like this:

Laptop
│
├── Rocky Linux
│
└── Docker
    │
    ├── Homepage
    ├── Uptime Kuma
    ├── Nextcloud
    ├── Jellyfin
    └── Vaultwarden

Each component served a specific purpose.

• Rocky Linux would act as the operating system and provide the foundation on which everything else ran.
• Docker would allow us to package each service into isolated containers, ensuring that applications remained independent and easy to maintain.
• Nextcloud would become the central storage layer. Files uploaded from one device would automatically become available everywhere else.
• Jellyfin would act as the media layer, allowing courses, videos, films, and other content to be streamed across devices.
• Vaultwarden would securely store passwords and credentials while synchronizing them between devices.
• Homepage would become a simple dashboard from which every service could be accessed.
• Uptime Kuma would monitor the health of the system and tell us when something inevitably broke.

Finally, all of this would be connected through Tailscale, creating a private network that allowed remote access without exposing the server directly to the internet.

Setting Up Docker

Up until this point, we were configuring an operating system. The next step would be setting up a platform for our homelab to operate on.

Before deploying anything, we spent some time discussing whether we should install services directly onto the host machine or isolate everything somehow. Neither of us wanted a system where every new application modified the server itself, left dependencies scattered across the operating system, and turned future maintenance into an archaeological expedition.

Docker solved that problem elegantly. Every service would live inside its own container. If something broke, we could rebuild it. If we wanted to move the entire setup to another machine someday, we could simply carry over the configuration and data directories. More importantly, it gave us a common language for every service we planned to deploy.

Each service would eventually have three things:

• A Docker image
• A configuration file (docker-compose.yml)
• A persistent data directory

This separation turned out to be incredibly useful because it meant applications could be recreated without losing data.

Whether it was Nextcloud, Jellyfin, Vaultwarden, Homepage, or Uptime Kuma, the workflow remained largely the same:

docker compose up -d

A few lines of configuration, a container image, a mounted data directory, and simply a new service existed.

We therefore proceeded with setting up Docker on standard instructions. This was the first step we took towards setting up the base for our homelab's infrastructure

When It Stopped Feeling Like Software

One of the biggest conceptual shifts occurred unexpectedly. Initially I thought we were installing services.

Nextcloud. Jellyfin. Vaultwarden. Homepage.

Simple enough.

Then I realized that an important thought one could have was that we were actually designing relationships between services and the distinction is what gives homelabbing its beauty.

Nextcloud wasn't merely cloud storage. It was the central synchronization layer.

Jellyfin wasn't merely media streaming. It was the consumption layer for content stored elsewhere.

Vaultwarden wasn't just a password manager. It was a trust boundary.

Homepage wasn't a dashboard. It was an operational surface.

Everything connected to everything else.

And once that realization occurred, the project stopped feeling like software installation. It started feeling like systems engineering.

The Services

1. Dashboard: Homepage

The first visible service was Homepage. At first glance, Homepage appears trivial.

A dashboard with links.

But after deploying several containers, it quickly became indispensable. Infrastructure becomes much easier to manage when there is a single location from which everything can be accessed.

Server Monitor: Uptime Kuma

Arguably one of the least exciting yet most useful additions. Monitoring is boring. Until something breaks. And eventually something always breaks.

Private Cloud Database: NextCloud

Nextcloud followed shortly afterward. The entire project existed because of Nextcloud. Everything else was supporting infrastructure.

For Avi, this was the first genuinely transformative service. Files stopped belonging to individual devices and became part of a shared ecosystem.

Rather than storing documents independently on every device, devices became clients of a shared storage system. The server held the data. Everything else synchronized with it.

Personal Media Server: JellyFin

This was where the idea became tangible. Watching a film, series or course stream from a server sitting elsewhere in the house feels surprisingly satisfying. Technically it isn't very different from streaming content from a commercial platform. Psychologically it is completely different. Ownership changes the experience.

Password Manager: VaultWarden

A password manager is one of those services that immediately becomes essential once you have it. Especially when it integrates across devices. And especially when you control it, because nobody should be sneaking into your passwords, should they?

The Finishing Basics

Not Linux. Not Docker. Not networking. The laptop.

More specifically:

Sleep. Suspend. Power management. Lid-close behavior.

It turns out that laptops are optimized for being laptops.

Disabling suspend. Preventing automatic sleep. Ensuring services survived reboots. Configuring Docker restart policies.

Not very glamorous, but things to keep in mind we turned off.

Tailscale: How Everything Clicks Together

The most elegant decision we made was adopting Tailscale.

Before Tailscale, remote access felt complicated.

Domains. Port forwarding. Firewall rules. Networking tutorials.

After Tailscale:

Everything simply worked. Technically, Tailscale creates a private mesh VPN between devices.

Devices separated by kilometers appeared as though they were sitting on the same network regardless of physical location and the complexity of setting up portforwarding completely vanished.

Now with this, considering the standard Free Tier of Tailscale, you can share your device among 6 different users sharing the same remote server each connecting an unlimited amount of devices into their personal home server systems. Just one physical device serving it all.

What We Actually Built

By the end of the process, we had not built a homelab in the traditional sense. We had built an expansible private digital ecosystem.

A mere laptop had become:

• a cloud storage platform,
• a media server,
• a private password manager,
• and a centralized access layer.

Useful not just for one user but for multiple users sharing the same physical storage. And usefulness is the only metric that ultimately matters.

The Real Lesson

People often assume homelabs are about technology. AI LLMs, Automations, Code Servers, and what not. I no longer think that's true. Homelabs are rather much more about ownership.

Ownership of data. Ownership of workflows. Ownership of systems. Ownership of learning.

The commands can be learned. The software can be installed. The hardware can be acquired.

What matters is the mindset that emerges afterward.

You stop asking:

What application should I install?

And begin asking:

What problem am I trying to solve?

That shift changes everything.

What We Didn't Build

One of the more interesting outcomes of this project was realizing how little we actually needed.

Spend enough time around homelab communities and it becomes easy to believe that the natural progression is endless expansion. More services. More containers. More dashboards. More automation. More complexity.

At some point the infrastructure begins serving itself rather than its users. We deliberately tried to avoid that trap.

Throughout the project there was a constant temptation to install "just one more thing." A new dashboard. Another monitoring system. A recommendation from a YouTube video. A container that solved a problem neither of us actually had.

The internet is full of homelab screenshots containing dozens of services. Many of them are genuinely impressive. Many are also rarely used.

We wanted something different.

Every service we deployed had to answer a simple question:

Who is going to use this, and what problem does it solve?

If the answer wasn't obvious, it didn't get installed.

That's ultimately why the final stack remained surprisingly small. Nextcloud existed because Avi needed centralized storage. Jellyfin existed because his immense chunk of media was becoming difficult to organize across devices. Vaultwarden existed because password management is genuinely useful. Homepage existed because managing services becomes easier when everything has a single entry point.

Beyond that, we stopped.

Not because we ran out of ideas, but because we had already achieved the original objective. The only thing perhaps, we'd want to extend further, would be setting up an ad blocker and a VPN, but for Avi, uBlock Origin and Cloudflare WARP still do the job.

Therefore note that good infrastructure is not measured by how much of it exists. It is measured by how much of it gets used.

If we expand this system in the future, it will likely be in the same spirit as the original build: slowly, deliberately, and only when a genuine need emerges. Better backups. More storage. Improved reliability. Perhaps a few carefully chosen services.

Not because homelabbing is the goal. Utility is.

So, How Hard Can It Get?

Honestly?

Much easier than most people think.

The internet has done an excellent job convincing people that self-hosting is an activity reserved for specialists.

It isn't.

If you can follow documentation, tolerate occasional frustration, and remain curious when things break, you can build useful infrastructure.

You do not need enterprise hardware. You do not need a networking certification. You do not need years of experience. You need a reason.

For us, that reason was simple. Avi wanted a better place for his files. That was the entire justification.

No grand vision of self-sovereign infrastructure. No ambitions of building a miniature datacenter. No obsession with uptime statistics or enterprise architecture. Just a practical problem that deserved a practical solution.

By the end, we had certainly built a server. But more importantly, we had built understanding on why ownership matters, and Why so much of modern technology feels fragile—not because the software is bad, but because we have become increasingly disconnected from the systems that support our digital lives.

The most surprising part is that none of this required extraordinary hardware, advanced expertise, or a professional background in IT.

It required curiosity. A spare laptop. A willingness to break things.

And perhaps most importantly, someone willing to sit beside you and figure things out together.

Today, Avi has his cloud storage.

He has his media server. I have a much deeper appreciation for systems engineering than I did before we started.

And somewhere in a corner of a room, a laptop that was never meant to be a server quietly does its job—synchronizing files, serving media, managing credentials, and reminding us that some of the most rewarding projects begin with nothing more than a simple question

How hard can it get?

Perhaps not as much as you think