Database access

shortspan db main

Fetches the credential for the registered target main and launches your local client - psql, mysql, or mongosh depending on the driver. The password is passed to the client through the environment, not on the command line, so it does not appear in the process list.

shortspan db main --print

Prints the connection details and a DSN instead of launching anything, so a GUI client, an ORM, or a migration tool can use them. This is a reveal: it requires the same permission as reading a secret and is audited as such.

Most production databases do not accept connections from the internet, which is correct and slightly inconvenient. If you have registered an SSH server that *can* reach the database, Shortspan will use it.

Tunnelling

shortspan db main --via prod-web-1

Opens a loopback-only port forward through the SSH target for the length of the session, then points your local client at the near end. Both credentials - the SSH one and the database one - are brokered, held in memory, and audited separately.

A target can name a default bastion when it is registered, in which case --via is unnecessary and tunnelling is the default behaviour.

Running the client on the server

shortspan db main --via prod-web-1 --remote

Some SSH servers forbid port forwarding - shared hosting almost always does. --remote runs the database client *on the server* over the SSH session instead of tunnelling. You get an interactive session either way; the difference is where the client process lives.

An admin registers it in the console under Infrastructure, supplying an alias, the driver (PostgreSQL, MySQL, or MongoDB), host, port, database name, username, password, and optionally the SSH target to reach it through.