Security Settings

CrestBid is built privacy-first: it runs on your infrastructure and, with local models, no bid content ever leaves your network. The full architecture, threat model, and an honest list of current limitations are published in the Security Whitepaper.

Data residency

• Projects, knowledge bases, embeddings, drafts, and chat history are stored locally in PostgreSQL and Docker volumes you control.
• Local-model inference happens entirely on your hardware — the platform runs air-gapped in its default configuration.
• Cloud providers are an explicit, server-side operator opt-in — off by default, with no silent fallback.

Network exposure

• Only the application port (default 3000, localhost-bound) is published; the database, model servers, queue, and license service live on a private internal network.
• Security headers (CSP, X-Frame-Options, nosniff, strict Referrer-Policy) are emitted on every request; CORS is disabled by default.
• For multi-user LAN deployments, front the app with a TLS-terminating reverse proxy.

Secrets and encryption

Each install generates its own random secrets with file permissions restricted to the installing user. Encryption at rest is inherited from the host (BitLocker, LUKS, or equivalent) and recommended in the deployment checklist.

Recommended practices

• Use local models for confidential or regulated tenders.
• Enable full-disk encryption on the host running CrestBid.
• Restrict access to the machine or server running CrestBid.
• On Team and Enterprise, use role-based access and audit logs.