Connect on-prem ConnectWise PSA through a Tunnel

This is the complete, in-order onboarding for a self-hosted ConnectWise PSA (Manage) server — LAN-only or behind your own CA — from nothing deployed to a verified AI tool call. Nothing on your ConnectWise server changes, and your network accepts no inbound connections: one small agent on any box you own dials out, and ConnectWise API traffic rides that connection.

The same flow applies to any vendor with the Tunnel-capable badge in the catalog; ConnectWise PSA is the flagship.

This is different from the Generic MCP server connector

The mcp-proxy connector runs a vendor’s MCP server on your host and keeps the credentials on your network. This page is the other pattern: Conduit’s own vendor integration (cloud-hosted, always current) reaches your server through the tunnel. Credentials are stored encrypted in Conduit; only the API traffic crosses the tunnel. Pick per customer based on credential-custody requirements.

Which path do you need?

Your ConnectWise server is…	Use
Reachable from the internet over HTTPS with a publicly-trusted certificate	No tunnel needed — fill in Server URL on the normal connect flow and you’re done
LAN-only (no inbound access), or public but with a private-CA / internal certificate	This page — all six steps

What you’ll need before starting

1. ConnectWise API credentials — a Company ID, an API member’s Public/Private key pair, and a ConnectWise-registered ClientID (yes, registration is still required for on-prem servers). Creating these on the ConnectWise side is covered in the ConnectWise PSA activation guide — the on-prem steps are identical in the ConnectWise UI.
2. Your server’s internal address — as resolvable from the box that will run the Tunnel, e.g. https://cw.internal. It never needs to resolve from the internet.
3. Your CA certificate (PEM) — only if the server’s TLS certificate is signed by your own/internal CA. Export the CA cert (the full -----BEGIN CERTIFICATE----- block).
4. A host for the Tunnel — any always-on Linux (systemd) or Windows box on the same network, with outbound 443. It does not need to be the ConnectWise server itself (and typically shouldn’t be).
5. Conduit org-admin access.

Step 1 — deploy the Tunnel

In Conduit: Connections → Tunnels → Add Tunnel. Conduit mints an enrollment token and shows a copy-paste command with everything filled in. On your chosen host, paste it:

# Linux (as shown by Add Tunnel — token already filled in):
curl -fsSL https://conduit.wyre.ai/get/tunnel.sh | sudo ENROLLMENT_TOKEN=<from Add Tunnel> bash

# Windows:
& ([scriptblock]::Create((irm https://conduit.wyre.ai/get/tunnel.ps1))) -Token '<from Add Tunnel>'

That installs a hardened service running the current pinned release, dialing out over WSS. Details, manual/air-gapped installs, and the service model are in the Quickstart.

Step 2 — confirm it’s online

Back on Connections → Tunnels, your tunnel appears with a green online dot (typically within seconds). Give it a name you’ll recognize (“HQ — cw-bridge box”). If it doesn’t come online, the Troubleshooting page maps every boot error verbatim.

Step 3 — connect ConnectWise with the Via Tunnel deployment

1. Connections → Catalog → ConnectWise PSA → Connect (in your org’s context — coming from the org admin surface or the catalog keeps you there).

2. A Deployment selector sits above the credential fields — it appears because Conduit can see your live tunnel:

   • Cloud / self-hosted (direct) — for internet-reachable servers.
   • Via Tunnel — pick this.

   No selector? Your tunnel isn’t online — go back to step 2.

3. Server URL — enter the internal address from your checklist (https://cw.internal). Give the bare root; Conduit appends ConnectWise’s API path (/v4_6_release/apis/3.0) automatically. When you pick Via Tunnel, the field’s label makes this explicit: it’s the address inside your network.

4. Private CA certificate — paste the PEM if your server uses your own CA. The TLS handshake to your ConnectWise server happens on your own host, on your own network, trusting exactly this CA for exactly this server.

5. Credentials — Company ID, Public Key, Private Key, ClientID from your checklist. Stored AES-256-GCM-encrypted in Conduit; they ride each API call through the tunnel and are never persisted on your host.

6. Connect.

Step 4 — what save does (and the one warning you might see)

On save, Conduit verifies your tunnel is live, stores the connection with its tunnel routing, pushes your server onto the Tunnel’s host allowlist (the bridge may only reach servers connected this way — nothing else), and runs a reachability probe through the tunnel to your server.

If the success page says “Saved, but nothing answered at the server URL through the Tunnel yet” — the connection is saved; the allowlist push may still be applying, or the URL/port is wrong. Give it a minute; if it persists, see when something fails.

Step 5 — grant access

Like every Conduit vendor, a new connection is usable by no one until the org grants it: Access → grant connectwise-psa to the members or teams who need it, at the tier that matches (read for lookups, write for ticket/entry creation). Details: Granting access.

Step 6 — verify end to end

From an AI client connected to Conduit (as a granted member), ask for something real — “show me open ConnectWise tickets for customer X.” The call goes client → Conduit → tunnel → your ConnectWise server and back. Nothing about the tunnel is visible to the end user; ConnectWise behaves like any cloud vendor from here on — same tools, same audit log.

That’s the whole onboarding. What follows is reference material.

How a request travels

MCP client ──HTTPS──▶ Conduit ──(signed egress URL)──▶ egress route
                                        │
                                   WSS tunnel  (the same single outbound
                                        │       connection your Tunnel dialed)
                                        ▼
                          http-bridge on the Tunnel host
                                        │  allowlist check + your CA trust
                                        ▼
                          your ConnectWise server, on your LAN

The vendor integration itself still runs in Conduit’s cloud (so it stays current); only its API calls are carried over the tunnel and re-issued locally by the Tunnel’s built-in http-bridge. The bridge will only connect to hosts on its cloud-synced allowlist — exactly the servers org admins have wired up, nothing else — so the tunnel can never be used to browse your network.

Switching a connection back to Cloud

Re-connect the vendor and pick Cloud / self-hosted (direct). The tunnel routing is removed and the Tunnel’s allowlist is automatically re-synced without the old host — no residue on the bridge. The same happens when you delete the connection.

When something fails

Verbatim messages and their fixes are in Troubleshooting — most commonly:

• no online connector site for this org on save → the tunnel is offline; bring it online first, then save again.
• Probe warning on the success page → saved, but nothing answered: wrong LAN URL/port, the server is down, or the allowlist push hasn’t been ACKed yet.
• TLS failures in the probe detail → the server’s CA isn’t the one you pasted (or none was). Fix the PEM — avoid disabling verification; an insecure per-host override exists in the API as a documented last resort for appliances with unexportable certificates, but prefer the CA.
• Access denied on tool calls → step 5 was skipped, or the tier is too low for the tool.