// FAQ
Frequently asked questions
Answers about privacy, access gates, security, billing, and self-hosting. If your question is not here, reach out on the contact page.
01 · PRIVACY
- No. Every payload is encrypted with AES-256-GCM before it is written to storage. The database and any backups contain only ciphertext. The decryption key is never written to disk or a cache — it lives in process memory only, re-derived from the KMS master key on demand.
- Only a viewer who passes the access gate you configure — by default, a time-limited access link you send yourself. Scanning the QR without an active gate reveals nothing. We cannot read your payload; we hold only the ciphertext and the wrapped key material.
- Access events (timestamp, approximate region, gate type) are recorded for your audit log. IP addresses are stored as a keyed HMAC hash, not in plaintext, so the raw address is not recoverable from the log.
02 · ACCESS GATES
- An access gate is the mechanism that controls who can decrypt and view a QR payload. The default gate is a time-limited magic link — a single-use URL you send to the intended recipient. Optional gates include a PIN code or a one-time email passcode.
- The link is rejected and the viewer sees a generic access-denied page — no information about the payload is revealed. You can issue a new link from your dashboard at any time.
- Yes. Each access link is stored as a revocable record. Revoking it from your dashboard immediately invalidates any future use, even if the link URL is still in the recipient's browser history.
03 · SECURITY
- We use envelope encryption with three layers: a KMS master key wraps a per-tenant data encryption key (DEK), which encrypts each individual QR payload. In production, the master key is held by AWS KMS — we never hold it. For self-hosted deployments, you supply your own master key.
- No. Each tenant has a distinct DEK. Payloads are additionally bound by tenant ID and QR ID as GCM additional authenticated data (AAD), so a ciphertext cannot be transplanted to another record even within the same tenant and still decrypt.
- Not at this time. We describe the technical controls accurately — envelope encryption, no plaintext-at-rest, revocable stateful access links — and will not claim certifications we do not hold. If your compliance programme requires a specific certification, contact us so we can assess the roadmap together.
04 · SELF-HOSTING
- Yes. The application is designed to run as a container against a PostgreSQL database and a Redis-compatible store. You supply your own master key (or point it at your own KMS endpoint). The self-hosted path is documented in the repository.
- AWS KMS is supported out of the box. For fully air-gapped deployments, a local-key provider is available for development and testing — supply a 32-byte base64 master key via environment variable. Additional backends (GCP KMS, HashiCorp Vault) are on the roadmap.
05 · BILLING
- Pricing details will be published at launch. The plan is to offer a free tier for low-volume personal use and a team plan metered by active QR codes and access events. Contact us for enterprise or self-hosted licensing.
- No. The free tier is a permanent plan within its usage limits, not a time-limited offer, so you can evaluate the product without entering payment details. Pro and Business also offer an annual cycle at two months free.
06 · DATA EXPORT
- Yes. From your dashboard you can export a full archive of your QR records including metadata and ciphertext. Because the payloads are encrypted, the export also includes your wrapped DEK so you can decrypt the archive independently if you ever need to leave the platform.
- After cancellation, your data is retained for 30 days so you can export it. After 30 days, all records including key material are permanently deleted from our systems. The deletion is irreversible.