What you control
Publish one app alias, bind it to one workspace connector, set the allowed workspace role and cap the session TTL.
Use case: contractor to internal appBeta
Give a contractor one internal app, not your network
A contractor needs an internal CRM, admin panel or partner portal for a limited project. A device VPN is too broad, a bastion is too heavy, and exposing the app directly would leak topology.
What stays outside
The contractor opens the alias in Chrome. They do not receive a network route to your VPC, and they do not see the internal upstream hostname or private IP. The alias path is a Layer-7 reverse proxy — see what it sees.
The alias path operates at Layer 7 — see the visibility disclosure on Private App Access.
Proof points
Backed by implementation
- One alias per internal web app, scoped to a workspace
- Launch/session token is short-lived, app-scoped and revocable
- The connector resolves the upstream inside your network
- Disabled apps and unhealthy connectors fail closed
- L7 alias visibility is disclosed: method, path, query, headers and bodies pass through in transit
When to use
- External contractors or partners need one web app.
- The app can run behind HTTP/HTTPS and tolerate reverse-proxy headers.
- You can run a connector close to the app.
- You want session TTL and revoke instead of broad network access.
When not to use
- You need full device networking, SSH/RDP, database tunnels or non-HTTP apps.
- You require automatic multi-connector HA today.
- You require group-based app policy today instead of workspace role policy.
- Your app cannot work behind a reverse proxy or requires unsupported custom TLS behavior.
Private App Access is in Beta. It's offered as sales-assisted early access while we complete production hardening — talk to us about a pilot.
Related use cases