Deploy the StreamGate relay on a public host, keep one stable domain for it, and make the service reachable through one predictable secure public entrypoint.
Quick start
The shortest route from zero to a working service tunnel.
Register by email, receive the access key, then use that key in the client. The access key binds the user, routes, node ownership and subscription state.
Run one client on the machine that can reach the protected service and another on the machine where the consuming app lives.
On the provider machine create a Publish route to the real internal endpoint. On the consumer machine create a Listen route that maps a local port to the same route key.
Provider node: Publish Route key: exchange-main Target host: exchange.internal.local Target port: 443 Consumer node: Listen Remote route key: exchange-main Local host: 127.0.0.1 Local port: 8443
Core concepts
These are the objects that matter when you design a deployment.
The public relay and control plane. It holds user access state, versions, route definitions, session visibility and dashboard operations.
A machine identity. Routes stay attached to the nodeId, because routes describe what that machine can provide or consume in a stable way.
A specific running copy of the client on a machine. Multiple app instances can exist under one access key, but they are still just instances on top of one or more nodes.
A named service path. Provider routes publish real internal targets. Consumer routes listen locally and point at a provider route key.
General routing pattern
Nearly every successful deployment follows the same sequence.
1. Put CS on the machine that already has direct access to the protected target. 2. Publish the target under a stable route key. 3. Put CS on the machine where the real consuming app runs. 4. Listen locally on the host and port shape that app already expects. 5. Point the consuming app at the local listener instead of the original unreachable endpoint.
Name by service meaning, not by temporary infrastructure details. exchange-main is better than server42-prod-a.
Use clear local ports and note them in your app config so operators can see exactly what has been mapped.
Provider nodes stay close to the protected resource. Consumer nodes stay close to the real user workflow or workload.
If the app only needs one exact service, publish one exact service. Avoid broad remote-access workarounds unless the real task truly requires them.
Common cases
These are the most frequent patterns where StreamGate is a better fit than broad VPN or one-off forwarding.
Outlook / Exchange / Autodiscover
Use a provider node near Exchange and a consumer node on the workstation. The listener gives Outlook a reachable local endpoint for the Exchange path it expects.
- Publish the Exchange or Autodiscover target from the node inside the mail environment.
- Listen on the user machine using the expected host override or local proxy mapping.
- Point the mail client or host override to the local StreamGate listener.
Jira / Confluence / internal portals
When the browser or integration tool only needs a specific HTTPS endpoint, publish the internal portal from the provider side and listen locally on the consumer side.
- Provider target:
jira.internal.local:443 - Consumer listener:
127.0.0.1:9443 - App or browser target: local port or local reverse proxy in front of it
SQL Server / PostgreSQL / Redis
Perfect for desktop tools, migration utilities and BI clients that only need one database port, not full network membership.
- Publish the database port on a machine that already reaches the database privately.
- Listen locally where the tool runs.
- Keep credentials and app config unchanged except for the endpoint host and port.
RDP / SSH / maintenance
Use StreamGate when you need a narrow maintenance path to one host without authorizing a broad remote-access environment.
- Provider publishes the private host's maintenance port.
- Consumer listens locally and connects using ordinary RDP or SSH tooling.
- Operator can later remove the route and close the path cleanly.
Private APIs and webhook consumers
Useful when an internal API should only be reachable from a very specific worker or workstation.
- Publish the API from inside the private environment.
- Listen on the build runner, sync job or integration host that needs it.
- Keep the API private and service-shaped instead of opening a whole network corridor.
CI/CD, artifact stores and license servers
Build workers often need just one protected dependency. StreamGate lets the runner see that dependency locally without making the runner a permanent trusted network island.
- Publish: artifact registry, license server, package mirror
- Listen: local endpoint on the build worker
- Use ordinary client tooling against the local endpoint
Operations and updates
How the control plane behaves once the route model is already working.
M advertises the currently served client package. Connected clients learn about new versions from the relay, not from aggressive polling.
M keeps a version catalog, can switch versions, and when installed as a Windows service can update its service target to a new versioned executable path.
Routes, nodes, sessions and app limits are all tied to the access-key owner. Each user only sees and consumes their own data.
Routes remain bound to the node identity, so a machine keeps owning its service map even if several app instances run on it over time.
Security notes
The security story should align with the routing story.
Nodes use one stable secure entrypoint to M. The relay remains the only public control-plane host you need to expose.
After the outer TLS connection is up, StreamGate still performs its own authenticated session establishment before payload frames are switched.
The relay can reject missing, expired, blocked or revoked access keys and can steer renewal flows through the subscription portal.
The design stays intentionally service-shaped. That is the core difference versus traditional network-wide remote-access tools.
Troubleshooting
These are the first places to look when a route does not behave the way you expect.
The client connects, but the app still cannot reach the service.
Check the local listener host and port, verify the route key matches between provider and consumer, and confirm that the provider node can really reach the protected target directly from its own machine.
The provider is online, but no session opens.
Make sure the publish route exists on the correct node, the user owns both sides of the route relationship, and the consumer is listening for the same remote route key.
The consuming app works only while the client is in the foreground.
Use the tray-enabled client build, keep the node connected, and avoid closing the app entirely if the route should remain alive in the background.
A client update is available but not appearing immediately.
Connected clients learn new packages from the relay snapshot. If the client is offline, the manual Check path is still available on a slower interval.