DEV Community: Mahesh Cheemalapati

What Building a Home Server Actually Taught Me About Infrastructure

Mahesh Cheemalapati — Sat, 09 May 2026 04:43:16 +0000

“Infrastructure always felt like this invisible layer beneath software engineering — important enough that everyone depends on it, but abstract enough that most developers never really touch it.”

A few weeks ago, I wanted to deploy my portfolio and a few personal projects, so I started researching hosting options.

Like most developers, I went through the usual rabbit hole.

Cloud providers
Free tiers
VPS comparisons
Deployment tutorials
“Deploy in 5 minutes” videos

At first, everything looked straightforward.

Pick a provider.

Push your code.

Point a domain at it.

Done.

But the more I looked into it, the more I started wondering:

What actually happens underneath all of this?

If I deploy an application to the cloud, where does it really run?

How are servers secured?

How do applications stay online 24/7?

What exactly happens when traffic moves through a VPN?

As developers, we interact with infrastructure constantly, but most of the time we experience it through abstractions.

Cloud dashboards
Managed databases
Deployment platforms
Serverless runtimes

Convenient abstractions make building software easier.

But they also make the underlying systems feel invisible.

And honestly, at some point, the engineer in me got annoyed by how much of modern infrastructure I was using without fully understanding.

Because every large system started somewhere.

At some point:

Google was just servers in a room
Netflix was just an application someone deployed
Infrastructure was still infrastructure before it became “the cloud”

So I started asking myself a different question:

Could I build a small version of this myself?

Not enterprise scale.

Not production-grade infrastructure.

Not something that replaces AWS.

Just enough to actually understand the moving pieces.

That’s when I came across the Raspberry Pi 5.

Why the Raspberry Pi Interested Me

I remembered using Raspberry Pis during my Master’s program for smaller academic projects, but I had never seriously thought of one as an actual server.

The more I researched, though, the more interesting the idea became.

I wanted something small. Something constrained. Something that would force me to understand what I was doing instead of hiding everything behind a dashboard.

A mini PC would probably be more powerful. A cloud VM would probably be easier. But that wasn’t really the point.

I was not trying to build the most powerful server.

I was trying to build something that would teach me how servers actually work.

That’s what made the Raspberry Pi interesting.

It sits in this weird middle ground where it is:

cheap enough to experiment with
powerful enough to run real workloads
constrained enough to force you to learn

You have to think about networking.

You have to think about storage.

You have to think about power.

You have to think about reliability.

You have to think about security.

You don’t just deploy software.

You build the environment the software runs on.

And that changes the learning experience completely.

So I broke the project into phases.

The first goal was simple:

Build a secure home VPN.

Eventually, I want this setup to become a platform for:

hosting personal projects
running Docker containers
AI experiments
self-hosted tooling

But I wanted to start with the fundamentals first.

Because that’s where the real learning happens.

The Hardware Mistake That Immediately Humbled Me

The first lesson came before the server was even fully assembled.

I bought a Kingston NV3 1TB NVMe SSD for the Raspberry Pi M.2 HAT+ because, on paper, everything looked compatible.

It was NVMe.

The Pi supported NVMe.

Problem solved, right?

Wrong.

The SSD physically did not fit.

That’s when I learned something I somehow never paid attention to before:

Not all NVMe drives are physically the same size.

The Raspberry Pi M.2 HAT+ only supports 2230 and 2242 drives.

The Kingston NV3 was 2280.

The drive was literally too long for the board.

It was such a small mistake, but it perfectly introduced me to what infrastructure work actually feels like.

Tiny details matter.

When you work closer to hardware, assumptions become expensive very quickly.

And honestly, I’m glad I made the mistake early because it forced me to slow down and actually read specifications instead of trusting product labels.

Right now, the server is still running from a 64GB microSD card while I search for the correct 2242 SSD.

Ironically, the mistake taught me more than the successful setup probably would have.

“The fastest way to understand infrastructure is to break something you thought would just work.”

The Moment Security Stopped Feeling Theoretical

There’s something psychologically different about exposing a machine to the internet.

The second I enabled remote access, security stopped feeling like a theoretical checklist from tutorials.

This was not just me reading about firewalls anymore.

This was a real Linux machine connected to my actual home network.

That changes your mindset immediately.

Instead of thinking:

“How do I make this work?”

you start thinking:

“How do I make this safe to leave running 24/7?”

That shift ended up changing how I approached the entire project.

I started from a deny-by-default mindset.

Expose as little as possible.

Open only what is necessary.

Reduce the attack surface first.

So the Pi only exposes what it needs for SSH and Tailscale.

Everything else stays closed unless there is a real reason for it to exist publicly.

Then I installed Fail2ban.

Before this project, Fail2ban was something I had maybe heard about but never really understood why people used it.

Now it makes complete sense.

The idea is simple:

If repeated authentication failures happen, the offending IP gets banned automatically.

But what surprised me was not the tool itself.

It was realizing how quickly infrastructure work changes the way you think about systems.

Applications optimize for features.

Infrastructure optimizes for resilience.

That distinction feels obvious in hindsight, but building a server yourself makes you experience it directly.

What a Home VPN Actually Is

Before this project, my understanding of VPNs was mostly shaped by commercial VPN marketing.

Hide your IP
Watch region-locked Netflix
Use public WiFi safely

That was basically my mental model.

But then I started thinking about something more relatable.

Have you ever talked about a trip and suddenly started seeing travel ads everywhere?

Or searched for cookware once and then every website, app, and Amazon notification suddenly thinks you are building a professional kitchen?

It gets annoying.

And while a home VPN does not magically solve all tracking or privacy problems, building one helped me understand what parts of privacy I could actually control myself.

A home VPN is different from a commercial VPN.

Instead of routing traffic through some company’s infrastructure, you route traffic through your own home network.

That means when I am traveling or connected to public WiFi:

my traffic encrypts back to my house
my devices behave like they are home
I control the network path
I can use my own DNS filtering

That realization completely changed how I think about privacy and networking.

You are not buying trust.

You are building it yourself.

And honestly, that was probably the biggest conceptual shift of this project.

The Difference Between “Working” and “Infrastructure”

At first, everything seemed perfect.

Tailscale worked.

The VPN connected.

My Mac connected.

My iPhone connected.

Then I rebooted the Raspberry Pi.

That’s when things broke.

Exit node functionality disappeared
IP forwarding stopped working
Routing behaved inconsistently

And that taught me one of the most important lessons of the entire project:

There is a massive difference between:

“I got this working once”

and:

“this survives reboot reliably forever.”

The fixes themselves were not particularly complicated.

Some sysctl configuration.

Some systemd services.

Some persistent kernel settings.

But the lesson was much bigger than the commands.

Infrastructure is about persistence.

Reliable systems survive:

reboots
failures
unexpected states
power interruptions

That realization honestly felt like crossing a boundary from hobby scripting into actual operational engineering.

“Software runs. Infrastructure stays running.”

What This Project Actually Taught Me

Technically, I learned a lot.

Linux networking
Firewall management
VPN routing
SSH hardening
Service persistence
Infrastructure troubleshooting

But honestly, the deeper lesson had very little to do with individual technologies.

It was about systems thinking.

A lot of software engineering focuses on isolated components.

APIs
Frameworks
Databases
Algorithms

Infrastructure forces you to think differently because suddenly everything becomes interconnected.

Networking affects security.

Persistence affects reliability.

Hardware affects software behavior.

Routing affects user experience.

You stop thinking only in features.

You start thinking in systems.

And honestly, I think that mindset shift is the real reason home labs are so valuable for developers.

Final Thoughts

I originally thought this project would teach me how to run a VPN.

Instead, it taught me how infrastructure behaves.

It taught me why operational reliability matters.

It taught me how networking layers interact.

It taught me why security is about layers instead of tools.

It taught me what self-hosting actually means.

More importantly, it changed my relationship with technology.

Before this project, infrastructure felt abstract.

Now it feels tangible.

I can debug routing problems I barely understood a month ago.

I can trace how different layers interact.

I can see how much engineering exists underneath the simple act of “deploying an app.”

And honestly, that is probably the real value of building a home lab.

Not the server itself.

The understanding you gain from owning the entire stack.

Algorithms vs Architecture: Why LeetCode Alone Doesn’t Prepare Engineers for Real Systems

Mahesh Cheemalapati — Wed, 25 Mar 2026 01:01:30 +0000

"Premature optimization is the root of all evil." — Donald Knuth

Abstract

Coding interview platforms such as LeetCode have become a standard benchmark for evaluating software engineering candidates. They emphasize algorithmic efficiency, data structures, and isolated problem solving. While these skills are important, they represent only a fraction of what software engineers encounter in real-world systems.
Production engineering goes beyond writing correct code — it involves designing, operating, and evolving systems under constraints, failures, and scale. This article explores the gap between algorithmic problem solving and real-world engineering, and why understanding this distinction matters for both aspiring and experienced engineers.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Robert C. Martin

Most engineers encounter these ideas early in their careers.
And then spend hundreds of hours optimizing solutions from  O(n²) → O(n log n).
Because that’s what success looks like on LeetCode.

The World We’re Trained In

In that world, everything is clean.
You are given a problem. 
You are given constraints.
 You are given complete control.

Input → Function → Output

No network. No latency. No failing dependencies. No “it works on my machine.”
Just logic.

And if you’re good really good it builds confidence:
“I can solve hard problems.”

What Actually Happens in the Real World

You ship your first real feature and suddenly, the problem looks different:

At this point, the question is no longer:

“What is the optimal solution?”

It becomes:
Why is this request slow?
Why does this fail only in production?
Why does fixing one issue affect another system?

In interviews, constraints are defined.
 In production, constraints are discovered.

The First Time It Breaks

Most engineers encounter a moment that isn’t covered in any coding platform.

The code works locally.
 You tested it.
 You wrote unit tests.

And yet, in production:

Requests start timing out
Logs don’t match expectations
Another team reports unexpected side effects
Rollback doesn’t fully resolve the issue

At some point, something becomes clear:

The problem was never just the code.

Where the Gap Begins

LeetCode trains you to solve problems in isolation.

Production systems are the opposite they are interconnected, evolving, and often unpredictable.

| LeetCode                                | Production                                   |
| --------------------------------------- | -------------------------------------------- |
| You control the input                   | You discover the input                       |
| System fails only if your code is wrong | System can fail even if your code is correct |
| You debug a function                    | You debug an entire system                   |

This is where the gap begins.

A More Honest Comparison

Interview Model

function solve(input) {
    return output;
}

Reality

function solve(userRequest) {
    try {
        callServiceA();
        callServiceB();
        readCache();
        queryDB();
        handleTimeouts();
        retryFailures();
        logEverything();
    } catch (e) {
        // Often unclear what actually failed
    }
}

The difference is not just complexity, it’s context.

The Nature of Real Problems

In real systems, problems rarely present themselves clearly. They often appear indirectly.

A performance issue might not be a loop problem, it could be:

an extra network call
inefficient data aggregation
duplicated requests
a missing or invalid cache

In one system I worked on, we reduced API traffic significantly; not by changing algorithms, but by identifying redundant calls and improving caching strategies.

The problem wasn’t computational complexity. It was unnecessary work happening across the system.

Similarly, a bug may not be incorrect logic, but:

timing issues
state inconsistencies
race conditions
partial deployments

The challenge is not always complexity. It is often uncertainty.

Architecture as the Real Problem Space

“Architecture is about the important stuff. Whatever that is.” — Martin Fowler

In production systems, the “important stuff” is rarely just the algorithm.

It is:

how services communicate
how failures are handled
how data flows through the system
how changes are introduced safely

An algorithm can be correct, and the system can still fail.
Algorithms optimize functions.  Engineering, in practice, is about optimizing systems.

Where Algorithms Still Matter

Algorithms remain essential.

They appear in systems as:

caching mechanisms
queue processing
ranking logic
dependency resolution

However, they are rarely the source of system-level failures. In interviews, algorithms are the focus. In production, they are one part of a broader system.

The Real Skill Shift

A significant transition in an engineer’s growth is not just:
junior → senior
It is:
problem solver → system thinker
The questions change.
From:
“Is this optimal?”
To:
“What happens if this changes?”

Learning Beyond Isolated Problems

Solving algorithmic problems builds a strong foundation.

But it does not fully prepare engineers for:

debugging production issues
working across distributed systems
understanding latency and failure modes
deploying safely
reasoning under incomplete information

These skills are typically developed through experience. One effective way to build this understanding is to work on systems end-to-end, even on a small scale.

When you build something yourself from API to database to deployment — you begin to encounter challenges that don’t appear in isolated problem solving.

In many enterprise environments, work is distributed across teams and services. While this enables scale, it can limit visibility into the full system lifecycle.

Building independently, even on a small project, helps develop a more complete perspective of how systems behave in practice.

Conclusion

LeetCode is not the problem. It builds discipline, clarity, and problem-solving ability. But it represents a simplified model of software engineering. Real systems are not solved in isolation.
They are:

designed
deployed
observed
debugged and continuously evolved

Understanding this gap is not about rejecting algorithms.

It is about recognizing that:
Writing correct code is only the beginning. 
Building reliable systems is the real challenge.