Why I Finally Stopped Running Servers in My Apartment (And Why You Should Too)

Two years ago, I was that guy with a Raspberry Pi and a sketchy networking setup in my bedroom, convinced I could save money by self-hosting everything. My internet went down during a client demo. My cooling fan died at 2 AM. I lost three hours debugging something that should have taken fifteen minutes. That's when it hit me: I was spending more time managing infrastructure than actually building things that mattered.

When I first looked at Azure VMs, I'll admit I was intimidated. The portal looked overwhelming. Pricing felt ambiguous. But here's what I realized after spending the last year building on cloud infrastructure: creating a Linux VM on Azure isn't actually complicated—I was just overthinking it. The barrier to entry is so low now that there's almost no excuse for developers to stay stuck in the "I'll just run it locally" phase.

The Real Reason Cloud VMs Matter (And It's Not What You Think)

Most beginner-focused articles will tell you that VMs are "computers in the cloud." That's technically true but misses the actual value proposition. What they really are is freedom from operational debt.

Think about it this way: when you own physical hardware, you're not just paying for the box. You're paying for the electricity bill, the space it takes up, the cooling required to keep it running, someone to physically maintain it, and the opportunity cost of your own time troubleshooting network issues. For a solo developer or small team, that's insane. You're trading your coding time for sysadmin work you probably hate doing.

Azure VMs let you rent infrastructure by the hour. You don't care if the physical server has issues—that's Microsoft's problem. You scale up when you need more power and scale down when you don't. For someone like me who was burning out on DevOps work I didn't sign up for, this was genuinely life-changing.

What the Setup Process Gets Right (And Where It Gets Fuzzy)

The original walkthrough covers the basics well: you're essentially filling in a form in the Azure portal, and by the end of it, you have a running Linux machine. The step-by-step approach is solid for someone's first time.

But here's where I think the instructions miss a crucial nuance: resource organization matters immediately, not eventually. The article mentions creating a resource group somewhat casually, but this decision compounds. I've seen developers a year into their Azure usage with a chaotic mess of resources scattered across random resource groups. Spend an extra five minutes thinking about your naming convention now—something like {project}-{environment}-rg—and your future self will thank you.

My Take: The Idle Timeout Issue Is a Red Flag

The original article flags idle timeout as "important," and I agree, but I'd go further. The fact that this setting exists and defaults to 4 minutes is a design problem in Azure's UX. Most beginners won't discover this until they're in the middle of work and get disconnected unexpectedly.

What I do instead: I immediately set the idle timeout to 30 minutes when spinning up any exploratory VM. But more importantly, I've shifted toward using Azure Bastion or even better—SSH key-based authentication instead of passwords. Passwords feel like security theater for cloud infrastructure. Yes, the article recommends passwords for beginners "to keep it simple," but I'd argue SSH keys are simpler once you've done it once. Here's what I actually do:

# Generate an SSH key pair locally (do this before creating the VM)
ssh-keygen -t ed25519 -C "your-email@example.com"

# When creating the Azure VM, paste your public key instead of choosing password
# Then connect like this:
ssh -i ~/.ssh/id_ed25519 azureuser@YOUR_VM_IP

# No password prompts. No invisible typing. No timeouts to configure.

That's it. One-time setup, infinitely more secure, and zero password management headache.

The Bigger Picture

What I appreciate about understanding this setup process is that it demystifies infrastructure. You're not doing anything magical—you're just provisioning compute resources and connecting to them. Once you've done it once, you realize how much of the "cloud is complicated" narrative is just poor UX design, not actual complexity.

The real insight isn't "how to create a VM." It's recognizing that infrastructure decisions should take minutes, not hours. The moment your setup process feels tedious, you've stumbled onto a friction point worth automating. That's when you graduate to Infrastructure as Code (Terraform, Bicep, whatever), but that's a post for another day.

What's Your Blocker?

Here's my question for you: if you've been hesitant about moving to cloud infrastructure, what's actually holding you back? Is it cost concerns? Security? Not knowing where to start? Because honestly, the technical barrier has never been lower. The real work is psychological—letting go of the illusion of control that comes with running your own hardware.

Give yourself an hour this week. Spin up a Linux VM. Install something. Delete it. See how cheap it is. You might surprise yourself.

Source: This post was inspired by "How to Create a Linux Virtual Machine on Azure (Step-by-Step for Beginners)" by Dev.to. Read the original article