§ Security

Your secrets never become our problem.

DeployDoc reads deployment errors and configuration files. By definition, those files contain sensitive material. Every paste is treated as untrusted until proven safe — and most of the work happens before anything leaves your browser.

Nine commitments
  1. 01

    Redaction happens in your browser

    Secrets matching known API key patterns are detected and masked locally before a single byte leaves your machine.

    Pattern set covers AWS, GCP, Stripe, Supabase, OpenAI, GitHub, Slack and 40+ others. Updated weekly.

  2. 02

    We never store the files you paste

    Request bodies are processed in memory and discarded. Only the redacted metadata required to render your report is persisted.

    No raw error logs. No raw env files. No raw config. Ever.

  3. 03

    Our logs refuse unmasked credentials

    The edge layer scans outbound log lines and drops anything that still contains an unmasked secret — a backstop in case redaction was bypassed.

    Enforced at the worker boundary, not the application layer.

  4. 04

    You see what was detected, before submit

    Every paste shows a preview of which values are about to be redacted. You decide whether to send, edit, or cancel.

    Nothing is silent. Nothing is automatic without your confirmation.

  5. 05

    Recommendations label exposure rules

    When DeployDoc suggests an env var, the guidance explicitly states whether it is safe in client code or must remain server-side.

    VITE_, NEXT_PUBLIC_ and equivalent client-exposed prefixes are flagged distinctly from server-only secrets.

  6. 06

    Health checks can't reach your internal network

    When DeployDoc probes a URL on your behalf, the server-side fetcher blocks localhost, private IP ranges, link-local addresses, cloud metadata endpoints, and non-http(s) schemes. Every redirect hop is re-validated against the same denylist.

    DNS is resolved server-side; redirected hosts that resolve to a private IP are refused before any byte is read.

  7. 07

    Uploaded files live in a private bucket

    Configs and logs you upload go to a private Supabase Storage bucket. We never generate a public URL. Reads use short-lived signed URLs (60 seconds), gated by Storage RLS plus a metadata-row RLS check.

    Raw files are deleted automatically after we extract and re-redact the text, unless you explicitly opt to keep the original.

  8. 08

    Encrypted token storage for integrations

    Provider tokens — Vercel, Netlify, Cloudflare, Supabase — are encrypted at rest with per-workspace keys and scoped to the minimum permissions we need.

    You can revoke any integration from the workspace settings at any time.

  9. 09

    A strict Content Security Policy is enforced in production

    Every response carries a CSP with a strict connect-src allowlist, frame-ancestors 'none', object-src 'none', base-uri 'self', form-action 'self', and SHA-256 hashes for our own static inline scripts. Violations are reported to our own endpoint and logged for review.

    Nonce-based script allowlisting is tracked as post-launch hardening pending stable framework support; CSP_REPORT_ONLY=1 remains as a documented rollback flag.

What we keep

The minimum to render your report.

  • Redacted error signatures and stack frames
  • Detected provider, framework and runtime
  • Hash of the paste, for deduplication only
  • Your workspace, plan and audit timeline
What we never see

Everything you would not paste in a screenshot.

  • Raw API keys, tokens or connection strings
  • Original contents of pasted env or config files
  • Source code beyond the lines around the error
  • Anything you redacted, edited or cancelled before submit
Disclosure

If you believe you have found a security issue, email support@deploydoc.com. We acknowledge within one business day and credit researchers in our public changelog.