Security

Deckle is a public-beta product. This page is an honest snapshot of what is in place today and what is on the roadmap, so you can make an informed call about whether the posture meets your bar before you ship.

API key handling

Keys are bcrypt-hashed at rest with a per-key salt. The full key value is shown exactly once at creation and never stored in plaintext. Revocation is immediate and invalidates the key for both the dashboard and the API.

Rendering isolation

Each PDF render uses a fresh Playwright browser context with JavaScript disabled. Outbound webhooks pass through SSRF guards (DNS check, scheme/port allowlist, redirect restriction). The React renderer is disabled by default until our V8-isolate sandbox lands.

Transport and storage

All traffic to api.getdeckle.dev is TLS 1.2+. Generated PDFs are written to your chosen S3-compatible storage (R2, S3, GCS). Storage credentials live in env vars, not in the code repo.

Webhooks

Inbound webhooks (Stripe, Clerk) verify the provider signature before applying any state. Outbound webhooks include an HMAC signature header so you can verify authenticity on your side — see the docs for the verification snippet.

On the roadmap

SOC 2 Type II — engagement opens once we have 12 months of operational evidence.
@deckle/react rendering in isolated-vm rather than Node's built-in vm.
Real AES encryption for POST /v1/pdf/protect via a native qpdf module. (The endpoint is currently disabled rather than ship a misrepresentation.)
Cryptographic (PAdES) digital signatures for PDFs.
HIPAA-eligible enterprise plan and a signable BAA.

Reporting a vulnerability

Email security@getdeckle.dev with reproduction steps. We respond within two business days and treat good-faith research under safe-harbor terms. Please do not publicly disclose until we have shipped a fix or 90 days have passed, whichever is sooner.