The Dev Environment Lives Elsewhere Now

Summary: My dev setup now treats the laptop and workstation as clients, not as separate development environments. The actual work runs elsewhere: persistent tmux sessions, isolated remote workspaces, local editors, and shared AI tooling. I can close the laptop, switch machines, ride a train with flaky Wi-Fi, and reconnect to the same environment without losing context.

What worked for me until now, is to install everything on each machine, keep projects in sync somehow, run Docker locally, configure the editor twice, and eventually wonder which machine has the branch, the container, or the half-finished fix.

Nowadays, my development environment lives on a small always-on Linux box. The laptop and workstation are clients. They run the editor, terminal, and a little connection glue. The code, containers, long-running processes, and shared tooling live in one place.

The shape

Beyond Local Development

I can leave work running in tmux, close the laptop, switch machines, lose Wi-Fi, and reconnect to the same state later.

That matters for builds, tests, data jobs, local services, experiments, and agent runs.

It also makes parallel work cleaner. Worktrees help with code, but not with ports, services, databases, or toolchains. Separate remote workspaces keep those isolated.

The toolset is already there too: same editor flow, same AI tools, same MCPs, same project setup. I attach and continue.

The best part is persistence

This is the part I notice every day.

I can start something on the workstation, leave it running in tmux, close the laptop later, go somewhere else, and reconnect. The process did not care that a client disappeared. It was never running on the client.

That is useful at home, but it matters even more on the train.

A flaky connection no longer means the whole session is gone. The editor may disconnect. SSH may drop. The laptop may sleep. The work keeps running on the remote machine. When the network comes back, I reconnect to the same tmux session and continue.

The daily flow is intentionally boring:

# show available workspaces
dvw

# create one if needed
dvw new

# connect to an existing workspace
dvw my-project

From there I choose what I need: terminal with tmux or Cursor / VSCode / [your IDE] attached to the workspace. The important part is that I do not care which physical machine created the workspace.

One workspace list everywhere

The small thing that makes this usable across two clients is a shared workspace list.

If I create a workspace from the laptop, the workstation sees it. If I start one from the workstation, the laptop can attach to it. I do not care which machine created it.

That removes a lot of low-grade friction. I pick a workspace, choose terminal or editor, and continue.

The implementation does not need to be grand. For one person and two clients, a small shared catalog is enough. The important part is not the storage mechanism. It is that both clients agree on what exists.

What it gives me

The practical result is simple:

That is the upgrade I wanted. Not a bigger laptop. A cleaner boundary between interface, compute, and state.

The team version

This started as a solo setup, but the pattern is not limited to solo work.

At company level, I would not keep every piece exactly as-is. The shape stays useful, but the personal glue needs grown-up infrastructure around it:

That is where this gets interesting beyond my own desk. The principle scales: local interface, remote compute, durable state, consistent tooling.

For a solo developer, this is a very practical setup. For a team, it becomes a platform pattern. Add access control, observability, secret management, and lifecycle automation, and the same idea starts looking a lot like an internal developer platform.

The machines where I sit can change. The environment stays put.