Building a private development workspace I can use from any device

I wanted to spend less time rebuilding development environments and be able to respond when a project needs attention. I created one private workspace that I can reach from my laptop, tablet or phone.

The value is simple: projects stay in one maintained place, work can continue when I switch devices and I can inspect an issue without waiting until I return to a specific computer.

Why I built it

Client projects often depend on several services and tools working together. Rebuilding that setup on every device takes time and creates small differences that are difficult to track. Keeping the environment in one place removes that repeated work.

I also wanted the freedom to check a project when I am away from my desk. If a build needs attention, a client asks a technical question or I want to capture an idea, I should not first need the laptop that contains the correct local setup.

How the setup works

1. The VPS does the work

The repositories, dependencies, containers and command-line tools live on the server. Long-running tasks can continue there when I close my browser or switch devices.

2. Tailscale limits access

The workspace is reached through my private Tailscale network. I do not need to expose the development interface as a normal public website.

3. T3 Code is the interface

T3 Code gives me access to the workspace from a browser. I can inspect files, use the terminal, work with coding agents and review a running website without installing the complete toolchain on the device in my hands.

What I can do from my phone

  • Open the same repository and see the current state of a project.
  • Check logs, builds and running services.
  • Review a change or a browser preview.
  • Ask a coding agent to investigate or prepare a small change.
  • Run tests and verify the result before anything is published.

For focused development I still prefer a large screen and keyboard. The phone is useful for checking, reviewing and handling smaller tasks. The important part is that I am opening the same environment, not a limited copy of it.

What this means for client work

A faster start

I return to the same project environment without setting it up again. More time can go to understanding and solving the actual problem.

A quicker response

I can inspect an issue, review a change or answer a question when I am away from my desk, with the full project context available.

More consistent delivery

Projects use the same controlled environment for development and checks. That reduces avoidable differences and makes future maintenance easier.

What needed careful thought

Moving development to a VPS creates different responsibilities. Access must be restricted, project secrets must be handled carefully, backups must be tested and the server needs updates and monitoring. The setup also depends on a working internet connection.

I treated those points as part of the design, not as tasks to consider later. Convenience is only useful when the environment remains understandable and maintainable.

The result

I now have a central development workspace that supports the way I work across different projects and technologies. I can use powerful tools from a lightweight device, continue work from another location and keep project environments in one managed place.

This small infrastructure project reflects how I approach client work: understand the real need, choose a simple structure, be honest about the tradeoffs and make sure the result can be maintained after it is launched.

Let’s look at the structure behind it.

I help companies make practical decisions about architecture, integrations, development and future maintenance.