Security statement

Send a report to the security contact address in the imprint. Include the affected endpoint, the steps to reproduce and the impact you observed. The operator confirms receipt, keeps you informed while the issue is being fixed and credits you if you want to be named.

Please do not run automated scanners against production, do not attempt to reach other customers' data and do not publish a finding before a fix is available. Testing against your own project is welcome; testing against someone else's is not.

• Passwords are hashed with bcrypt at cost twelve and are never stored or logged in clear text.
• Sign in is rate limited per username, per address and in combination, so credential stuffing is throttled rather than merely logged.
• Session tokens are random 32 byte values, stored in the browser as an HttpOnly, Secure, SameSite Lax cookie and in the database only as a SHA-256 hash.
• API keys and automation tokens are scoped to a project and a set of permissions, can carry an IP allow list, and are shown exactly once when they are issued.
• Short lived signed tickets authorise uploads, downloads and realtime connections. A ticket is single use, expires within a minute and carries its authorisation in the signature rather than in a session lookup.

• Every managed database gets its own PostgreSQL login role named usr_<database> with its own connection limit. A leaked credential reaches one database.
• Row level security is available for the customer's own tables and is enforced by PostgreSQL, so it also applies to a direct psql session and to the HTTPS Data API.
• The platform's own tables carry row level security policies for the application role, so a bug in one query cannot read across the control plane.
• Project membership decides which resources a dashboard account sees, and a scoped API key never resolves to a project it was not issued for.

• Applications and background functions run as rootless Podman containers under a dedicated unprivileged user.
• Each container starts with a read only root filesystem, every Linux capability dropped, no new privileges, a process limit and a hard memory limit enforced by the kernel rather than by a monitor.
• A deployment starts the new container next to the old one and only discards the old one after an HTTP health probe succeeds. A failed probe restores the previous version automatically.
• The backend service itself runs from a directory that is read only to it; only the data directory is writable, and no deployment step writes into customer data.

• The backend binds to the loopback interface and is reachable only through nginx with TLS.
• Certificates are obtained and renewed automatically; a deployment that cannot obtain a certificate aborts rather than serving plaintext.
• The realtime host proxies exactly one path and answers everything else with 404, so the hostname cannot be used to reach the rest of the API.
• PostgreSQL is reachable from the internet so that customers can connect their own tools directly. That is a deliberate trade off; it is protected by per role credentials and connection limits, and the next hardening step is a fail2ban jail on authentication failures.

• The backend refuses to start when a secret is missing, when PostgreSQL does not point at loopback, when the superuser role would be used, when the Redis password is too short or when the connection pools exceed the connection budget. Misconfiguration stops the service instead of degrading it silently.
• Database credentials are encrypted at rest with a key identifier, so a key can be rotated without losing access to older records.
• Deployment credentials live in the pipeline, not on a workstation. A single repository variable disables every push triggered deployment.

• Every control plane mutation is written to an audit log with the acting account, the action, the resource, the address and the payload.
• Credential reveals and rotations are audited like any other administrative action.
• Each merge to the main branch runs a verification job against the live platform, so a broken route or a missing endpoint surfaces immediately instead of at the next customer request.

Container isolation is not a dedicated virtual machine, and the operator will not describe it as one. A kernel level escape would affect the workloads on the same host.

A single virtual private server is a single point of failure. There is no multi region failover and no availability guarantee unless one has been agreed in writing.

The platform holds no third party security certification. Everything on this page is a mechanism you can verify, not an audited attestation.

Backups exist because the platform offers them; taking them, downloading them and testing a restore remains the customer's responsibility.