Security

Overview

Cadrix is built to keep each organisation’s workspace separate and to give administrators control over who can do what. This page describes controls we have implemented and how we operate the hosted service. It is not a guarantee, it reflects our current practice, and it lists the limits as well (see What we do not claim). For questions or a security questionnaire, write to hello@cadrixflow.com.

Infrastructure and hosting

• The service runs on a server operated by Hetzner Online GmbH in Falkenstein, Germany. Data is stored in a PostgreSQL database on that server.
• The application and database run as separate containers. The database has no published network port, and the application listens only on the server’s loopback interface, behind a reverse proxy.
• The reverse proxy terminates TLS (HTTPS), redirects HTTP to HTTPS and sets security headers including HSTS. The server firewall allows only SSH, HTTP and HTTPS, and a brute-force protection service runs on the host.
• The application container runs as a non-root user with a read-only filesystem, all Linux capabilities dropped, privilege escalation disabled, and memory, CPU and process limits.
• Account emails (verification, password reset, invitations) are sent through Microsoft 365 / Exchange Online.

Access control and tenant isolation

• Tenant isolation. In the hosted service, the management endpoints for users, roles, organisations and workspaces check that every identifier in a request belongs to the caller’s active organisation, taken from the signed session and never from the request. A user of one organisation cannot read or change another’s.
• Role-based access. Actions are checked against permissions held through roles; organisation administrators manage members and workspaces, and custom roles are available on higher plans.
• Sign-in. Passwords are stored as salted bcrypt hashes. Sessions use signed, short-lived tokens in HttpOnly cookies, and email addresses must be verified before an account is activated.
• API keys. API secrets are stored only as salted hashes and compared in constant time.
• Plan limits. Members, workflows, runs and storage are enforced server-side per plan.

Data protection

• In transit: connections to the app use TLS at the reverse proxy.
• Stored credentials: the credentials you save for third-party services (for example model provider keys) are encrypted before they are written to the database, with a key that is kept outside the database.
• Outbound requests: a request guard blocks workflow HTTP and tool calls to private network address ranges, to reduce server-side request forgery.
• Logs and secrets: secrets are not committed to the code or the container image; they are supplied to the server by environment configuration.
• Your model providers: content in a workflow step goes to the provider you configured, under your own account with it. Cadrix does not train models on customer content.

Application security

• Rate limits. Sign-up, verification-resend and sign-in endpoints are limited per IP address at the proxy, and sign-up and resend are also limited per IP and per email address in the application.
• Abuse controls. Disposable email domains are rejected at sign-up, and an optional captcha check can be switched on.
• Code execution nodes. Workflow nodes that run customer-written JavaScript run inside the application process. That is not a hard isolation boundary and we do not describe it as a sandbox; we treat these nodes as a risk to be managed and may restrict them.
• Dependencies. The container base image is pinned and rebuilt on a regular schedule to pick up operating-system security patches.

Backups and recovery

• A nightly job takes a compressed backup of the PostgreSQL database and of the volume holding the encryption keys, validates the files, and deletes backups older than 14 days.
• Restores have been tested by loading a backup into a scratch database. Because backups are nightly, up to a day of changes could be lost in a worst case.
• Backups are currently stored on the same server as the service. Uploaded files are not part of the nightly job.
• Releases keep the previous application version so that a deploy can be rolled back.

Billing security

• Payments for paid plans are handled by Polar as merchant of record. Card details are entered with Polar and never reach Cadrix systems.
• Billing events from Polar arrive as webhooks. Each one is verified against a cryptographic signature and a timestamp before it is accepted, and each event is processed once, so a repeated or forged delivery does not change a plan twice or at all.

Responsible disclosure

If you believe you have found a security issue, email hello@cadrixflow.com with the subject “Security report” and enough detail to reproduce it: what you found, where, and the steps.

• Please give us a reasonable time to fix the issue before telling anyone else.
• Do not access, change or delete other customers’ data, do not degrade the service, and do not use social engineering or physical attacks. Use only your own account and data for testing.
• We will acknowledge good-faith reports, keep you informed as we investigate, and credit you if you wish. We do not run a paid bounty programme.

If you follow these rules and act in good faith, we will treat your research as authorised and will not take legal action against you for it, to the extent we are able to under the law.

What we do not claim

Cadrix does not hold third-party security certifications or attestations, such as SOC 2 or ISO 27001, and we have not published an independent penetration test. We do not state an uptime commitment or a breach-notification period on this page. The hosted service runs as a single application instance, so a release or restart causes a short interruption, and operational items such as off-server backup copies and external monitoring are still being completed. If something here changes, this page will say so. See also the Privacy Policy.