If your question isn't answered here, contact us.
Every secret and document is encrypted in your browser, using your organization's key pair, before it's ever sent to our servers - so it travels and sits in our database (or storage, for documents) as ciphertext, never plaintext. The private key needed to decrypt it is also encrypted at rest, but using a key derived from your organization's recovery key - a key only you hold, that never leaves your browser and that our servers never receive or store. That means GoSecretly's infrastructure cannot decrypt a stored secret or document, even if we wanted to or were compelled to: this is a genuine zero-knowledge design for everything you send and receive. The one narrow exception is your two-factor authentication secret, which our servers must be able to read to validate your login codes - that's encrypted separately, under a key we do hold. See our Privacy & Data Security page for the full picture.
Yes - that's the core problem GoSecretly solves. A password or API key pasted into an email or chat message sits there indefinitely, gets forwarded, and often never gets deleted. A GoSecretly link is single-use and time-boxed instead: the recipient submits the secret through an encrypted form, you view it once, and it's destroyed from our database the moment you click "Got it" - no lingering copy sitting in an inbox or chat history to leak later.
Before. Registration generates your organization's encryption key pair right there in your browser, and shows you a one-time recovery key that locks the private half - none of that touches our servers until after it already exists locally. You also set a login password (which only gets you into your account, and never touches those encryption keys) and enroll in mandatory two-factor authentication, both required before the account is actually created. See our How It Works page for the full registration walkthrough.
Yes, for every user, with no way to opt out. It's checked again (a fresh code, on top of your session) before creating a new share link and before viewing a submitted secret, since those are the two most sensitive actions in the app.
You choose an expiry when you create a link (from 5 minutes up to 30 days). Once the recipient submits a secret and you view it, clicking "Got it" permanently destroys it from our database - it cannot be viewed again by anyone, including us.
Yes - any logged-in team member can type a key and value directly and save it into an Internal Vault, no request or recipient needed. It's for secrets you already have (an API key, a shared password) rather than ones you're asking someone else to submit.
Yes. A short value like an API key, password, or connection string goes through a self-destructing link or straight into a Secrets vault; a larger file like an exported .env goes into a Documents vault the same way you'd share any other file. Either way it's encrypted in the browser before it's sent, so it's never stored or transmitted in plaintext.
For secrets enrolled in Managed Secrets, yes on a schedule you set - every 24 hours out to yearly, or a custom date. You'll get reminders as the rotation date approaches, then confirm with a fresh authenticator code and GoSecretly generates a new value on the spot, or you supply one you already rotated yourself. Today this covers GoSecretly-generated values and username/password pairs; it doesn't yet call out to a third-party provider (AWS, Stripe, etc.) to rotate a live credential there on your behalf.
Yes. Secrets, Documents, and Internal each support multiple named vaults per organization - create as many as you want (by team, project, or however makes sense), rename them, and move on. Every organization starts with one default vault of each kind, so nothing requires extra setup to use right away; deleting a vault is only possible once it's empty.
Yes, exactly the same guarantee as a secret submitted through a share link: it's sealed in your browser against your organization's public key before it's ever sent to our servers, and a fresh authenticator code is required to save, view, edit, or delete it.
Yes - Documents and Internal vaults (not Secrets vaults) can be shared whole with an external recipient who has no GoSecretly account. You set their email at creation - that's the only address that can ever complete the one-time code check - pick an expiry from 1 hour to 30 days, and optionally add a passphrase on top, sent by you rather than emailed. It's built for handing over an ongoing set of files or credentials, like a solicitor sharing case documents with a client, rather than a single one-off item.
Yes - external vault sharing is built for exactly that: an ongoing relationship where you're periodically sending a client documents or credentials, not a single one-off item. Share a Documents or Internal vault with a client's email, they access it after a one-time code check (no account needed on their side), and you can add to it, remove single items, or revoke the whole share at any time. Every access is logged, which is the audit trail a compliance review usually asks for.
Yes, on Solo plans and above - GoSecretly's own logo, marketing navigation, and footer are dropped from every public share page, notification email, and link preview, and the same applies to invite emails sent to new team members. A small "Secured by GoSecretly" credit stays regardless; the legal entity line in every email's footer always stays too, since that's a company-registration disclosure, not branding.
Yes, on Team plans and above, from Settings → Branding - upload a PNG, JPEG, ICO, WEBP, or GIF up to 1MB, and set a tagline up to 500 characters. Both show up everywhere GoSecretly's own branding would otherwise appear: the share page itself, the notification email's header, the link preview when it's pasted into Slack or iMessage, and in your own team's dashboard header too.
Yes. Each share gets its own encryption key pair, generated in your browser at creation - the decrypting half lives only inside the share link itself, never sent to or stored by our servers, and the recipient's browser does the actual decrypting after they pass the code check. We never see plaintext content on either side of a share.
Not automatically - it's a deliberate action. Add new documents or secrets to the vault as usual, then open the share and click Sync to wrap the new content for that recipient. You can also remove a single item from an active share without revoking the whole link, and revoke the whole share outright at any time.
Yes - the share's card shows when it was last viewed and how many times, and you get a one-time email the first time it's opened, so you're not left wondering whether it landed.
Yes. An organization admin can invite additional users by email. Two-factor authentication is enforced for every invited user the first time they log in - there's no way to skip it.
No, not with individual keys. Anyone can set up their own personal key from Security settings, which an admin then grants access to - once granted, that person unlocks the vault with their own key, never needing the organization's shared recovery key at all. Admins keep standing access via the shared key regardless, since they already have full access from signup.
Yes - that's the actual point of individual keys. An admin can revoke a single person's granted access at any time, instantly and on its own, with zero effect on anyone else's access and no need to rotate the organization's shared recovery key. Revoking access is different from removing someone from the organization: it only removes their ability to unlock the vault, not their account.
An admin can remove them from the organization entirely, not just revoke their vault access. This blocks their login immediately, revokes any active individual key grant automatically, and anonymizes their personal details - the same handling used for a GDPR closure request. Their account row isn't deleted, so the organization's audit log stays intact and accurate.
Rotate it from Security settings (organization admins only). This generates a brand-new recovery key and immediately invalidates the old one - your organization's public key, and everything already sealed against it, is untouched, so nothing needs to be re-encrypted. Every admin gets an email confirming the rotation happened. This is separate from, and more disruptive than, revoking one person's individual access - reach for individual-key revocation first if only one person's access is actually in question.
A share link is single-use and time-boxed - once submitted and viewed, it's destroyed. All traffic runs over TLS. That said, anyone who obtains a valid, not-yet-used link can submit a secret through it, so treat the link itself the way you'd treat a one-time password: send it through a channel you trust, and only to the intended recipient.
Anything in the vault becomes permanently unrecoverable - we have no way to decrypt it for you, precisely because we never hold the key that can. This is the direct tradeoff of a genuine zero-knowledge design: store your organization's recovery key somewhere safe (a password manager or secure offline location) the moment it's shown to you at setup.
No. We don't collect or store any payment or card information anywhere in the product.
Account basics (name, email, organization), and metadata about requests (timestamps, status, who created or viewed them) for audit purposes. Secret content is always stored encrypted, never in plaintext. See our Privacy & Data Security page for the full picture.
Yes - either or both, independently of each other and of email. Paste an incoming webhook URL from your own Slack workspace or Teams channel into Settings → Notifications, and you'll get pinged when a secret or document is submitted, when someone opens a vault you shared, and as saved items approach expiry. Only ever a "go check your dashboard" nudge - never the secret or document content itself.