Move builds to a cloud VPS and use a $25 Quadro P620 to drive 4+ monitors for efficient AI coding
Join developers getting comprehensive guides, code examples, optimization tips, and time-saving prompts to accelerate their development workflow.
No spam. Unsubscribe anytime.
If you run several Cursor windows at once and want more screen space without buying an expensive laptop, move your development environment to a cloud VPS and turn your local machine into a display terminal. The remote server stores your repositories, runs your builds, and hosts your databases and containers. The local machine only needs enough power to render editor windows, terminals, and a browser. This split lets you build a capable multi-monitor workstation from cheap secondhand hardware, including a $25 graphics card that can drive four displays.
I run five Cursor windows across separate client and internal projects most days, and the bottleneck was never my local CPU. It was how much of my work I could keep visible at once. Once I moved my actual development environment onto a Hetzner server, I stopped caring what processor sat on my desk and started caring about how many monitors it could drive.
This guide walks through the architecture, what actually consumes local resources, and how to pick hardware, including a specific low-cost GPU that solves the multi-monitor problem cleanly.
The setup splits into a local client and a remote development server.
Your desk machine runs Ubuntu, your editor (Cursor or VS Code), SSH terminals, a browser, and communication apps. It also drives your physical monitors, keyboard, and mouse. Nothing here needs to be fast. It just needs to render windows reliably.
The VPS runs your Git repositories, your Node.js or Python runtime, your dev servers, type checking, builds, Docker containers, databases, Redis, and any AI agent terminal commands. This is where the actual work happens.
My remote machine is a Hetzner server with an AMD Ryzen 5 3600, 64 GB of RAM, and SSD storage. That's far more capacity than my local client will ever touch, because the client's job is display, not computation.
Remote SSH extensions in VS Code and Cursor install a small server component on the remote machine, which lets the editor interface stay local while every command you run executes on the remote filesystem. Your local machine becomes a terminal in the original sense of the word: a window into compute that lives elsewhere.
Traditional development tends to center on one active editor window where you write and review code continuously. AI-assisted development spreads that attention across several windows at once.
On a typical day I have Cursor open on a client website, an internal proposal system, my own business site, and a demo project, sometimes with a second worktree of another project alongside them. The limiting factor is how much I can supervise, not how fast I can type. A wider desktop surface directly increases how many active AI agents I can watch and steer at the same time.
One monitor holds the primary Cursor agent. Another shows the running site. A third holds logs and terminals. A fourth holds documentation or the CMS admin panel. Extra monitors here produce more practical value than a faster local CPU.
Moving development to a VPS still leaves real work for the local machine. Cursor and VS Code are Electron apps, so every open window needs local memory for rendering, chat history, and background processes.
On my current setup, five Cursor windows together use roughly 3.5 to 3.8 GiB of local RAM:
About 0.5 GiB of that is shared Cursor overhead distributed across windows, so each workspace's actual footprint runs closer to 0.47 to 0.77 GiB.
A realistic local memory budget looks like this:
Ubuntu 26.04 LTS lists 6 GB as the minimum for a comfortable desktop, but that figure assumes light usage. Running several Electron apps alongside a dozen browser tabs pushes well past that. Here's where I landed on RAM tiers:
| RAM | Verdict |
|---|
The monitor count itself barely touches system memory. Framebuffers are cheap. Editor windows, browser tabs, and desktop apps are what eat RAM.
The first questions to ask about a thin client aren't about processor speed. Ask instead how many independent displays it can drive, whether it accepts one or two graphics cards, whether it supports at least 16 GB of RAM, whether it has an SSD, and whether it has stable Ethernet.
A secondhand six-core Intel i5 from several generations back already handles terminals, editor UI, and browser previews without strain. The harder problem is driving four or more independent displays, since most integrated graphics chips top out at two or three monitors and laptops are often more restrictive still. Docks and USB adapters can extend that, but they add compression, extra cables, and their own reliability problems. A desktop with a dedicated multi-output GPU sidesteps all of it.
The NVIDIA Quadro P620 is a professional workstation card, not a gaming card, and its display setup is unusually well suited to this use case:
NVIDIA's own specs confirm the four Mini DisplayPort outputs, the single-slot form factor, and the 40W ceiling. I found secondhand units for around €25, which puts the card well below the price of most docking stations or multi-monitor USB adapter setups, and for a machine whose job is displaying terminals and editor windows rather than rendering games, that's plenty of headroom.
One warning: confirm you're buying a P620 and not the older K620. The K620 ships with just one DisplayPort and one DVI output, so it won't get you anywhere near four monitors.
Two P620 cards work independently in the same machine, with no SLI bridge, no NVLink, and no cable connecting them. The first card drives monitors one through four, the second drives five through eight, and Ubuntu presents all of them as a single extended desktop.
For this workload the second PCIe slot doesn't need much bandwidth, so even a slot with fewer lanes works fine for rendering desktop applications. Two secondhand P620 cards can give you eight monitor outputs for around €50 in GPU cost, provided the host machine has two usable PCIe slots, room for two single-slot cards, matching brackets, sufficient power headroom, and adequate airflow around both cards. Both cards run on the same NVIDIA driver.
This route is often easier to pull off than hunting for a rare six-output card, since four-output cards like the P620 are common on the secondhand market.
Check what you already own before buying anything. An older business desktop is often enough:
The CPU can be modest. A fourth-generation Intel i5 will do the job, and something like an eighth-generation i5-8500 gives you more local headroom than you'll use.
16 GB of RAM is the target. Eight gigabytes technically works, but five Cursor windows plus Ubuntu plus a browser will already push against that ceiling. DDR4 is cheap now, so bumping an 8 GB office PC to 16 GB usually costs very little.
An SSD matters even though your repositories live remotely, because the local machine still writes application data, browser cache, editor state, logs, and swap. A 250 GB SSD is plenty, since Docker data and large repos stay on the server.
PCIe slots determine your monitor ceiling. One P620 covers four monitors; two cover eight, assuming the board and case can physically accept them. A second full-length slot doesn't need to run at x16, since physical fit matters more than bandwidth here.
Case size rules cards in or out. Towers and small-form-factor cases generally accept graphics cards; Mini, Micro, and Tiny form factors usually don't have standard PCIe slots at all. Small-form-factor machines need low-profile brackets, towers need full-height brackets, and secondhand cards sometimes ship with only one bracket type, so check before buying.
Power supply headroom should cover roughly 40W per card, so two cards add about 80W to the system's peak draw. A standard tower PSU handles that without issue, though compact office machines running 180W or 200W proprietary supplies are worth checking. The P620 needs no separate GPU power cable, which makes it drop into office desktops without a PSU upgrade.
Going to six or eight monitors just means a board with two usable PCIe slots, a second P620, and a few more Mini DisplayPort cables. The CPU stays the same.
The P620 outputs Mini DisplayPort, so the cleanest path is a direct Mini DisplayPort to DisplayPort cable rather than an adapter chain. Each adapter you add is another point where resolution or refresh rate can misbehave, and passive Mini DisplayPort to HDMI cables in particular carry their own resolution limits.
Before ordering cables, check your monitor's input type, the resolution and refresh rate you want, whether the cable actually supports that combination, and whether you need an active adapter. For coding work, 60Hz is enough. Higher refresh rates make scrolling feel smoother but add nothing essential to this setup.
Ubuntu is a good fit here because the local machine doesn't need a large software ecosystem. It only needs NVIDIA drivers, your editor, OpenSSH, a browser, a password manager, and whatever display arrangement tool you prefer.
Ubuntu 26.04 LTS asks for a 2GHz dual-core CPU, 6 GB of RAM, and 25 GB of storage for a comfortable install, and a 16 GB machine will run the standard desktop without trouble. The release also includes NVIDIA-related improvements aimed at smoother GNOME performance with NVIDIA drivers.
Keep the local install lean. Skip local databases, container runtimes, and language toolchains unless you genuinely need them there, since every local dependency you add pulls the client back toward doing work it shouldn't be doing.
Create a host alias in ~/.ssh/config:
# File: ~/.ssh/config
Host development
HostName your-server.example.com
User developer
IdentityFile ~/.ssh/id_ed25519
ServerAliveInterval 30
ServerAliveCountMax 3
Connect with:
ssh development
This alias means the editor's Remote SSH connection picker just needs the name development, and you can open your project directory directly on the server from there.
In Cursor or VS Code, select the Remote SSH connection and open the project folder on the server. The remote folder behaves like a normal workspace, but every command you run in its integrated terminal executes on the remote machine. VS Code's Remote SSH documentation describes this as opening a remote folder while keeping the editor's usual features intact.
Say your dev server runs a Next.js app on port 3000:
pnpm dev
You don't need to expose that port publicly. Tunnel it through SSH instead:
ssh -L 3000:localhost:3000 development
Then open http://localhost:3000 in your local browser. Traffic runs through the SSH tunnel to the remote server, so nothing is exposed beyond your own connection.
For multiple projects, map each to its own local port:
ssh \
-L 3001:localhost:3000 \
-L 3002:localhost:3001 \
-L 3003:localhost:3002 \
development
Some Remote SSH implementations detect and forward dev server ports automatically, so check your editor's behavior before setting up manual tunnels for every project.
Your remote server now holds your active development environments, so locking it down deserves real attention. Use SSH keys instead of passwords, disable direct root login, and run everything under a dedicated non-root user. Keep the OS patched, restrict exposed ports with a firewall, and back up repositories and persistent data on a schedule. Separate production credentials from development credentials, encrypt local storage in case the client machine is lost or stolen, and consider routing the connection through a VPN or private network.
The client itself shouldn't become a long-term home for copied credentials or environment files. One benefit of this architecture is that replacing the local machine is simple: install the editor, restore your SSH key securely, and reconnect. Nothing about your development environment needs rebuilding.
Remote development doesn't require heavy download bandwidth, since the editor exchanges filesystem operations, terminal output, and extension messages rather than streaming video of a remote desktop. Latency and connection stability carry far more weight.
A wired Ethernet connection suits a fixed workstation well, and a stable fibre or cable line will make a nearby server feel close to local for everyday editing. Things get uncomfortable when the connection drops frequently, latency runs high, a repository operation floods the terminal with output, the server sits far away geographically, remote storage is slow, or the remote editor process gets overloaded. Picking a data centre in your own region, rather than the cheapest available, avoids most of this.
Do I need a powerful CPU on the local machine? No. A secondhand six-core Intel i5 from several generations back handles terminals, editor rendering, and browser previews without strain, since the heavy computation runs on the remote server.
How much RAM does the local client actually need? 16 GB is the practical minimum for running several Cursor or VS Code windows alongside a browser and desktop environment. 8 GB works but leaves little headroom.
Can I use a gaming GPU instead of the P620? You can, but most gaming GPUs support two or three outputs and cost far more than a $25 workstation card built for exactly this display count.
Does the P620 need extra power cables? No. It draws a maximum of about 40W and pulls power directly from the PCIe slot, which is part of why it fits into office desktops without a PSU upgrade.
What if my internet connection is slow? Bandwidth matters less than latency and stability here. A modest connection with low latency to a nearby server will feel more responsive than a fast connection to a distant one.
Splitting your development environment across a lightweight local client and a capable remote VPS turns an old office desktop and a $25 graphics card into a genuine multi-monitor AI coding workstation. The Hetzner server handles repositories, builds, and containers, while the local machine's only job is rendering windows reliably across as many displays as you can attach to it. For anyone running several AI coding agents across multiple projects at once, that display space tends to matter more than another CPU upgrade ever would.
Let me know in the comments if you have questions, and subscribe for more practical development guides.
Thanks, Matija
| Cursor workspace | Approximate RAM |
|---|
| Client project | 0.88 GiB |
| Proposal builder, window one | 0.84 GiB |
| Business website | 0.71 GiB |
| Proposal builder, window two | 0.63 GiB |
| B2B demo project | 0.58 GiB |
| Workload | Approximate RAM |
|---|
| Five Cursor windows | 3.5 to 4 GiB |
| Ubuntu desktop and services | 1.5 to 2.5 GiB |
| Browser windows and previews | 2 to 4 GiB |
| Terminals and utilities | 0.5 to 1.5 GiB |
| Comfortable working total | 8 to 12 GiB |
| 8 GB | Usable but restrictive |
| 16 GB | Practical minimum |
| 32 GB | Comfortable for heavy multitasking |
| 32 GB+ | Unnecessary for this setup |
| Component | Example |
|---|
| Computer | Used Dell, HP, or Lenovo office desktop |
| Processor | Intel i5-6500, i5-7500, i5-8500, or similar |
| Memory | 16 GB DDR4 |
| Storage | 250 GB SSD |
| Graphics | NVIDIA Quadro P620 |
| Displays | Four DisplayPort monitors |
| OS | Ubuntu 26.04 LTS |
| Dev environment | Cursor over Remote SSH |
| Network | Wired Ethernet |