Use cases
Start with the people and services that need to connect. Then define which devices, destinations and ports should be allowed.
Your engineers need to administer approved servers in several locations without a separate VPN tunnel project for each site.
Enroll their laptops and the servers. Give Server Engineers access to the approved destinations on the required SSH or RDP ports. Keep OS login and application permissions in place.
See server engineer access →Your web tier runs in one cloud, an application in another, and its database in a datacenter.
Permit only the intended application paths, such as HTTPS to the application and the actual database port from its approved clients. Existing LAN subnets stay in place; outbound connectivity and host/cloud firewall permissions still need review.
Explore multi-cloud connections →Two sets of servers must not communicate with each other, but the same engineers support both.
Use separate server groups and explicit rules from Server Engineers to each group. Group membership alone grants nothing. Remove broad allow-all permissions; narrow rules do not override them.
See the two-group diagram →You want to manage an enrolled home server or NAS from your laptop on another network.
Connect approved enrolled devices over encrypted peer paths. For a NAS that cannot run a client, a separately configured gateway can provide access to selected local resources. Keep permissions deliberate, even on a small network.
Explore home and hobby examples →A new server is enrolled, but its identity and intended role still need checking.
Use a Lobby label with no matching peer-access allowances, review the device, then assign the service groups its role needs. This requires checking all effective policies; Lobby is not a deny override or an automatic quarantine product.
Read the Lobby onboarding guide →Helpful building blocks
Private DNS can give an enrolled server a readable company name. Resolution and permission are separate.
How Private DNS works →Direct encrypted connections are preferred, with relay fallback. The controller coordinates rather than ordinarily forwarding application traffic.
Connections and regional relays →Review current Alpha scope and clearly labeled future service options before making deployment plans.
Offerings and availability →Tell us where your people and servers are, and what each should be allowed to reach.