The goal is to limit what a breach on our side could expose. Here is what we cannot read, what we can and why, and what has not been tested yet.
Your Shely account password is never sent to us.
Your password derives two independent keys on your device. One proves your identity to the server, and we store only a hash of that proof. The other opens your encrypted vault. They are separate, and the server only ever receives the first.
Because the vault key is derived and used locally, it is never transmitted. The account service stores encrypted vault contents, but item names and public metadata remain readable. A connection uses credentials separately, as described below.
Not everything you store with us is held the same way, so the honest answer has two parts.
SSH keys, certificates and other keychain items are encrypted on your device before they reach us. We store the scrambled copy and do not hold the key that opens it. A copy of our database does not contain your account password or your vault key. Losing both your password and your recovery codes is unrecoverable for the same reason: we cannot restore your vault.
Saving or syncing a server password sends readable password JSON over HTTPS to the API for server encryption. We encrypt it at rest with a key available to our gateway, and the gateway decrypts it in memory to connect on your behalf. That is a deliberate choice: it lets Shely connect without unlocking your vault. It also means the password is not sealed away from us. Someone who obtained our database and that key, or who got into the running gateway, could read saved server passwords. For a sensitive server, use an SSH key from your keychain instead of a saved password.
Recording a session should not create a replayable copy on our side.
The gateway seals recording keys to configured administrators, who can decrypt the stored recording. The storage service does not hold an ordinary playback key. The gateway handles readable session data while recording. Redaction is heuristic and may miss secrets in commands or output; do not assume a recording contains no secrets.
A decrypted private key or other credential can reach the gateway when you use browser SSH. Encrypted vault storage does not keep a credential hidden from the service that uses it to authenticate. Native direct SSH and SFTP run from your device instead. Account synchronisation and AI requests still reach Shely. AI requests also reach the configured model providers with the context you submit. Storage encryption is not a guarantee against a compromised client, unlocked device or running service. See theprivacy policy for data sharing and retention.
Sharing a server with a team does not mean handing out its password.
A server shared with a team signs in with a password that we keep encrypted on our gateway, the same way as any saved password above. Members can connect without being told it, and only admins and above can reveal it. SSH keys are not shared with a team yet.
The vault protects your secrets; 2FA and passkeys protect the account that reaches them.
Use the supported two factor sign-in or passkey controls in account settings. Availability differs by platform and app version. The Apple app can also lock behind Face ID or Touch ID.
We would rather be plain about the state of things than imply a review that has not happened.
An independent external penetration test has not been completed. The design described above is what the software does, but it has not been through an outside security review, and we will say so until it has. We do not claim any compliance certification or a formal uptime commitment.
Report vulnerabilities to [email protected] or use the private GitHub reporting form. Our security.txt andrepository security policygive the existing research safe harbour and disclosure process. Do not send secrets or test other users' accounts.
