Forem: Jonasz Jozwicki

Why Every Developer Should Have a Homelab in 2026

Jonasz Jozwicki — Wed, 18 Mar 2026 23:00:00 +0000

Picture this: your own private cloud.

Virtual machines. Containers. Networking. Automation pipelines.
All running quietly… in your own home.

No cloud bills creeping up at 2AM.
No rate limits.
No “you don’t have permission for that.”

Just pure infrastructure — and it’s yours.

Prefer video?

I documented this entire setup step-by-step — if you'd rather watch than read:

Otherwise, keep reading — I’ll break everything down here.

So… Why a Homelab?

I work with real cloud environments every day — production systems, test environments, shared infrastructure.

And while that’s great… it comes with limits.

You can’t just:

break things freely
test risky ideas
spin up weird experiments “just because”

There’s always structure. Ownership. Guardrails.

And that’s exactly why I decided to build a homelab in 2026.

Because sometimes the best way to learn…
is to have a space where nothing matters except curiosity.

What Is a Homelab, Really?

A homelab is your personal data center.

That might sound dramatic — but it doesn’t have to be.

It can be:

an old PC gathering dust
a mini PC from eBay
a small cluster of machines
or even a full rack (if you’re feeling ambitious)

Inside that setup, you can run:

virtual machines
containers
databases
DNS servers
reverse proxies
Kubernetes clusters
automation tools

Basically… anything you’d find in real-world infrastructure.

Except here, you control everything.

You’re Not Playing — You’re Simulating the Internet

A server is just a computer that runs services for others.

A homelab is what happens when you connect multiple services together:

apps talking to databases
APIs talking to other APIs
systems depending on each other

That’s infrastructure.

And when you build it yourself, something clicks.

You stop seeing “apps”…

…and start seeing systems.

My Goal: Build a Private Cloud at Home

This year, I’m rebuilding my homelab from scratch.

Not as a side experiment — but as a serious learning playground.

Why?

Because I want:

full control over my environment
a place to test ideas before production
a sandbox where failure is fast and cheap

And honestly?

Also just to have fun.

Because sometimes the best projects aren’t “necessary” —
they’re just interesting enough to pull you in.

What You Can Actually Do in a Homelab

Here’s where things get fun.

In your homelab, you can:

deploy your own cloud services
build CI/CD pipelines
host personal projects
simulate production environments
experiment with networking and security
break things… and fix them

Over and over again.

No tutorials. No constraints. Just iteration.

Why This Matters for Developers

Let’s be honest.

Most developers:

write code
run it locally
maybe deploy it to the cloud

But very few truly understand:

how infrastructure is wired together
how systems fail
how services communicate under the hood

A homelab changes that.

It forces you to:

think in systems
debug real problems
understand networking, storage, and compute

And that’s where you level up from:

“someone who writes code”
to
“someone who understands how software lives in the real world”

And No — You Don’t Need Expensive Gear

You don’t need a data center.

You can start with:

an old PC
8GB+ RAM
a decent CPU
a USB drive

That’s it.

Seriously.

The magic isn’t in the hardware.
It’s in what you build on top of it.

Where I’m Starting

For my setup, I’m using Proxmox — an open-source virtualization platform.

It lets me:

run multiple virtual machines
create lightweight containers
manage everything from a web interface

In other words — it becomes the control center of my homelab.

This is where everything begins.

This Is Just the Beginning

This post isn’t a tutorial.

It’s the starting point.

In the next steps, I’ll be building:

a fully functional Proxmox node
virtual machines and services
networking between systems
and eventually… a complete home infrastructure

Step by step.

Final Thought

A homelab isn’t about replacing the cloud.

It’s about understanding it.

It’s about having a place where you can:

experiment freely
learn deeply
and build without limits

So if you’ve ever thought:

“I want to get better at DevOps / infrastructure / backend…”

This is your sign.

Start small.

Break things.

Build again.

What’s Next?

This is just the starting point.

In the next step, I’ll be setting up the Proxmox host properly — networking, storage, and all the small things that actually make it usable.

If you want to see the full process in action, I documented this part here:

And if you’re building your own homelab too — I’d genuinely love to hear what you’re running and what you’re planning to build.

Things I Wish I Knew Before Building My Own IT Infrastructure

Jonasz Jozwicki — Wed, 11 Mar 2026 23:00:00 +0000

How I Got Here

Building a startup is hard these days. Building a tech startup is even harder.

My niche is Cloud and DevOps, so from the very beginning I wanted Platform as a Service to be part of my offering. Naturally, I also needed a place where I could test the services I wanted to sell.

So we decided to build our own datacenter.

Looking back, I had absolutely no idea what I was getting myself into.

The funny thing is that I’m about 7 months in, and sometimes it feels like nothing really moved forward. We still don’t have anything publicly available yet. But that’s a story for another post.

For now, I’d like to share some of the less obvious mistakes I made while building a self-hosted IT infrastructure. Hopefully they’ll save someone else a few headaches.

Infrastructure as Code… and Coding Everything

Yes, you heard that right.

These days everyone talks about Infrastructure as Code, Terraform, automation, pipelines, and writing code for every piece of infrastructure.

It’s cool. It sounds sexy. It’s also incredibly satisfying.

But sometimes… it’s just not worth the hassle.

I started with the idea that everything must be written as code. Every configuration. Every service. Every system.

Terraform.
Ansible.
Bash scripts.
You name it.

And while writing automation is fun, I eventually realized something important:

Sometimes you're just fiddling with code instead of finishing the job.

There are moments when you need to ship something quickly. Sometimes a quick click in a UI is perfectly fine.

In my case, I even wrote a full Bash script to auto-configure Proxmox. Later I discovered that something very similar already existed:

Proxmox VE Helper Scripts
https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install

So I basically did the work twice.

Lesson learned: automation is great, but don’t automate things that already have a perfectly good solution.

Sometimes it's okay to just click the button.

Why Backup Anything If I Can Recreate Everything From Code?

This mistake came directly from the previous mindset.

Since everything was defined as code, I convinced myself that traditional backups were unnecessary.

And to be fair, in many cases that actually works.

If a VM breaks?
Just recreate it with Terraform.

Easy.

But here’s the catch.

Real life rarely follows the clean IaC model.

Sometimes you:

tweak something manually
test a quick change
forget to update your Terraform
don’t want to rewrite a module for the 100th time

And suddenly your perfectly reproducible infrastructure isn’t perfectly reproducible anymore.

So yes, infrastructure as code helps a lot.

But periodic backups still matter.

One important clarification though:

This is about infrastructure backups, not user data.

User data should always be backed up properly.

For infrastructure itself, backups are just a safety net when reality drifts away from the code.

Sometimes restoring a backup is simply faster than rebuilding everything.

Old-school admin practices exist for a reason.

Documentation Doesn’t Need to Be Perfect

Everyone keeps repeating the same advice:

“Always document everything.”

And yes, documentation is important.

But it doesn’t need to be perfect.

At some point I started writing extremely detailed documentation for even the smallest tasks. Sometimes a simple setup ended up with multiple pages of documentation.

Eventually I realized something funny.

Many of those beautifully structured documents were never opened again.

Meanwhile the documents I actually used were:

quick notes
work-in-progress docs
messy personal guides
short command snippets

Not the polished ones.

Turns out the most useful documentation is often the one that is fast to write and easy to search, not the one that looks perfect.

Write documentation for future you, not for a technical writing award.

The Classic Hypocrisy: No Monitoring for My Own Infrastructure

This one is honestly embarrassing.

One of the products I’m planning to launch is a SaaS observability platform for software houses.

Meanwhile my own infrastructure monitoring barely exists.

It’s somewhere near the top of my backlog, but not properly implemented yet.

Which is ironic.

If you're building infrastructure, monitoring should exist from day one:

system metrics
service health
logs
alerts

Otherwise you're basically flying blind.

This is something I’m planning to fix soon and probably stream the entire setup process, if anyone is interested.

Doing Everything “By the Book” and Thinking Too Big

Another trap I fell into was trying to do everything the “proper” way.

Perfect architecture.
Perfect processes.
Perfect automation.

But the reality of startups is different.

Sometimes speed matters more than perfection.

What matters most is delivering value, especially to clients.

Ambition is great. Big plans are important.

But when you're:

bootstrapping
low on budget
early in the journey

it’s often better to start small and evolve.

You can always improve things later.

You can’t improve something that was never shipped.

What mistakes did you make?

Building infrastructure is one of those things where you only learn by doing… and by breaking things along the way.

These are just a few mistakes I made in the first months.

I’m sure there are many more waiting for me in the future.

So now I’m curious:

What’s the biggest mistake you made while building infrastructure?
What’s something you wish someone told you earlier?
Did you also fall into the “automate absolutely everything” trap?

I’d love to hear your stories. I suspect I’m not the only one who learned some of these lessons the hard way.

Docker Finally Clicked When I Understood This One Thing

Jonasz Jozwicki — Thu, 05 Mar 2026 18:12:44 +0000

For a long time, Docker felt for me like a collection of mysterious commands copied from StackOverflow.

I knew the basics:

docker build
docker run
docker ps

But if someone asked me what Docker actually was, I would probably say something vague like:

“It packages your app so it runs everywhere.”

Technically correct.

Not very helpful.

Docker finally clicked when I understood one simple mental model.

The Real Problem Docker Solves

If you’ve worked on any team project long enough, you’ve probably heard this conversation:

“It works on my machine.”
“Well… it doesn’t work on mine.”

Different operating systems.

Different library versions.

Different runtime environments.

A Node project might work perfectly on one laptop but fail on another because someone installed a slightly different version.

Multiply that problem across teams, staging servers, CI pipelines, and production infrastructure.

That’s where Docker comes in.

Docker lets you package everything your application needs:

the runtime
system libraries
dependencies
configuration
the application itself

All of it goes into a single isolated unit.

That unit is called a container.

The Mental Model That Made Docker Click

The analogy that made this make sense for me comes from the shipping industry.

Before standardized containers existed, cargo shipping was chaotic.

Ships carried:

wooden crates
barrels
sacks
oddly shaped equipment

Every time cargo moved from a ship to a truck or train, workers had to handle each item individually.

Then shipping containers were introduced.

Everything goes into the same standardized box.

Ships move the box.

Trucks move the box.

Trains move the box.

Nobody touches what’s inside.

Docker applies that exact idea to software.

Instead of shipping code and hoping the environment matches, you ship a container that already includes the entire environment.

Your laptop.

Your teammate’s machine.

A cloud server.

Same container. Same behavior.

The Three Docker Concepts That Matter

Once the mental model clicked, the core pieces of Docker became much easier to understand.

1. Images

A Docker image is the blueprint.

It describes everything needed to run an application:

which base system to start from
which packages to install
which files to copy into the environment
what command should run when the container starts

Think of an image as a template.

2. Containers

A container is a running instance of an image.

One image can create many containers.

A simple analogy:

Image → cookie cutter
Container → cookie

3. Registries

A registry is where Docker images are stored.

The most popular one is Docker Hub, which acts like a huge library of prebuilt environments.

Need a database?

There’s an image for that.

Need a web server?

There’s an image for that too.

The Moment Docker Usually Clicks

Docker usually makes sense when you run your first real container.

For example, this single command launches a full web server:

docker run -d -p 8080:80 nginx

Let’s break that down.

docker run

Creates and starts a container.

Runs it in the background.

p 8080:80

Maps port 8080 on your machine to port 80 inside the container.

nginx

The image that contains the web server.

Once it starts, open your browser and go to:

localhost:8080

And just like that, you’re running a real Nginx server.

No manual installs.

No system configuration.

One command.

That’s when Docker usually clicks.

What Happens Behind the Scenes

When you run a container, Docker automatically:

checks if the image exists locally
downloads it if needed
creates the container environment
starts the process inside the container

The container runs until the process stops or you shut it down.

You can inspect running containers with:

docker ps

And see all containers, including stopped ones, with:

docker ps -a

A Full Beginner Walkthrough

I recently recorded a full beginner walkthrough where I explain:

what Docker actually is
images vs containers
running your first container
launching an Nginx web server
basic container management

Everything happens live in the terminal so you can follow along step by step.

If you're interested, you can watch it here:

https://www.youtube.com/watch?v=x2sahRjVtGc

Curious About Your Experience

Docker tends to "click" at different moments for different people.

For some it's when they run their first container.

For others it's when they build their first image.

I'm curious:

When did Docker finally make sense for you?