How Vela Docs handles your files

Security

Last updated May 16, 2026

Quick version. Your file lives only in your browser until you click Share. HTML files render in a sandboxed iframe with no access to your other tabs. Data on our servers is encrypted at rest and in transit. Report security issues to security@vela.partners.

Local-first storage

Files you drop on Vela Docs anonymously stay in your browser's IndexedDB. They never reach our servers, our logs, or our backups. Closing the tab keeps them local; clearing browser data removes them completely. The anonymous flow is genuinely anonymous: we have no record an upload happened.

The moment you click Share, the file is uploaded to Firestore so collaborators can fetch it. From that point forward the file is at rest on our servers, encrypted, and governed by the access controls below.

Sandboxed HTML rendering

Every HTML file you open renders inside an iframe with the sandbox attribute set and without the allow-same-origin flag. The result:

  • Scripts in the file can run, so interactive demos and AI-generated mini-apps work as intended.
  • Scripts cannot read your other tabs, cookies, localStorage, IndexedDB, or the parent page's auth state.
  • Scripts cannot navigate the parent window, open same-origin popups, or read the URL bar.
  • The page can make outbound network requests, so if a file calls a third-party tracker or CDN, that request still happens. Treat unfamiliar files the same way you'd treat any untrusted webpage.

For AI-generated HTML specifically, the risk profile is low. The bigger practical concern is the page silently calling external resources whose availability changes over time. Inspect the source in Code mode if that matters for your use case.

Encryption

  • In transit: all traffic between your browser and our servers uses TLS 1.2 or higher. HTTP requests redirect to HTTPS via a 308. The real-time collaboration socket runs on Secure WebSockets (wss://) with the same TLS posture.
  • At rest: file contents in Firestore are encrypted using Google Cloud's default customer-data encryption (AES-256 key envelope, keys managed by Google Cloud KMS).
  • Backups: Firestore's managed point-in-time recovery retains data for 7 days. Manual backups roll off within 30 days.

Authentication

  • Sign-in uses Firebase Auth, with Google OAuth or a one-time email magic link. We don't run our own password database, so we can't leak one.
  • Magic-link tokens expire after one use or 1 hour, whichever comes first.
  • Session cookies are HTTP-only, Secure, and SameSite=Strict.
  • The real-time collaboration server validates a fresh Firebase ID token on every WebSocket connection. Permission changes (e.g. revoking a collaborator) take effect on the next session refresh.

Access control

Read and write permissions are enforced server-side by Firestore Security Rules, not just by the client UI. The three tiers:

  • Owner (the person who shared the file): full read, write, and share management.
  • Per-user invitees: view or edit role, set by the owner. Sign-in required.
  • Anyone-with-link viewers, if the owner enabled it: read-only render. No account required, but also no way to leave comments.

The owner can revoke any tier from the share dialog; revocation takes effect on the next request.

Infrastructure

  • Hosted on Google Cloud (Cloud Run, Firestore, Firebase Auth). SOC 2 Type II and ISO 27001 certified at the platform level.
  • Service accounts use the principle of least privilege: each Cloud Run service runs with only the IAM roles it needs.
  • Secrets live in Google Secret Manager. They are mounted into Cloud Run services at runtime; they never enter container images or git history.
  • Service-account keys are rotated when a key is exposed, and proactively on a 90-day cadence.

Reporting a vulnerability

If you've found a security issue, please email security@vela.partners with:

  • A description of the issue and impact.
  • Steps to reproduce, ideally with a proof-of-concept URL or file.
  • Whether the issue has been disclosed publicly.

We'll acknowledge within 2 business days and aim to ship a fix within 14 days for critical issues. Please give us a chance to ship the fix before public disclosure. We don't run a paid bounty program today; we will credit reporters in release notes where appropriate.

What we don't claim

We're a small team. We do not claim SOC 2 Type II certification at the application level, HIPAA / PCI-DSS compliance, or formal pen-test reports. If your compliance regime requires those, get in touch and we'll be honest about whether and when we can meet that bar.

Security posture as of May 16, 2026. Material changes are announced at the top of this page; the previous version remains accessible for 12 months. See also our privacy statement for what data we store and what we don't.