Private network membership
Engineer → private network → server, database, printer, internal APIs, and every other reachable Device on that network.
TunnelCrib secure access
Access without
exposure.
Access the service. Not the network.
TunnelCrib gives an authorized user a temporary encrypted Tunnel to one approved Service on one registered Device — without making that user's machine a member of the surrounding private network. Device identity verification, per-Service authorization, and Tunnel activity logging, no VPN required.
- Direct first
- P2P when available
- Encrypted
- SSH transport
- Controlled
- Organization scoped
TunnelCrib / secure Tunnel
$ tunnelcrib connect production-db:ssh
+ device identity verified
+ direct Tunnel negotiated
+ Service Tunnel active
localhost:49318
TunnelCrib
Client
Client
TunnelCrib
Relay
Relay
TunnelCrib
Agent
Agent
Service
See TunnelCrib in action
From Device to Service in a few clicks.
The preview plays automatically without sound. Open it to watch the full-size video with playback controls.
Remote access should be deliberate, visible, and temporary. TunnelCrib creates a temporary Tunnel from TunnelCrib Client to a selected Service on a Device without turning that Device into a public-facing service. It does this without requiring the user's machine to join the Device's private network.
Not a private network
A private overlay network grants reachability.
TunnelCrib grants one Service.
TunnelCrib Service Tunnel
Engineer → temporary Tunnel → one approved Service, e.g. PostgreSQL on localhost:49318. Nothing else on the Device or network is reachable.
The platform
One access layer.
Built for the Devices you already have.
Direct when it can be
TunnelCrib Client first attempts a direct Tunnel to the TunnelCrib Agent on your Device.
Relay when it must be
When direct connectivity is unavailable, a TunnelCrib Relay carries the Tunnel without changing how you access the Service.
Services your teams use
Access approved remote shell, remote desktop, remote management, web, database, and custom TCP Services through a local port.
Security by design
Every path starts with identity.
Devices are registered to an organization, Agents prove possession of their keys, and each Tunnel reaches only the requested Service.
Read the security documentationDevice verification
Known Device identity and nonce signatures before a Tunnel is accepted, backed by TPM/Secure Enclave hardware where available. See device identity.
Temporary Tunnels
Fresh Tunnel credentials and automatic Relay process expiry.
Service forwarding only
No remote shell, exec, or PTY access through the Relay layer.
Organization boundaries
Clients, Devices, and Private Relays stay within their organization.
Agent access policy
Allow or deny which Clients may reach a given Agent, per Service.
Organization-scoped activity log
Every Tunnel request, grant, denial, and session is recorded to a durable, per-organization audit log, viewable and filterable in the admin console. See audit events.
Private Relay
Bring the fallback path closer to home.
Run a Private Relay in your environment. TunnelCrib uses it only when TunnelCrib Client and TunnelCrib Agent cannot establish a direct Tunnel.
A Private Relay keeps fallback Tunnel traffic within infrastructure controlled by your organization. TunnelCrib-hosted Relays remain available when it is offline.
private-relay.env
PUBLIC_HOST=relay.example.com
RELAY_PORT_START=1337
RELAY_PORT_END=2337
MAX_SESSIONS=10
./tunnelcrib-bridgeStart a conversation
Access should not be the weak link.
Tell us about your Devices, Services, access requirements, and operational constraints.
Talk to TunnelCrib