Use cases
What teams actually build with Peerlify.
Each page below is a concrete job — the problem, how Peerlify solves it, the rules you would write, and the parts that are not finished yet. No hypotheticals.
Platform & IT teams
Remote access to private infrastructure
Reach servers, VMs, and lab hardware that have no public address — without opening an inbound port or standing up a jump host.
- No inbound ports to open
- Access rules by user, group and tag
- Direct paths when possible, encrypted relay otherwise
Helpdesk & IT support
Remote support and screen shadowing
View or take control of a signed-in Windows or Mac desktop over your own mesh — its own rule family, with optional consent prompts.
- A separate rule family from traffic
- Consent prompts and view-only mode
- Sessions and denials logged on Business and Enterprise
Common ground
True in every one of them.
- Nothing accepts inbound connections
- Every enrolled machine dials out. No port-forward, no bastion, no public DNS record for the thing you are reaching.
- Encrypted end to end, relay or not
- Noise IK with P-256 static keys and AES-GCM transport ciphers. A relay forwards ciphertext and can read nothing.
- Access follows your identity provider
- Rules are written against tags, roles, and groups. Offboard someone in your IdP and their sessions die with the token.
Still weighing the approach?
Concentrators, cloud proxies, and self-hosted meshes all solve a version of this. Here is what each one costs you, and where an identity-scoped mesh is the wrong answer.