Tunnels

A Tunnel (conduit-tunnel) is a small Go binary an MSP deploys on a customer’s own infrastructure so the customer’s on-prem systems (SQL Server, legacy ERPs) are reachable through Conduit — without opening any inbound port on the customer’s network. The Tunnel dials WYRE’s relay outbound and comes online empty: which connectors run and how they’re configured is managed centrally in Conduit and pushed down the tunnel.

This page orients you. The deeper docs are linked below by goal.

When you want it

In Conduit, every vendor an MSP onboards for a customer uses one of three wiring patterns (decided in the Onboard-MCP wizard — see Onboarding a customer):

• Bring Your Own Credentials (BYOC) — each user supplies their own API key.
• Shared credentials — you supply one set of credentials, all users go through it.
• Self-hosted (via a Tunnel) — the customer runs conduit-tunnel on their own infrastructure, reached through the tunnel.

A Tunnel is the third pattern, and it carries two kinds of traffic: built-in connectors running next to the customer’s systems (read-only SQL, a local MCP server — see Using the connectors), and on-prem vendor egress — Conduit’s own cloud vendor integrations (e.g. ConnectWise PSA) reaching a server that lives on the customer’s network (see On-prem vendors via Tunnel). Pick it when:

• The customer runs a self-hosted instance of a supported vendor (an on-prem ConnectWise PSA server, LAN-only or behind a private CA) that Conduit’s cloud can’t reach directly.
• The customer’s security review or compliance posture bars third-party custody of vendor credentials.
• The customer has on-prem systems (SQL Server databases, legacy ERPs) that have no cloud-callable MCP equivalent — a connector has to live next to the system.
• Data-residency rules require vendor responses to stay on the customer’s network.

If those don’t apply, BYOC or Shared is simpler — no on-prem service to deploy and operate.

What you get

• One small static binary (~12 MB). conduit-tunnel runs as a service on the customer’s host — no container, no runtime to install. Linux (systemd) and Windows (a signed service install) both ship today.
• Outbound-only. The Tunnel dials WYRE’s relay over WSS and binds no inbound port — it opens no new attack surface on the customer’s network.
• Comes online empty (identity-only enrollment). The enrollment token carries only the customer’s org identity — no capabilities. The Tunnel registers with zero capabilities; your Conduit operator then chooses which connectors run and configures them from Conduit.
• On-prem vendor egress with an exact, derived allowlist. A vendor connection saved with the Via Tunnel deployment sends its API calls through the tunnel to the customer’s own server — private CAs included — and the Tunnel’s bridge can only reach hosts org admins explicitly connected, nothing else.
• Config encrypted at rest, held in memory only. Connector config (endpoints, credentials) is encrypted at rest in Conduit (AES-256-GCM), only ever travels over the TLS tunnel, and the Tunnel keeps it in memory — never written to disk. If the Tunnel restarts, Conduit re-pushes the stored config automatically (within ~60s) — no manual action.

Legacy: v1 Docker container

Already-deployed sites run the v1 conduit-onprem-gateway Docker container, which is still supported. It uses the older model (a CAPABILITIES env var + capabilities baked into the enrollment token). If that’s you, keep to the legacy flow — see Quickstart → Legacy: v1 Docker container. New deployments should use a Tunnel.

What’s here now vs. coming

Here now: one-line installers for Linux and Windows (the Windows binary is Authenticode-signed and installs as a service, optionally under a gMSA), self-service Connections → Tunnels pages (mint tokens, configure connectors, rename/disable/delete), and on-prem vendor egress — Conduit’s cloud vendor integrations (ConnectWise PSA first) reaching a server on your network through the tunnel, private CAs included. Still coming: packaged RMM fleet-rollout recipes and per-user SQL enforcement (EXECUTE AS).

For the full security model — data flow, the security properties, config encryption, one-tunnel-per-org routing, and audit-log split — see the Architecture Context page (written for the security/compliance review most MSP deployments need).

Go to

• Quickstart — deploy a Tunnel as a service (binary + systemd + two env vars). For MSP ops doing first deploy.
• Architecture Context — what a Tunnel is, the security spine, data flow, config encryption. For security / compliance review before deploy.
• Reference — the env-var contract, the built-in connectors catalog (echo, mssql, postgres, mysql, mcp-proxy), and the config model.
• SQL Server — the read-only on-prem SQL Server path via the mssql connector.
• Troubleshooting — failure modes and fixes. Error messages appear verbatim as section headings so you can search-key directly from the error you saw.

Related

• Onboarding a customer — where a Tunnel fits in the customer-onboarding flow (the Self-hosted wiring pattern in the Onboard-MCP wizard).
• Subtenant model — the multi-tenant security model a Tunnel extends.