How PixelDepot is built to hold your images.

What is running today

A marketing site and one form. No API is serving traffic, no images are being processed, and no API keys exist.

• The beta list lives in Supabase Postgres in AWS us-east-1, with Row Level Security enabled and no policies, so the publishable key that ships to every browser can neither read nor write it. A server action holding the secret key does the insert.
• Rate limiting counts submissions in the database rather than in the web process, because serverless instances do not share memory. It stores a one-way HMAC of the caller address, never the address.
• PixelDepot sets no cookies of its own and carries no advertising or third-party tracking scripts.
• The framework header is disabled, unhandled errors return a stable code with no stack trace or filesystem path, and logs are structured JSON carrying a request ID and no payload.

Runtime images: the commitment for launch

This is what the API is being built to, and it is stricter than the retention window this site used to describe:

• Images are never stored. They are held in memory for the request and deleted as soon as the response is returned.
• The hard maximum is 60 seconds from receipt, including for failed, cancelled and timed-out requests. The request timeout enforces it, so the guarantee does not rest on a cleanup job that can fail quietly.
• Images are never written to disk, including temporary and scratch storage, and never enter object storage.
• Pixels, transient facial representations, landmarks and API responses never enter logs, analytics, crash dumps or backups.
• There is no opt-in storage option in v1. If storage is ever offered, it is a separate service with its own review.
• No customer image is used for training without a separate, explicit written agreement.

Biometric restraint by design

Face Analyze creates no enrollment record and stores no face embedding. Transient facial-geometry representations are computed in memory during a request, are never written to disk, and never persist between requests. We say that rather than the vaguer "no embeddings stored".

Apparent-attribute features are gated off for EU processing at the organization and API-key level, so entitlement follows who is calling rather than where the packet came from. Face recognition and 1:N matching are not offered, and sit behind a separate biometric-privacy and licensing review.

Keys and tenant isolation: the commitment for launch

None of this is built yet, because there are no accounts and no keys:

• API keys stored as HMAC-SHA256 with a server-side pepper, the full secret shown exactly once, and revocation supported.
• Separate live and test keys.
• Row Level Security on every table in an exposed schema, tested per role and for cross-tenant denial.
• Rate limiting by API key, organization and IP risk signal.
• Audit logs for administrative changes and API-key operations.

Handling the images we are sent

Also a commitment for launch, and a list of how image endpoints get attacked:

• Input size, dimension, format and timeout limits.
• SSRF and DNS-rebinding protection on remote-image fetching: private, loopback, link-local and metadata-service addresses blocked, redirects validated, download size and time capped.
• File-signature validation rather than trusting a MIME type or a file extension.
• EXIF stripped on ingest unless explicitly requested and justified.

Reproducibility

Every response names the model versions and SHA-256 weight digests behind it, so you can pin a version and diff a regression. Nothing ships until a human has signed off on all four licenses: code, weights, training data and dependencies.

Your responsibilities

Notice and consent from the people in your images, before capture, in the form your jurisdiction requires. Keeping your API keys secret and rotating them when someone leaves. Controlling who in your organization can call the service, and securing the systems you store our responses in.

Vendors

Vercel serves the site. Supabase holds the beta list and, later, account data. Resend sends the confirmation email. Paddle will process payments as merchant of record, with card details entered in Paddle-hosted flows. We do not receive or store card numbers.

Reporting a vulnerability

Write to security@pixeldepot.ai with enough detail to reproduce it. We will confirm receipt, tell you what we find, and credit you if you want the credit. Please give us a reasonable chance to fix it before publishing, and please do not run tests that degrade the service or touch anyone else's data.

What we do not claim

No SOC 2 report, no ISO certification, no third-party penetration test, and no counsel-reviewed data processing agreement. Those arrive with the product, and this page will say so on the day they do and not before.