Back
REMOTE DEV & NETWORK SETUP
// No Screenshots

Overview

What is this?

Development work doesn't always happen at the main machine. This is the personal infrastructure that makes remote access to the main development setup practical — without routing traffic through third-party cloud services, which introduce latency, privacy concerns, and dependency on uptime you don't control.

The setup covers network tunnelling for remote desktop access, multi-monitor configuration that survives remote sessions without collapsing to a single virtual display, and system-level configuration for keeping a GPU-heavy development machine responsive under remote load.

  • Multi-monitor DisplayPort remote access
  • Network tunnelling without third-party cloud
  • Cross-device dev workflow active
  • Custom Windows system configuration

Technical Breakdown

Components & Configuration

Network Tunnelling
A self-hosted tunnel configuration that exposes the development machine's RDP port through an encrypted tunnel without requiring port forwarding on the router or a static IP. The tunnel terminates on a small always-on relay. Traffic stays within controlled infrastructure.
DisplayPort Multi-Monitor Persistence
A known issue with remote desktop on Windows is that physical DisplayPort monitors disconnect from the GPU when no physical session is active, collapsing to a single virtual display. The fix involves a combination of EDID ghost displays (virtual display adapters that hold monitor configurations) and registry-level persistence settings to keep the full monitor layout available during remote sessions.
GPU Scheduling Under Remote Load
Running heavy development tools (UE5, Topaz) during a remote session requires the GPU scheduler to not starve the remote session renderer. Hardware-accelerated GPU scheduling was configured with specific priority overrides for the remote desktop pipeline.
PowerShell Session Scripts
Startup scripts that verify the tunnel is active, check display configuration, and set GPU scheduling before any development work begins. Each check logs its result so failures are identifiable without needing to debug interactively.

Challenges & Lessons

What I Learned Setting This Up

The DisplayPort persistence problem consumed the most time. The issue was non-obvious because the symptom (collapsed monitor layout) appears immediately on remote connection, but the root cause (display driver releasing the DP link) is several layers below where Windows exposes any configuration. The EDID ghost display solution is a well-known workaround in the remote desktop community but is nowhere in official Microsoft documentation.

Key lesson Windows remote desktop is designed for office environments with VGA monitors and no GPU workloads. Anything beyond that basic case requires going below the abstraction layer Microsoft provides. The registry and driver configuration documentation in community resources is more complete than anything official.

The no-cloud-dependency requirement turned out to be simpler to satisfy than expected. A small relay server running a single tunnel daemon is cheaper, faster, and more reliable than every commercial remote access product tested before this setup was built.