Security at Stacktree.

The default: the link is the credential

A new page is unlisted: it lives at an unguessable token URL (roughly 128 bits of entropy), it is never enumerated or listed anywhere, and it is served with crawler-blocking headers (X-Robots-Tag, no AI training) and no sitemap entry, so search engines and AI crawlers leave it alone. There is no public directory of pages. If you do not share the link, no one finds the work.

Gates you can add

The unguessable link is on every plan, free included, and so is the passcode. The email-domain gate starts on Solo at $19 a month.

• Passcode. Require a shared passcode before the page renders. Stored as a hash, never in plaintext.
• Email-domain gate. Require viewers to verify an address on a domain you choose (your client's company domain, for example) by magic link before the page loads. The gate sits on top of the unguessable link.

End-to-end encryption for the most sensitive work

For the most sensitive deliverables, encrypt the page in your browser before it is uploaded (AES-GCM). The decryption key lives only in the URL fragment (the part after the #), which browsers never send to the server. Stacktree stores ciphertext and cannot read the content; only someone with the full link, fragment included, can decrypt it.

Content security

Hosted pages are served under a strict Content-Security-Policy by default (default-src 'self'). Your own page's inline scripts still run: Stacktree computes a per-page hash allowlist at upload time, which permits exactly your scripts while still blocking injected ones, rather than weakening the policy for everyone. Markdown is sanitised on render. The result is that one hosted page cannot be turned into a vector against other pages on the domain.

Access ends when the engagement ends

Every page can carry an expiry (from minutes to never), be set to burn after a single read, or be deleted from the dashboard. Whichever you use, access ends at that moment: the page stops serving, everyone holding the link gets a dead link, and no part of it is served to anyone again. A share link, a passcode, a preview and the owner's own session all sit under that, so none of them reopens a page that has been taken down.

Then a 30-day undo, then destruction. Once a page has stopped serving we keep its content for 30 days, so you can put it back at the same URL from the dashboard, with the same link, the same gates and the same read history. Nobody can reach it through the URL in the meantime. At the end of the 30 days a scheduled job destroys the file in object storage and the row in the database, along with that page's view log, feedback and reactions, and after that nobody can bring it back, us included. On the free plan, where pages carry a 7-day limit, restoring one that ran out of time gives it 48 more hours rather than a fresh window: a restore is a rescue, not a renewal.

Two cases skip the window and are final. A page set to burn after a single read is destroyed in the same request that serves its one allowed view, which is the promise the feature makes. A page we take down for abuse stops serving at once, is destroyed by the next hourly cleanup run, and is never restorable. If you need any other page destroyed now rather than in 30 days, email privacy@stacktr.ee with the URL and we will purge it. The same timings, in policy language, are in the privacy policy.

Infrastructure, residency and self-hosting

Stacktree runs on Cloudflare Workers, R2, and D1. Cloudflare maintains SOC 2 / ISO 27001 compliance for that underlying infrastructure, which your compliance reviewer can verify directly. If your engagement requires data residency, your own perimeter, or zero third-party dependencies, Stacktree is source-available and self-hostable: run the entire stack on your own Cloudflare account, where Stacktree itself has no access to anything.

Data processing, DPAs and vendor reviews

Stacktree processes the minimum needed to run the service: the content you publish, an account email and session (via Clerk), and a payment identifier (via Stripe, who never expose card details to us). Operational logs carry IPs HMAC-hashed at the edge. The full list of sub-processors, what each handles, where it sits, and the EU Standard Contractual Clauses in place, is on the sub-processors page; data handling and your rights are in the privacy policy.

Your data rights. Export or delete any page from the dashboard at any time: it stops serving at once and follows the retention above, restorable for 30 days and then destroyed. Full account deletion is a request to privacy@stacktr.ee, and we delete your sites, API keys and audit logs within 30 days of it. If a client needs something destroyed sooner than the restore window allows, say so in the same email with the URL and we will purge it immediately instead. Anonymous uploads stop serving 24 hours after they are published, with no action from anyone.

DPAs and questionnaires. If your client's procurement needs a Data Processing Agreement signed or a vendor security questionnaire completed before you can use Stacktree on the engagement, email security@stacktr.ee and we will work through it with you. If policy requires a third-party SOC 2 attestation we do not yet hold, self-hosting keeps all data inside your own audited environment, with no vendor agreement to negotiate because there is no external processor.

What we do not claim

We would rather be precise than impressive. Stacktree itself has not completed a third-party SOC 2 audit or a published external penetration test; the SOC 2 / ISO 27001 coverage above is Cloudflare's, for the infrastructure Stacktree runs on. We do run internal security reviews and ship the fixes (the changelog records security-tagged releases), and the codebase is source-available so your own reviewer can read it. If third-party attestation is a hard requirement, self-hosting puts the data inside your own audited environment.

Reporting a vulnerability

If you find a security issue, email security@stacktr.ee. We read every report, we will acknowledge it, and we will not pursue researchers acting in good faith. Machine-readable contact details are at /.well-known/security.txt.