← Back to Guides

    Remote debugging on edge devices (without VPN): make it feel like localhost

    You can debug an edge device behind NAT without a VPN by using the device's persistent QUIC connection plus port/socket forwarding. With m87 (make87's command line + device runtime), your IDE, browser, and dev tools connect to localhost on your laptop while m87 forwards that traffic to the device — so remote debugging feels like local development.

    When you want this

    This approach works when your device is behind NAT, CGNAT, or a network with egress filtering — and you need to attach a debugger, open a local UI, or hit a service running on-device. It avoids the overhead of managing VPN access, inbound firewall rules, or SSH tunnels.

    The mental model

    Your tools stay local. Your IDE, browser, or client connects to localhost on your machine. The m87 CLI forwards that connection through the make87 platform to the device runtime, which routes it to the target service:

    localhost → m87 CLI → make87 platform → device runtime → service

    No inbound ports, no router changes, no special dev network.

    Quick start (example)

    1) Confirm the device is reachable

    m87 login
m87 devices list

    2) Start or identify the service you want to debug on the device

    Examples:

    • HTTP service on port 8080
    • Python debug server on port 5678
    • gRPC service on port 50051

    3) Forward a port from device → your laptop

    Example: forward an on-device HTTP service to your laptop:

    m87 <device> forward 8080:localhost:8080

    Now use your normal workflow locally:

    • open http://localhost:8080 in your browser
    • run a local client against localhost:8080

    IDE attach example (debugger)

    If your debugger expects to connect to localhost:<port>, forwarding is the bridge.

    Example (debug server port 5678):

    m87 <device> forward 5678:localhost:5678

    In your IDE:

    • attach to localhost:5678

    Your IDE stays unchanged. Only the transport changes.

    Socket forwarding (when ports aren't enough)

    If your workflow relies on Unix sockets, gRPC streams, or custom TCP protocols, the same approach applies: keep your local tooling pointed at localhost, and forward the underlying connection via m87.

    Remote development with SSH-based IDEs

    IDEs like JetBrains (PyCharm, CLion, GoLand), Zed, and VS Code have built-in remote development features that connect over SSH. To use these with m87:

    1) Enable SSH access

    m87 ssh enable

    This configures your local SSH client to reach m87 devices via the <device>.m87 hostname.

    2) Configure your IDE

    Point your IDE's remote development feature to <device>.m87:

    • JetBrains: Remote Development → SSH → rpi.m87
    • Zed: Remote Projects → rpi.m87
    • VS Code Remote SSH: Host rpi.m87

    3) Develop remotely

    Your IDE connects through the m87 tunnel. Edit files, run debuggers, and use terminals — all on the remote device.

    This gives you full IDE features (indexing, refactoring, debugging) running on the edge device, with the UI on your laptop.

    Why this is different from "just SSH + tunnel"

    Port forwarding is not new — what changes is the default assumption. The device doesn't need inbound access, you don't distribute SSH keys, there's no bastion host to maintain, and no VPN is required. The result is a consistent developer experience that works on real devices in real networks.

    Alternatives (and tradeoffs)

    VPN (WireGuard / Tailscale-style)

    Pros:

    • Full Layer 3 network access once connected
    • Peer-to-peer connections possible (reduced latency when hole-punching succeeds)

    Cons:

    • PKI/certificate distribution or pre-shared key management per device
    • Persistent daemon and always-on connectivity required
    • Subnet/IP allocation conflicts when devices roam between networks
    • Split-tunnel vs full-tunnel policy decisions per environment

    SSH tunnels / port forwarding

    Pros:

    • Native on most Linux devices; no additional software
    • Standard protocol with broad tooling support

    Cons:

    • Inbound port 22 (or custom) exposed through NAT/firewall
    • authorized_keys management across fleet or SSH CA setup
    • Manual ~/.ssh/config or ProxyJump chains per device
    • Key revocation requires touching every device or CA infrastructure

    Bastion host (jump box)

    Pros:

    • Centralizes access; single point for audit logging
    • Native SSH tooling (ProxyJump, scp, port forwarding)

    Cons:

    • Hardened host with patching, monitoring, and HA considerations
    • Single point of failure; all sessions route through one endpoint
    • Session logging and audit compliance add complexity
    • Bandwidth bottleneck for file transfers or high-throughput debugging

    FAQ

    Do I need a VPN?

    No. The m87 runtime maintains a persistent QUIC connection (TLS 1.3), and m87 forwards ports/sockets over that channel.

    Does this work behind CGNAT?

    Yes — the outbound-only model works regardless of NAT/CGNAT topology.

    Do I have to run a daemon?

    No. The m87 runtime can run in the foreground for development; in production it's typically run as a service.

    Is this SSH?

    No. m87 provides an interactive workflow and forwarding primitives without requiring inbound SSH access.

    Next