The Dumb plan
It was 1:47 AM. At that time, I was trying to set up my first ever home server. The entire system setup felt like ritual more than engineering.
Heavy metal was blasting in the background, masking the sleep deprivation and the very real fact that I had office the next morning.
The plan was simple. For context, one of my friends had suggested me to use a open source expense tracker called firefly. I was also planning to use it for my personal expenses and had plans to few plans.
Instead of having this run in AWS and Azure, i took it up on myself "I’m a BTech student. With ChatGPT. How hard could this be?"
And boy was i starting a rollercoaster ride
My younger brother had his third hand laptop, that was dying and wanted to use it as a server. Its a very old Dell E5470 with a decent hardware. it has seen many blue screens of death and i wasnt sure if it would work.
In a nutshell, i had planned to install Archlinux on it but my last single brain cell would have been used up to install it. So "Ubuntu" it was.
I have a blog coming up on what all i did and how i set it up. I hope you find it interesting.
The Night the Illusion Broke
The laptop that I call a server was humming under my desk like it was proud of itself. I had just deployed a new container. It worked. Clean logs. No errors. I leaned back like I had just conquered infrastructure.
Then the Wi-Fi dropped. Then SSH froze. Then everything that “worked perfectly” became unreachable.
And Somewhere between refreshing my terminal and interrogating my router lights, it hit me:
This isn’t a server. It’s a laptop cosplaying as infrastructure. That moment.... yup it was the end of my “it works on my network”, the line that i was planning to tell my friends.
Why This Isn’t Just a Nerd Problem
A home server sounds harmless. Cute, even. It feels like an Iron Man garage montage, old hardware, Linux install, terminal glow, a little bit of rebellion against cloud bills.
But the second you depend on it even slightly, the game changes.
If you’re storing real data, hosting something you check daily, or accessing it while traveling, you’ve crossed a line. You are no longer tinkering. You are operating infrastructure.
Infrastructure has properties. And those properties don’t care how aesthetic your setup looks on Reddit.
You either design for failure or failure designs your night.
The Deep Dive: What Actually Makes a Server “Real”
The word “server” misleads people. It isn’t hardware. It’s behavior under stress.
A real server assumes three things:
- It will lose power.
- It will lose network.
- You will not be physically present when that happens.
If it collapses and waits for you to wake up and fix it, it isn’t infrastructure. It’s a pet.
And pets need attention. Servers need to be reliable.
Networking: The Moment You Expose a Port
I opened port 22 and forgot about it.
The next morning, I checked the logs out of curiosity. There were hundreds of login attempts. Not because anyone cared about my little laptop under the desk. Just because it existed.
Just automated scripts sweeping across the internet, trying doors. That was the moment I understood something important.
The internet doesn’t notice you. It discovers you.
There are three models people usually choose:
-
Direct port forwarding is simple but expands your attack surface.
-
Overlay networks like Tailscale create a private mesh using WireGuard under the hood. Only authenticated devices can see the machine. It feels almost unfair like you built a secret tunnel under the internet.
-
Reverse tunnels like Cloudflare Tunnel invert the connection. Your server dials outward. No inbound ports. HTTPS handled. Cleaner boundary.
Each model is a tradeoff between control, exposure, and dependency. None of them are magic. All of them require thinking.
The Complication: “It’s Cheaper to Host at Home”
This is where people get it wrong. “Why pay cloud bills when you have an old laptop?”
That argument ignores hidden costs. Electricity isn’t free. Old hardware degrades. Residential internet doesn’t promise uptime. Your house is not a data center.
Running infra at home is a training arc. The kind where you come out stronger, with a lot of coffee, entirely sleep-deprived, and much more paranoid in a healthy way.
But it is not effortless freedom. It is responsibility disguised as savings.
The Serious Section: Security Is Not Optional
This is the part where the tone stabilizes.
If you expose anything publicly, key-based SSH authentication is mandatory. Password login is negligence. Logs must be monitored. Updates must be applied. Services must run with least privilege. Secrets must never live in public repositories.
Changing a port is not security. It’s noise reduction. Firewalls are not optional. Fail2ban or equivalent intrusion protection is not overkill.
If you are using overlay networks, device access control matters. Approving devices blindly defeats the purpose. Removing old devices is important. Rotating keys is a must.
Security is not about paranoia. It is about blast radius. You don’t design systems assuming compromise won’t happen. You design them assuming it might and limit the damage.
What I Learned After the Chaos
The biggest lesson was subtle.
Working systems are not impressive. Recovering systems are.
I learned to optimize for performance and clever setups. Now I started to learn for survivability. If something crashes, I want it to come back without my involvement.
Manual restart scripts became automatic services.
Hope became configuration, and that shift changed how I think about every system not just the one in my house.
When This Makes Sense — And When It Doesn’t
Running a home server makes sense when you want to understand infrastructure at a fundamental level. When you want to learn networking, process supervision, service design, and failure modes in a way cloud abstractions hide from you.
It does not make sense when uptime is contractual. It does not make sense when handling regulated client data. It does not make sense if you don’t have the time to monitor and maintain it.
There is a difference between experimentation and production responsibility.
Confusing the two is expensive.
Zooming Out
The strange thing about building a home server is that it quietly changes your mindset.
You stop thinking like someone who deploys features. You start thinking like someone who designs systems.
You begin anticipating failure instead of reacting to it. and once that mindset clicks, whether you’re deploying to a bedroom laptop or three cloud regions, you carry the same discipline with you.
P.S
This is the first entry in my personal blog logs. I'm writing these posts mainly to practice and improve my writing while sharing things I find interesting along the way.
If you have suggestions, thoughts, or feedback about the post, feel free to send me an email. I'd love to hear what you think.