Short answers. Including the unflattering ones.

No. Creating and revealing a share both work signed out. An account only changes two things: a link can be set to expire up to seven days out instead of one, and a share can be restricted to named recipients, which requires the reader to sign in so there is an identity to check against.

An encrypted envelope, plus the rules attached to it — expiry, remaining views, and any recipient or network restrictions. The decryption key is in the URL fragment, and browsers do not send fragments to servers. An attacker with the database, the logs, the environment and the API traffic still cannot recover the content. The security model draws the boundary in full.

The share stops opening, permanently. Expiry and the view limit are both enforced server-side before anything is returned, and view accounting is atomic — two people clicking at the same moment cannot both get a view that only one of them was entitled to. A rejected attempt, such as a wrong passphrase or a blocked region, consumes nothing.

No, and this is deliberate. There is no recovery path, because a recovery path would mean the operator could reach the content — which is the exact property the product exists to deny. Send it again instead.

Anywhere from five minutes to seven days. Signed out, the ceiling is one day. Shorter is better: the expiry window is the window in which a leaked link is worth anything.

For anything genuinely sensitive, yes — and send it through a different channel than the link. The link alone is enough to open a share without one; with one, an attacker holding the full URL still has to guess, and Argon2id makes each guess expensive.

Use a passphrase that is not the secret itself and not something the recipient would have to ask you for over the same channel you sent the link on.

Between one and twelve views. If you need a specific group rather than a count, restrict the share to their mailboxes or to your domain — then a leaked link is not enough on its own, because opening it requires signing in as somebody on the list.

They add a layer, not an identity. Country, subdivision and CIDR allowlists are checked before a view is consumed, and a restricted request is denied outright when the source information is missing or cannot be trusted — it fails closed. Treat them as defence in depth, not as proof of who is on the other end.

Yes. After revealing a share that still has views left, the recipient can destroy it so nobody else can open the link. Deleting re-runs the same region, IP, sign-in and passphrase checks as a reveal, and does not spend a view.

No. The text is matched against the gitleaks reference rules inside a browser worker, and both the scan and its label stay on the page. They are not sent to the server and not stored with the share, so the operator never learns what kind of credential the envelope holds.

Treat the link as the secret, because for a share without a passphrase it is. Anything that can read the channel can open the link. Pages are served with a no-referrer policy and a strict content policy to limit accidental leaks, but that does not help if the link is sitting in a thread anyone can scroll back through. Keep expiry short, keep the view count minimal, and add a passphrase over a second channel when it matters.

An automated reader that follows a link only reaches the page, not the fragment — the key never leaves the browser that opened it. But an assistant with access to the message containing the full URL is in the same position as any other reader of that channel. The security page covers automated readers specifically.

Yes, and it is free. The backend is a single Rust binary over a SQLite/libSQL file, shipped as a hardened non-root Docker image with a Compose stack, an ordered migration step and a readiness check. The same security boundary is shared with the hosted service. See pricing for what self-hosting does and does not include.

Honestly: it is a Phase 0 preview. Encrypted text sharing, expiry, view limits, passphrases, network restrictions, the signed-in recipient gate and recipient deletion all work through both transports. File attachments, multiple recipients, creator-side deletion, accounts and secret requests are not finished — features marks which is which, and ask about the roadmap for what is planned next.