Introduction

Most teams end up with the same arrangement, not because anyone chose it but because each step was reasonable at the time. Production SSH keys sit in ~/.ssh on six laptops. The database password is in a password manager, and also in a Slack thread from March, and also in someone's shell history. A long-lived AWS access key is in ~/.aws/credentials on the machine of a contractor whose engagement ended two months ago.

None of that is recoverable after the fact. When a laptop is lost you cannot enumerate what was on it. When someone leaves you cannot prove what they still hold. When an auditor asks who read the production database password last quarter, there is no answer - not a bad answer, no answer at all.

Shortspan is a credential broker. Secrets, SSH servers, databases, AWS accounts, and Kubernetes clusters are registered once, encrypted, and scoped to a project. After that, nobody holds the credential - they hold the right to ask for it.

When a developer runs shortspan ssh prod-web-1, the CLI asks the API for that server's credential, receives it over TLS, holds it in memory for the length of the connection, and never writes it to disk. The request is recorded: who asked, for what, from where, and when.

The command line is the product. The web console exists to configure it, approve requests against it, and read the record it leaves behind - not to be where the work happens.

Being clear about the boundaries is more useful than a longer feature list.

Not a password manager

There is no browser extension and no autofill. Shortspan is for the credentials your machines use, not the ones you type into websites.

Not zero-knowledge

The server decrypts secrets in order to broker them. That is what makes shortspan run and SSH brokering possible at all. See the security model for exactly what the server can see, and when.

Not a bastion or a VPN

Shortspan brokers the credential; the network path is still yours. It can tunnel a database connection through an SSH server you have registered, but it is not itself a network appliance.

Not a dynamic secrets engine - yet

Credentials are stored and handed out, not minted per session against your cloud provider. Grants are short-lived; the underlying credential is long-lived until you rotate it.

• A solo developer or contractor working across several clients, who wants one place for each engagement's credentials and a clean way to hand them back at the end.

• A small team that has outgrown a shared password-manager vault and wants to know who used what, without standing up Vault.

• A team with a compliance obligation that needs an access log, approval workflows for production, and a defensible answer to "who could reach this".

It is deliberately usable by one person on the free tier. A credential broker that only makes sense at fifty seats has already failed the people who need it most.