Sign in
Stable

Private apps and policy

Define one app: public addresses, upstreams, location rules, allow/deny presets and session TTL.

Key topics

Use these topics to orient setup and security review.

  1. 01What counts as "one app"Aliases, upstreams, related origins and WebSocket routes.
  2. 02Public address, browser hosts and upstreamWhich hostname is public, which hostname may stay private, and which address the connector must resolve.
  3. 03CORS and related API originsWhen frontend and API are separate origins, publish the API as a related origin instead of letting the browser call it directly.
  4. 04Location rules: route, response, allow, denyAllow-list default-deny and reports-only presets.

Reference

Implementation details for setup and review.

Public app address and launch sessionA public app address represents one approved internal web app. The user opens it after BusinessProxy exchanges a one-time launch token for an app session and removes that token from the URL.
  • The public host identifies the app.
  • Subsequent requests require a valid app session.
  • The connector reaches the internal app; the user does not see the internal hostname or private IP.
Public address, browser host and internal upstreamKeep these three values separate when publishing an app. The public app address is the HTTPS address users receive from BusinessProxy, for example crm-abc123.business-proxy.com or a verified customer domain. A published browser host is an optional hostname users may type because the original app, bookmarks or documentation already use it. The internal upstream is the real URL opened by the connector, for example http://crm.internal:8080 or https://10.0.12.15.
  • Public app address: must resolve publicly to BusinessProxy and identifies the gateway-side app session.
  • Published browser host: may be a private or split-horizon hostname. It only works for users while the extension is signed in, connected and has the current routing snapshot.
  • Internal upstream: does not need public DNS, but the connector host must resolve and reach it. If the connector runs outside that network, the app will stay unavailable even if the browser host is configured correctly.
  • Do not use this field to claim ownership of arbitrary domains. Published browser hosts are routing hints for known private apps, not a replacement for DNS control or domain verification.
Connector readiness and fail-closed behaviorBefore relaying app traffic, BusinessProxy checks that the app is enabled and the assigned connector is ready. If the app is disabled, the session is missing, or the connector is unhealthy, the gateway returns a sanitized error instead of exposing internal topology.
Rewrite behaviorSome internal apps redirect to their own hostname or set cookie domains for that hostname. When enabled in app configuration, matching internal Location headers and matching Set-Cookie Domain attributes are rewritten to the public app host. Host-only cookies and external redirects are preserved.
CORS and related API originsIf the app opens at https://crm-abc123.business-proxy.com or a custom alias such as https://app.example.com, but JavaScript calls https://api.example.com, the browser treats that as cross-origin and may block it before BusinessProxy can relay the response. Add https://api.example.com to Related origins so calls are rewritten through the same app alias.
  • Expected shape: https://crm-abc123.business-proxy.com/__bp_related/https/api.example.com/v1/users, or the same /__bp_related/ path under the custom alias.
  • Use a Location route rule only when that related origin or a path prefix must be sent to a different internal upstream or WebSocket service.
  • WebSocket is supported for listed related origins: browser wss:// calls are rewritten to wss://<app-alias>/__bp_related/https/api.example.com/..., while the Related origin value remains https://api.example.com.
  • If DevTools still shows https://api.example.com directly, check cached bundles, service workers, CSP, content encoding and runtime config that keeps the absolute API URL.
Internal app TLSFor live deployments, configure internal apps with certificates trusted by the connector host. Diagnostics should verify DNS, TCP, TLS and HTTP end to end before production access.
Headers and logged dataThe private app path relays HTTP method, path, query, headers and bodies in transit. Bodies are not logged or stored; transport-only headers are filtered before the upstream request.
Deployment-specific commands, package versions and runtime credentials are shown in the account downloads area after sign-in.