Self-Hosting: Keep Your AI Agent's Data on Your Own Servers
Once AI Agents start taking on real engineering work, one question becomes harder and harder to avoid:
Where do your code, your sessions, and your prompts actually live?
When the Agent only writes a snippet once in a while, the answer doesn't matter. But when it works for hours at a time, reads and writes your real codebase, and remembers your project conventions and preferences, "data sovereignty" stops being compliance jargon and becomes a daily concern for every developer.
Self-hosting isn't paranoia about the cloud. It's the plain requirement that my data should be controlled by me.
Helix's position has always been direct: Agents run on your machines, and the way you connect is determined by your scenario. Today I want to talk about the three paths that make this real: direct connection, self-hosted tunnels, and VPN networking.
First, Get Clear: Why Do You Need Self-Hosting
Everyone has their own reasons, but they mostly fall into four buckets:
Data sovereignty. Code is one of the most valuable assets a company has. Handing the full context of your codebase, session history, and even your hard-won lessons to a third party is a non-starter for many teams — especially finance, healthcare, and government.
Private network access. Agents usually run on the company intranet (the most common deployment), but you need to reach them from home, from client sites, from anywhere. Intranet machines typically have no public IP, which means you need a secure channel.
Compliance and audit. Data-residency limits, internal audit requirements, access-control policies — these are often murky on cloud SaaS, but crystal clear on your own servers.
Cost structure. The team already has servers. Why pay per seat and per usage to a SaaS vendor on top of that? After self-hosting, marginal cost approaches zero.
Helix was architected for this from day one: desktop, backend, and web clients can all point at your own Agent instances. The only remaining question is — how do you connect?
Path One: Direct Connection
The simplest case: your computer and the Agent are on the same LAN. The office desktop runs the Agent; your laptop connects over the same Wi-Fi.
This scenario needs no extra infrastructure. The client discovers Agent instances on the local network and connects directly — lowest latency, fastest throughput.
But direct connection has a ceiling: it only works on the same network.
Once you leave the office, or the machine sits behind NAT, direct connection dies. That's when you need path two.
Path Two: Self-Hosted Tunnel — A Secure Channel Through NAT
This is what most people need. The idea:
Deploy a gateway (we call it EasyGateway) on your own server. The internal Agent actively connects out to the gateway. You reach the subdomain assigned to your node from any network, and traffic is securely forwarded to the internal Agent.
Your device (any network) ◄──encrypted──► Gateway (your server) ◄──subdomain route──► Internal Agent
Note the key point: the internal Agent connects outward to the gateway, rather than the outside punching inward through your firewall. No router changes, no public IP application, no port forwarding. NAT is circumvented, not penetrated — home networks, office networks, and cloud VPC machines are all treated the same.
Design Choices Worth Talking About
Mutual TLS. It's not "anyone who connects gets in." Nodes request client certificates via CSR at startup, and only verified nodes can join. All transport is encrypted. You never expose a raw port to the public internet.
Subdomain routing. Each node gets its own subdomain (e.g. mybox.gw.example.com). Multiple machines never interfere, and you can see each device's connection status and real-time traffic from the gateway side.
Heartbeat & auto-reconnect. Network jitter is the norm. The control channel carries heartbeat detection; connections recover automatically after drops, and silently dead channels are detected and re-established. No 3 a.m. restarts.
Self-contained deployment. The gateway itself depends on nothing external — one config file and it runs, even on a fully offline intranet.
Typical Scenarios
- An Agent runs on office servers; you keep working from home with identical workspaces, sessions, and toolchains
- Temporarily show an internal web service to an external colleague without touching the firewall
- A team shares one self-hosted Agent; each member connects from their own client
Path Three: VPN Networking — Many Machines, One Virtual LAN
Tunnels solve "reach a single Agent." But real engineering often involves multiple machines that need to reach each other: an Agent on your laptop needs the office database, the build machine calls the test machine's API, the test machine pulls model-service endpoints…
For that, tunnel mode gets tedious — you don't want to open a tunnel per service. A more natural model: let these machines behave as if they're on the same LAN.
Helix's VPN client creates a virtual network interface on each device (macOS uses the system utun, Linux uses native TUN) and joins a virtual LAN maintained by the gateway:
- Each device registers its local subnets (e.g.
192.168.1.0/24) into a route table - Other devices forward packets using longest-prefix matching
- Packet forwarding happens entirely in user space — no admin privileges, no system route-table changes (no CGO dependency on macOS/Linux)
- Connections auto-recover after network switches (Wi-Fi → hotspot) without interrupting work
The experience: the office database IP just pings from your laptop. Local dev, multi-machine coordination, and cross-region team access to internal resources all collapse into one thing — "being on the same LAN."
Dual-Link Automatic Selection: The Fast Path, Automatically
One detail we spent real effort on: the connection shouldn't have just one route.
Helix maintains both direct and tunnel links simultaneously and continuously probes latency:
- Same LAN → automatically uses the direct link for lowest latency
- Cross-network → automatically switches to or parallel-uses the tunnel
- Link quality changes → automatically re-selects the optimal path
The practical effect: whether you're in the office or at home, Helix "invisibly" uses the fastest available path. There is no "manually switch connections" operation — connectivity is infrastructure, and users shouldn't have to think about it.
Security Model: Three Layers
Self-hosting is not "set up a service and let anyone in." Helix's security model has three layers:
- Transport encryption — client↔Agent API communication uses long-lived credentials plus a pairing flow; after first pairing, credentials are issued and every request carries identity verification
- Node authentication — gateway-side mTLS ensures certificates are valid and nodes are real; unregistered devices can't even establish a connection
- User authorization — the gateway can integrate with your user system to show which user owns each node, for auditing
Each layer has its own job: even if one layer is compromised, the other two still hold.
Which Path When
| Scenario | Recommended Approach |
|---|---|
| Same LAN | Direct connection |
| Reach an internal Agent from any network | Self-hosted tunnel |
| Multiple machines accessing each other's services | VPN networking |
| Both local and remote needs | Direct + tunnel (auto-selected) |
| Fully offline intranet | Self-contained gateway + tunnel |
Finally
The past two years of competition in AI coding tools was about "how strong is the model." But model capability converges — the choice over data and infrastructure is what really separates products.
Helix's choice: an Agent's compute can come from any model, but an Agent's data and runtime should be controlled by you. Self-hosted tunnels and VPN networking turn "controlled by you" from a slogan into daily operations.
If you also want Agents running on your own servers, join our community and tell us about your deployment scenario — real network environments are often more convincing than any architecture diagram.