Security & technical measures

1. Infrastructure & hosting

• All servers are located within the European Union (Hetzner, Germany and OVH, EU region).
• Object storage is provided by Hetzner Object Storage (EU, Germany).
• The application is deployed as isolated Docker containers via Kamal.
• TLS/HTTPS is enforced for all connections using Let's Encrypt certificates.

2. Access control

• Production server access is restricted to SSH key authentication; password login is disabled.
• Infrastructure is managed by a single operator — there are no shared accounts or team credentials.
• Application authentication uses signed, HttpOnly session cookies that cannot be read by JavaScript or tampered with.
• Passwords are hashed with bcrypt via Rails has_secure_password; plaintext passwords are never stored.

3. Data in transit

• All communication between clients and the server is encrypted via TLS 1.2 or higher.
• HTTPS is enforced at the proxy level; unencrypted HTTP requests are redirected.

4. Data at rest

• Passwords are hashed and salted using bcrypt — not stored in recoverable form.
• Session identifiers are stored as signed cookies — tamper-evident by design.
• Database files are not currently encrypted at the storage layer. This risk is mitigated by EU-only server hosting, SSH-key-only access, and single-operator control.

5. Application security

• CSRF protection is enforced on all state-changing requests via Rails built-in mechanisms.
• All database queries use parameterised statements — no raw SQL string interpolation.
• Data access is strictly scoped to each customer's organisation; cross-tenant access is not possible at the application layer.
• Content Security Policy (CSP) headers are set to restrict resource loading.
• Static security analysis (Brakeman) and dependency vulnerability scanning (bundler-audit) run automatically on every code push via CI.
• On the Pro and Team plans, an audit log records configuration and access changes — who changed what, when, and from which IP address. Entries cannot be edited or deleted from the application, and secret values such as tokens and webhook URLs are never recorded. See the audit log documentation.

6. Monitoring & incident detection

• Application errors are monitored in real time via Sentry.
• Alerts are sent immediately to the operator when unexpected errors or exceptions occur.

7. Backups & recovery

• Database backups are performed automatically on a regular schedule.
• Backups are stored separately from the primary database server.
• Restore procedures are tested periodically to verify recoverability.

8. Organisational measures

• A single, identified operator is responsible for all data processing activities and security decisions.
• Third-party subprocessors are evaluated for EU presence and GDPR compliance before use. See the Subprocessors page for the full list.
• Software dependencies are reviewed and updated regularly to address known vulnerabilities.
• In the event of a personal data breach, the operator will assess the impact and notify affected users and the relevant supervisory authority as required by law.

9. Contact

To report a security issue or ask questions about these measures, contact us at: [email protected]