Security at Stacktree.
The pages you publish carry real client work, so privacy is the default rather than a setting. This page sets out how that works, what runs underneath, and exactly what we do and do not claim, in the plain terms a vendor review needs.
Running a vendor review?
Email security@stacktr.ee for a DPA and our security overview. We complete security questionnaires quickly, in plain language, and we will work through procurement with you.
Stricter requirements? The whole platform runs in your own cloud: the stack is source available and self-hostable on your own Cloudflare account, where client data never leaves your perimeter and Stacktree itself has no access.
Is Stacktree safe for confidential client work?
Stacktree is private by default: every page gets an unguessable link that is itself the credential, is never listed, and is served with crawler-blocking headers. On top of that you can add a password, restrict viewers to a company email domain, encrypt the page end-to-end so even Stacktree cannot read it, or set it to expire or burn after one view. It runs on Cloudflare (Workers, R2, D1), and the whole stack is source-available so you can self-host it under your own perimeter.
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
- Password. Require a shared password 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 immediately from the dashboard. Expired and deleted pages are purged from both object storage and the database within the hour by a scheduled job.
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, and request full account deletion, where content is purged from object storage and the database within the hour. Anonymous uploads expire on their own.
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.
Frequent questions
Can Stacktree sign a DPA or complete our security questionnaire? +
Where does client data sit? +
Are Stacktree pages public? +
Can Stacktree read my hosted pages? +
Has Stacktree been SOC 2 audited? +
How do I report a security issue? +
Related guides
Sources and further reading
Answer the security question before it stalls the engagement.
A DPA on request, source you can inspect, and self-hosting when the requirements are stricter.