Reach your database from anywhere

◐ in progress

Reach a database through an end-to-end encrypted relay that can route the traffic but cannot read it.

Reach your database from where you are, without the usual VPN scavenger hunt or jump-box ritual. An end-to-end encrypted tunnel passes through a relay that can route the traffic but cannot read it.

The three pieces

The bridge

A small daemon you run inside your network, next to the database. It dials out to the relay - so there is no inbound port to open, no firewall exception, and nothing new exposed to the internet.

The relay

A public forwarder that matches your client to your bridge and shuttles frames between them. It knows which session goes where; it does not know what is in it.

Your client

SQLly on your laptop, running the same engine path it uses locally - the transport underneath it changes, the features above it do not.

What “cannot read it” means

Client and bridge complete a Noise XX handshake with each other - X25519 keys, ChaCha20-Poly1305 encryption - through the relay, and every payload chunk is encrypted under keys the relay never sees. The control plane stores and transmits public keys and route grants only: never a private key, never a symmetric payload key. Relay logs redact bodies, and a session's source is bound to the authenticated connection that opened it.

The honest limit. Zero-knowledge covers the contents. A relay necessarily sees metadata - which bridge, when, how much traffic - because that is what routing is. If even that is too much for your threat model, connect directly; direct connections do not involve a relay at all and stay free.

Choosing per connection

Routing is a property of a connection profile: Direct or Via Relay, with a badge in the UI so you always know which path a session is taking. Direct is the default, and no profile becomes remote by accident. The route is stored without secrets, so an exported connection set carries the shape of your setup and none of its credentials.