Stable

Connectors

Administrator setup for the outbound connector: package access, runtime values, network reachability, readiness, diagnostics and rotation.

Steps

Follow these in order.

  1. 01Create the connectorIn the dashboard open Workspace settings → Connectors, add a connector and copy its install command/token.
  2. 02Download the connectorGet the connector binary or Docker image from Downloads for your OS — or use the install command from step 1, which pulls it.
  3. 03Run it where the app livesStart the connector inside the network with the app. It dials out to BusinessProxy — no inbound firewall port.
  4. 04Wait for “online”The connector status flips to online when the outbound tunnel is established and authenticated.
  5. 05Scale to high availabilityFor production, run two or three connector instances with one connector ID and distinct instance IDs.
  6. 06Allowed upstreams and configuration snapshotThe connector only reaches explicitly published upstreams (a controlled snapshot). It is not a general bridge.
  7. 07Rotate or revoke credentialsConnector credentials can be rotated and revoked from the account; access fails closed on loss.

Reference

Implementation details for setup and review.

Package access and installationConnector builds are issued from the account downloads area after access is enabled. Use the account-specific install command or package for the target operating system, then verify the checksum and signature before running it.
Required runtime valuesDo not publish real connector tokens in docs, screenshots or support tickets. Store the runtime token immediately after it is shown.
  • BUSINESSPROXY_API_URL — BusinessProxy API endpoint.
  • CONNECTOR_WORKSPACE_ID — workspace that owns the connector.
  • CONNECTOR_ID — connector identifier from the workspace.
  • CONNECTOR_TOKEN — one-time runtime token shown after creation or rotation.
Network reachability
  • Connector to BusinessProxy API: outbound TCP 443 for HTTPS and tunnel traffic.
  • Connector to internal app: internal DNS and TCP/TLS reachability to each configured app URL.
  • External user to public app address: HTTPS 443 to the issued app host.
  • Do not open a public inbound port to the connector.
Readiness and fail-closed statesReady means the connector is online and the heartbeat is fresh. Draining, stale, offline or missing connector states close new launches, diagnostics and private app access until the connector returns online.
High availability modeFor production private apps, run the connector as a server process under Kubernetes, systemd or Docker Compose. Use the same connector record and runtime token, but give every process a distinct CONNECTOR_INSTANCE_ID. Do not count the desktop wrapper as a high-availability runtime.
  • Use two instances for normal redundancy and three when API replica coverage, rolling restart margin or customer policy requires it.
  • Place instances on separate hosts or nodes when the goal is host-level failure tolerance.
  • Use the detailed high-availability guide before enabling this for a customer environment.
Rotation and maintenance
  • Rotate the connector token from the dashboard or API.
  • Store the new token in the connector host secret store.
  • Restart the connector with the new value and confirm that readiness returns to Ready.
  • If maintenance requires an immediate access cutoff, revoke active private app sessions separately.
Diagnostics and support-safe failure dataDiagnostics should verify DNS, TCP, TLS and HTTP from the connector side. When opening a support ticket, include sanitized connector status, readiness, diagnostic result and timestamp; do not include runtime tokens, token hashes, internal app addresses, private IPs or custom CA material.