Why I Develop on a Remote Server (and You Might Want To)

Contents

Here’s something I don’t hear talked about enough: the idea that your development environment doesn’t have to live on your local machine at all.

I use Whisperflow and Claude Code every day. But rather than running everything on my Windows machine or in WSL, I SSH into a remote server. That one change has quietly made my entire workflow better in ways I didn’t fully appreciate until I’d been doing it for a while.

The Setup

The concept is simple. You rent or provision a Linux server — a VPS is fine — and you do your actual development work there over SSH. Your local machine becomes a thin client: a terminal, a browser, an SSH connection. That’s it.

My tools of choice are PowerShell with multiple tabs and TMUX. More on that in a moment.

Why This Works So Well

It’s Always On

This is the big one. Your server doesn’t sleep. It doesn’t reboot for updates at an inconvenient moment. It doesn’t lose your state because you closed the laptop. Whatever process you kicked off at midnight is still running at 8 AM when you sit back down.

If you’re running Claude Code on long agentic tasks — the kind that take fifteen or twenty minutes to chew through a codebase — you don’t have to babysit it. Start the job, walk away. Come back and the work is done. If you’ve set up Agent Vibes, you’ll hear the agent narrate its progress and announce completion through your laptop speakers even when the server has no audio hardware of its own.

It’s Accessible from Anywhere

Home, office, a coffee shop, your phone via a terminal app — if you can get an SSH connection out, you’re at your full development environment. Every file, every running process, every session exactly where you left it.

This is especially useful when you’re mid-problem and you want to check something from a different device. No syncing, no git stashing, no “let me pull that branch.” You’re just back in.

Isolation and Security

Your server has no idea what else is on your home machine. Your personal files, your browser history, your documents — none of that is on the development box. If a project dependency does something sketchy, it stays contained. If you’re working with client code or anything sensitive, there’s a clean wall between that work and everything else in your life.

This also forces good habits around file organization. There’s no accumulation of “just this one script” on the desktop. Everything on the server is there intentionally.

VS Code Remote Works — But I Moved Past It

VS Code has a Remote SSH extension that lets you edit remote files as if they were local. It works well. If you’re a VS Code user, it’s worth knowing about.

But I’ve found myself drifting away from it. VS Code is a lot of application to run for what often amounts to editing text. It has a habit of showing “Reconnecting to server…” at inconvenient moments — usually mid-flow. And it tends to pull in extensions and processes that don’t really belong in a lightweight server environment.

These days I use PowerShell with multiple tabs, one per project or context, and TMUX running on the server side. No reconnection drama. No overhead. Just a prompt and the work.

The TMUX Factor

TMUX is what makes this setup resilient. If your SSH connection drops — and it will, occasionally — TMUX keeps your session running on the server. When you reconnect, you reattach to the session and you’re exactly where you were. Nothing lost.

If you’ve never used TMUX, I’ve written a full breakdown of it: The Genius Behind TMUX. Start there. It’s a short read and the payoff is immediate.

Taking It Further with PowerShell Scripts

Once you’re comfortable with this setup, the next step is automation. I have a PowerShell script that opens a set of tabs for each active project, colors each tab differently, SSHes into the server, and attaches to the right TMUX session — all in one shot.

What used to be three minutes of setup every morning is now one command. The cognitive overhead of “getting into work mode” drops to almost nothing, which means you start building faster.

The Honest Trade-offs

This setup is not for everyone. If your development work requires a GUI application, a local database with a visual tool, or screen recording tied to your actual desktop, a remote server adds friction rather than removing it. And if your internet connection is unreliable, SSH becomes a liability rather than an asset.

But if most of what you do is code, terminal tools, and AI-assisted development — which describes a lot of serious builders in 2026 — this approach is worth a try. The benefits compound. A server that’s always on, always reachable, and completely separate from the rest of your life is a surprisingly clean way to work.