Use case

Production database access without a VPN route

The problem

A developer needs to run a one-off query or investigate an incident against a production PostgreSQL instance that is not publicly reachable.

Why traditional network access is excessive here

Putting the developer's laptop on the production VPN gives it a route to every other production system reachable from that network segment — not just the one database the investigation requires.

How TunnelCrib handles it

A TunnelCrib Agent runs alongside the database (or on a Device that can reach it on localhost) and advertises the database as an approved Service. The developer's TunnelCrib Client requests a Tunnel to that Service only.

Setup example

$ tunnelcrib connect prod-db-02:postgres
device identity verified
direct Tunnel negotiated
Service Tunnel active
localhost:49318
$ psql -h localhost -p 49318

Authorization example

Database access can be time-boxed for the duration of the incident by revoking the Agent-access policy grant once the investigation is complete; new Tunnel requests after revocation are denied at the Central Server.

User experience

The developer runs their existing psql client against localhost:<port> using their normal database credentials — TunnelCrib does not replace or see those credentials, it only carries the TCP connection.

Audit trail

The connect request, grant, and session duration are recorded for later review (see audit events).

Security considerations

No inbound port is opened on the database host to the public internet, and the developer's machine gains no route to any other production system. See what the Relay can see if the session falls back to a Relay path.