This document explains how we protect your data with encryption: while it is stored (at rest) and while it moves between systems (in transit). It also covers how we manage encryption keys and how we keep each customer's data separate.

Summary

• All stored data is encrypted at rest with AES-256. This covers our database, its backups and point-in-time recovery archives, our file storage (including meeting recordings), and our configuration secrets.
• All data in transit is encrypted. Public connections use HTTPS with TLS 1.2 or 1.3. Traffic between our internal services goes over an encrypted private network (WireGuard).
• Your connected-account credentials get a second layer of encryption. We encrypt Google OAuth tokens and other integration credentials inside our application with AES-256-GCM, using keys that we keep separate from the database.
• Each customer's data is isolated. Database-level Row Level Security keeps every workspace's records apart.

Where your data is stored

We run our application, database, and file storage on Railway, in data centers in the United States. Railway owns and operates the hardware that runs our services, and holds SOC 2 Type II and SOC 3 reports from an independent auditor.

Encryption at rest

Railway manages the disk and storage encryption keys. We manage the keys for the application-level credential encryption.

Encryption in transit

Session cookies are marked Secure, HttpOnly, and SameSite=Lax, so browsers send them only over HTTPS and page scripts cannot read them.

How we manage encryption keys

• We generate keys with a cryptographically secure random number generator, and we use only standard, well-reviewed algorithms (AES-256-GCM, SHA-256, HMAC-SHA256, Ed25519, TLS 1.2+).
• We never store keys in our source code, our database, or our logs. We keep them in a dedicated secrets manager, with production secrets separate from development secrets.
• We use envelope encryption for credentials: a fresh data key encrypts each credential, and a separate key-encryption key protects that data key.
• We rotate our encryption and signing keys every year, and at once if we suspect a compromise or when a person with key access leaves.

How we keep customer data separate

Every customer record belongs to a workspace. The database enforces Row Level Security, so a request can read or change only the records of the workspace it is authorized for. Staff support access to a workspace uses audited, time-limited sessions.

Providers that process data for us

We use a small set of established providers, such as Google, a meeting-capture provider, AI model providers, and an email delivery service. Data we send to them travels over HTTPS. We can share the list of providers and their published security reports on request.

Questions

For more detail, a completed security questionnaire, or our list of providers, contact us and we will reply directly.