Security and responsible self-hosting
Seryvon security starts with the environment running your audits. The open core fetches public websites, can call external measurement providers, and can persist reports and artifacts. This guide explains the controls present in the source and the decisions a self-hosting operator must make before granting access.
Control access to the audit API
The API checks the X-API-Key header when SERYVON_API_KEY is configured. Its default value is empty; in that state the middleware does not enforce authentication. Set a strong key before allowing other users to reach the service. The health endpoint is exempt from the key check.
The repository's Docker Compose configuration binds the API, web interface, database and Redis ports to loopback. Keep those bindings for local evaluation. For shared deployment, review the reverse proxy, TLS termination, network restrictions and access to the database separately. A local development configuration does not establish tenant isolation or a production access policy.
Understand where provider keys go
Bring your own key means that your configured provider account supplies access and incurs any applicable usage charges. Environment-based credentials belong in deployment secrets, outside Git history and exported reports. The stored-key API uses Fernet encryption with SERYVON_SECRET_KEY; key-management endpoints are unavailable when that encryption key is not configured.
Keep the encryption key separate from database backups and document how you will recover it. Encryption of stored provider keys does not imply that every log, artifact or database column is encrypted. Restrict access to the running application because it needs to decrypt credentials to call providers.
Crawl public targets responsibly
The crawler safety module permits HTTP and HTTPS, rejects credentials embedded in URLs, checks resolved addresses against non-public IP ranges and revalidates redirect destinations. Its source explicitly documents a remaining DNS-rebinding window between validation and connection. Network-level outbound restrictions remain an important part of a self-hosted deployment.
Use bounded page counts, timeouts and appropriate crawl scope. Respect the target owner's permissions and review robots handling. Treat collected HTML as untrusted input. If you enable browser rendering, isolate that browser workload and account for the additional remote resources it may request.
Choose a retention policy
The artifact-store factory uses an S3-compatible store when its endpoint and bucket are configured; otherwise it selects an in-memory store. That fallback does not persist raw artifacts. Audit history in the database and raw artifact retention are separate concerns. Decide who can retrieve each, how long you keep it, and how backups are removed.
External connectors send requests to their respective providers. Review the selected provider's data handling before including confidential prompts or client information. Self-hosting the engine does not make external API calls local.
Report a concern
Contact hello@seryvon.com with the affected version, component and a minimal description. Start without credentials, personal data or exploit details that expose another system. Ask for a suitable private exchange before sharing sensitive evidence. No response-time commitment or bounty is stated here.
Implementation references: API access checks, stored-key encryption, crawler safety and residual limits, and artifact storage selection.
Continue with the self-hosting quickstart, measurement limitations and website privacy policy.