Modern web development often ends up scattered across multiple machines and operating systems, which increases setup time, maintenance effort, and hardware costs. A more efficient and cost-effective pattern is to centralize your development stack on a Linux server, then connect to it from whatever Windows or Mac desktop and laptop you prefer, so you gain a powerful, consistent environment while still working where you are most comfortable.

The Problem: Too Many “Local” Environments

Most developers end up juggling a lot of machines over time:

A desktop that is great for everyday work
A laptop for meetings or travel
Sometimes, a second machine that gets upgraded every few years

Each one slowly collects its own stack of PHP versions, Node runtimes, databases, container setups, and half-working local sites. After a while, your “local environment” is really three different environments and a folder of backup zips.

Centralizing development on a Linux box solves a lot of this:

A Linux server, such as Debian, Ubuntu, Rocky Linux, or RHEL, becomes your single development environment
Your desktop (Windows or Mac) and laptop (Windows or Mac) act like very capable thin clients
Web projects such as Drupal and WordPress, custom PHP apps, MySQL-backed sites, and Next.js apps all run in containers on the Linux box

You still work in the desktop environment you prefer, but all your projects and tooling live in one place.

High-Level Architecture

At a high level, the setup looks like this:

Linux Dev Server
- Debian is my default recommendation, but Ubuntu or Rocky / RHEL work fine too
- Runs Docker for containerized environments
- Hosts web projects like Drupal, WordPress, PHP apps, and Next.js
- Stores all project code and databases
- Has a fixed IP address on your network, such as 192.168.1.50
Desktop
- Windows or Mac
- Main workstation with your monitors and peripherals
- Connects to the dev server over SSH using the server IP
- Uses a remote-capable editor or IDE
Laptop
- Windows or Mac
- Connects to the same dev server over SSH
- Lets you pick up work without syncing or copying projects

Your development state lives in one place on the Linux server. Desktops and laptops come and go. The server keeps working.

Why Centralize On A Linux Dev Server?

1. Stability And Ecosystem

Debian, Ubuntu, Rocky, and RHEL are all solid server operating systems. Debian in particular is known for its focus on stability and large package ecosystem, and it serves as the base for many other distributions.

Docker runs well on all of these. Once Docker is in place, container-based tools can provide predictable PHP, MySQL, and Node environments that are much closer to production than ad hoc stacks you install separately on each workstation.

2. Cost And Upgradability

You can often:

Build a solid Linux dev server with plenty of RAM and storage
Build or buy a capable Windows or Mac desktop

for less money than a single high-end laptop. A custom Linux box is also much easier to upgrade. If you need more memory, you add DIMMs. If you need more disk space, you can add another SSD or HDD. Many laptops, especially MacBook Pros, cannot be upgraded after purchase.

3. One Environment, Many Entry Points

With a centralized dev server:

Every project lives in one environment
Configuration is shared across all your client machines
Switching between desktop and laptop is just “SSH to the same IP and open the same directory”

You do not rebuild environments when you get a new machine. You just teach the new machine how to reach the server.

DDEV And Docksal In This Setup

Two popular tools fit very nicely on a Linux dev server for web work:

Both are Docker-based tools that make it easy to spin up repeatable environments for projects like Drupal and WordPress, along with generic PHP and front-end stacks.

A few important notes for this kind of setup:

You can install DDEV and Docksal side by side on the same Linux server
In practice, you usually run only one of them at a time
Both rely on a local DNS resolver that listens on port 53, so they can route project-specific hostnames to the correct container stack
Because of that shared port, running both simultaneously tends to cause conflicts

The common pattern is:

Pick DDEV as your default if you want a widely supported tool with a lot of documentation around Drupal and WordPress
Use Docksal if you want a light Docker Compose wrapper that is highly customizable
Keep both installed if you need to support older or mixed projects, but start and stop them as needed, so only one is handling local DNS at a time

In this guide, the focus is on how to wire your desktop and laptop into the Linux server. The specifics of configuring DDEV or Docksal for individual projects can live in their respective documentation.

Prerequisites

Linux Dev Server

You need:

A Linux server running Debian, Ubuntu, Rocky, or RHEL
A normal non-root user; I will call this user will in examples
SSH access enabled
Reasonable specs, for example:
- 6 or more CPU cores
- 16 GB RAM minimum, 32 GB or more if you run a lot of containers
- SSD-based storage

Desktop And Laptop

For each client machine:

Windows 10 or 11, or macOS
SSH client
- Windows: built-in OpenSSH or an SSH-capable terminal
- macOS: OpenSSH in Terminal or iTerm
A terminal you like on Windows
- Cmder or Windows Terminal
At least one editor or IDE with remote development support
- Visual Studio Code with the Remote - SSH extension
- JetBrains IDEs such as PhpStorm, WebStorm, or IntelliJ IDEA with JetBrains Gateway or the built in Remote Development features

Step 1: Prepare The Linux Dev Server

All commands in this section run on the Linux server.

1. Create Your User

If you did not already create a regular user during installation, add one and give it sudo access:

sudo adduser will
sudo usermod -aG sudo will

Log in as will from now on.

2. Install And Enable SSH

Install the SSH server if it is not already installed, then enable it:

sudo apt update
sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh

On Rocky or RHEL, the package name is usually openssh-server as well, installed with dnf or yum.

3. Find And Reserve The Server IP Address

Your clients will connect to the server using its IP address, so you want that IP to be stable.

On the server, check the current IP with a command such as:

ip addr

or

ip a

Look for the address on your main network interface, often something like 192.168.1.50.

Once you know the IP:

Log in to your router web interface
Find the DHCP or LAN settings section
Use the “DHCP reservation” or “address reservation” feature to assign that IP to your server's MAC address

This ensures that any time the server requests an address from DHCP, it receives the same one. You will use that IP in all your SSH and editor connections, such as 192.168.1.50.

4. Install Docker

Follow the official Docker instructions for your distribution. For Debian, the main reference is the Docker Engine on Debian guide.

In short, you will:

Uninstall any conflicting Docker-related packages
Add Docker’s repository
Install the Docker Engine packages
Enable and start the Docker service

Once Docker is installed, test with:

sudo docker run hello-world

Add will to the docker group so you do not have to use sudo for every command:

sudo usermod -aG docker will
# log out and log back in

Step 2: SSH Keys And Profiles For Desktop And Laptop

SSH keys give you secure authentication without typing your account password every time. Profiles in your terminal or SSH client help make everything feel like one cohesive system.

Here we will use RSA keys, which are commonly supported and familiar in many environments.

1. Generate SSH Keys On Each Client

On your Windows desktop, in Cmder or Windows Terminal:

ssh-keygen -t rsa

Press Enter to accept the default location and set a passphrase when prompted.

On your Mac or another Linux client, run the same command in Terminal:

ssh-keygen -t rsa

This gives you:

A private key file, typically ~/.ssh/id_rsa
A public key file, typically ~/.ssh/id_rsa.pub

Keep the private key on that client only. The public key is what you copy to the server.

2. Copy Keys To The Linux Server

From each client, copy the public key to the will user on the server using its IP:

ssh-copy-id will@192.168.1.50

Replace 192.168.1.50 with the actual IP you reserved.

If ssh-copy-id is not available on a client, you can:

Open ~/.ssh/id_rsa.pub in a text editor
Copy its contents
On the server, append it to /home/will/.ssh/authorized_keys

After that, test:

ssh will@192.168.1.50

You should be able to log in without typing the account password. You may still be prompted for the key passphrase if you set one, which is ideal.

3. Set Up Default Profiles In Your SSH Clients

Instead of manually typing ssh will@192.168.1.50 every time, configure your terminal or SSH client so that opening it drops you directly into the Linux server.

Examples:

Windows Terminal
Create a new profile that runs ssh will@192.168.1.50 as its command. Set that profile as the default so Windows Terminal opens connected to the server.
Cmder
Create a task that starts an SSH session to will@192.168.1.50 and make that task the default.
macOS Terminal or iTerm
Set the default shell command to ssh will@192.168.1.50 instead of a local shell.

The effect is psychological as much as technical. When you open a terminal, you are already “on” the dev server. It feels like a single machine with multiple screens rather than a separate server you have to remember to connect to.

Step 3: Remote Editing With VS Code Or JetBrains

With SSH and profiles in place, your terminal experience is already focused on the Linux server. The next step is to do the same for your editor.

Visual Studio Code With Remote SSH

On your desktop or laptop:

Install Visual Studio Code
Install the Remote - SSH extension
Use the command palette to choose “Remote-SSH: Connect to Host”
Enter will@192.168.1.50 when prompted
Once connected, open a folder such as /home/will/projects/client-site

VS Code installs a small helper on the server and runs language tooling there. Your editor window still lives on your Windows or Mac desktop, but everything it does is against the Linux filesystem.

Inside the integrated terminal in VS Code, you will see a shell on the Linux server. That is where you run Git commands, container management commands, and project scripts.

JetBrains IDEs With Remote Development

If you prefer JetBrains tools:

Install JetBrains Gateway or enable Remote Development in your IDE
Configure an SSH connection to will@192.168.1.50
Choose a backend IDE such as PhpStorm for Drupal and WordPress work, or WebStorm or IntelliJ IDEA for Next.js
Point it to a project path like /home/will/projects/client-site

The IDE backend runs on the Linux server, next to your containers and code. The UI streams to your desktop or laptop. You get the same inspections, refactorings, and debugging you are used to, but without installing full stacks on every machine.

Step 4: Optional File Sharing With Samba

Remote editing covers most workflows. Sometimes it is still convenient to browse project folders from Explorer or Finder, or to drag assets into a theme directory.

Samba lets your Linux server share directories using the same protocol that Windows file sharing uses.

1. Install Samba

On the Linux server:

sudo apt install samba

On non-Debian systems, adjust the package command as needed.

2. Prepare A Projects Directory

Create a central directory for your projects and make sure will owns it:

sudo mkdir -p /home/will/projects
sudo chown will:will /home/will/projects

3. Configure A Share

Edit /etc/samba/smb.conf and add a share definition:

[projects]
    path = /home/will/projects
    browseable = yes
    read only = no
    valid users = will
    create mask = 0644
    directory mask = 0755

Create a Samba password for will:

sudo smbpasswd -a will

Restart Samba:

sudo systemctl restart smbd

4. Map The Share On Windows

On a Windows desktop or laptop:

Open File Explorer
Right-click “This PC” and choose “Map network drive”
Choose a drive letter such as P:
For the folder, enter \\192.168.1.50\projects
Authenticate as will with your Samba password

The projects directory on the Linux server will now show up as a normal drive in Explorer.

5. Mount the Share on macOS

On a Mac desktop or laptop:

In Finder, press Cmd + K
Enter smb://192.168.1.50/projects
Authenticate as will

You can add it to your login items or use mount options if you want it to reconnect automatically.

Step 5: Daily Workflow For Web Projects

Once everything is wired up, your day-to-day work looks more like using a single machine with multiple screens than jumping between environments.

On The Desktop

Open your terminal on Windows or Mac
The default profile connects directly to will@192.168.1.50
Open VS Code or a JetBrains IDE and connect to the server using remote development
Open /home/will/projects/client-site

From the terminal in your editor:

cd ~/projects/client-site
# start or manage your containers for Drupal, WordPress, PHP, MySQL, or Next.js
# run project specific commands like composer, npm, yarn, or custom scripts

You edit code on your desktop, but all the heavy lifting happens on the Linux server.

On The Laptop

Later, on your laptop:

Open your terminal; it connects directly to will@192.168.1.50
Open your editor or IDE and connect to the same server IP
Open the same project directory
Continue right where you left off

No cloning, syncing, or reinstalling. It is the same project, same containers, and same databases as the desktop session.

Optional: Exposing Local Environments To The Internet

Most of the time, your dev server only needs to be reachable from your local network. In some cases, though, you may want your local environments to be accessible from the public internet. For example:

Testing webhooks or third-party services that need to call back into your application
Validating HTTPS behavior with real certificates
Demonstrating a feature to a client without deploying to a shared staging server

You can do this by setting up port forwarding on your router:

Log in to your router's web interface
Find the port forwarding or NAT section
Forward external port 80 (HTTP) to 192.168.1.50:80
Forward external port 443 (HTTPS) to 192.168.1.50:443

A few important caveats:

This presents a security risk if the services on your dev server are not hardened
- Anything listening on port 80 or 443 on the Linux box may become reachable from the internet
- You should treat it more like a small production server in terms of updates and security settings
Having a static public IP from your ISP makes this much easier
- Some ISPs only offer static IPs on certain plans, or not at all
- Without a static IP, you may need a dynamic DNS solution that keeps a hostname pointed at your current IP
You will also need to handle TLS certificates if you want valid HTTPS
- For example, by using an ACME client such as Certbot with a certificate authority
- Your router and ISP setup can affect what is possible here

If you only occasionally need public access for testing, it is often safer to enable port forwarding temporarily, perform your tests, then disable it again. For everyday development, keeping the server private on your LAN is simpler and less risky.

Multiple Clients, One Environment

Once the dev server exists, adding new machines follows the same pattern:

Generate an RSA key pair on the new desktop or laptop with ssh-keygen -t rsa
Copy the public key (id_rsa.pub) to will@192.168.1.50 and append it to ~/.ssh/authorized_keys
Set up a default profile in the terminal or SSH client that connects directly to will@192.168.1.50
Configure your editor or IDE to open projects on the server

Each machine becomes just another window into the same set of web projects running on Linux.

Who This Setup Is Great For

This pattern works well if:

You want better hardware value
A good Linux server and a capable desktop together often cost less than a single high-end laptop, and the server is easy to grow over time.
You maintain many websites
Running a lot of Drupal or WordPress instances is much easier to manage in one containerized environment than duplicating everything across multiple machines. DDEV and Docksal are both designed to support these kinds of stacks.
You like separating “environment” from “device”
Your development environment lives on the server. Your devices are just ways to reach it.
You want flexibility in how you use your desktop
For example, that same Windows desktop that drives client work during the day can also run games in the evening. Since containers, code, and databases all live on the Linux server, you can swap GPUs or even replace the desktop without moving any development projects.

Wrapping Up

Centralizing local development on a Linux server while treating your Windows and Mac machines as power clients gives you:

A single, consistent environment for Drupal, WordPress, PHP, MySQL, and Next.js
Reproducible container-based setups for your web projects
Freedom to choose Windows or Mac on the desktop and laptop
A better story for cost, upgrades, and hardware changes
The ability to switch between machines without moving your work
The option to expose selected local environments publicly when needed, as long as you handle security carefully

At the core, the stack looks like this:

Linux server, ideally Debian, Ubuntu, Rocky, or RHEL
Docker for isolated environments
Web-focused tooling such as DDEV and Docksal on the server for Drupal, WordPress, and related projects
OpenSSH with RSA keys for secure access
Remote-capable editors and IDEs (VS Code and JetBrains) on your desktop and laptop
Optional Samba shares for file access from Explorer or Finder
Optional router port forwarding when you truly need a public-facing dev instance

From there, you can layer on reverse proxies, HTTPS for local and external domains, CI runners that target the dev server, or separate Linux servers for different kinds of work.

The main idea is simple: keep your development world in one well-tuned Linux box, and let whatever screen you sit in front of be a comfortable, familiar window into it.

References / Further Reading

#Windows

PostsBlog Posts (1)

Linux Dev Server With Windows/Mac Clients: A Cost-Effective Setup for Modern Web Development