> For the complete documentation index, see [llms.txt](https://kmanu225.gitbook.io/cs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kmanu225.gitbook.io/cs/software-engineering/unix-linux-on-windows-choosing-the-right-environment/remote-linux-development-use-linux-somewhere-else.md).

# Remote Linux Development: Use Linux Somewhere Else

So far, every solution has run something locally on the Windows computer. There is one more possibility: **do not run Linux locally at all**.

In this article, we will look at remote Linux development, where Windows remains your desktop while the actual build and execution environment runs on another Linux machine.

Not every Linux environment needs to run on your Windows machine. Sometimes the simplest solution is to keep Windows as your desktop and use a **real Linux machine somewhere else** for building, testing, or running the application.

That Linux machine could be:

* a server in your company;
* a cloud VM;
* a dedicated development workstation;
* an embedded target;
* a shared build machine;
* or a remote test environment.

## When should you use remote Linux?

Remote development is a good choice when:

> You need the real target environment more than you need Linux locally.

Typical examples include:

* software that depends on specific hardware;
* GPU development;
* embedded systems;
* large builds requiring more CPU or RAM;
* production-like networking;
* company-managed Linux environments;
* software that must run on a specific Linux distribution or architecture.

For example:

```
Windows laptop
    |
    +-- editor / terminal / browser
    |
    +-- SSH
          |
          +-- Linux server
                 +-- source code
                 +-- compiler
                 +-- dependencies
                 +-- application
```

Your Windows machine becomes the interface, while the actual development work happens on Linux.

## The simplest workflow: SSH

The basic approach is simply:

```bash
ssh developer@linux-server
```

Once connected, you work directly on the remote Linux machine:

```bash
git pull
cmake -S . -B build
cmake --build build
./myapp
```

This gives you the exact Linux environment available on that machine.

## Remote development can feel local

Modern development tools can make this workflow much more comfortable.

An editor or IDE can connect to the remote machine while keeping its graphical interface on Windows.

Conceptually:

```
Windows
    |
    +-- IDE / editor
           |
           +-- remote connection
                  |
                  +-- Linux filesystem
                  +-- Linux terminal
                  +-- Linux compiler
                  +-- Linux debugger
```

The project can appear almost local even though compilation and execution happen remotely.

## Why choose remote Linux?

The biggest advantage is fidelity.

You are not emulating Linux, translating POSIX APIs, or reproducing the target with a container.

You are running directly on a real Linux system.

This is especially useful when differences in:

```
kernel
architecture
drivers
hardware
networking
system libraries
```

actually matter.

## The trade-offs

Remote development depends on connectivity and access to the remote machine. It can also make local/offline work less convenient, and file transfer or latency may matter depending on the tooling. But when the remote machine closely matches the real target, those trade-offs can be worth it.

## Should you use remote Linux?

Use remote development when your requirement is:

> **"I need to build and run on a real Linux system, but that system does not need to be my local computer."**

This is often the best approach for specialized hardware, production-like environments, and shared development infrastructure.