Trust Center
The real technical architecture behind EnvSync — not a marketing summary. If you want more detail on any of this, see the Security & Encryption docs page.
Encryption at rest
Every secret value is encrypted with AES-256-GCM — an authenticated cipher, so tampering is detectable, not just blocked. Each organization has its own encryption key, itself wrapped by a master key never exposed outside the server process.
Authentication
Sign-in is Google-only — EnvSync never stores or verifies a password, since Google already verifies the account owner controls that email. Sessions use short-lived JWT access tokens plus a rotating, opaque refresh token — only its hash is ever stored. A revoked session is force-signed-out in real time, not on next reload.
Access control
Roles are scoped per project, not org-wide: an org has only one privileged tier (Owner, with unconditional access everywhere); every other member holds Admin, Developer, or Viewer independently on each project they've been explicitly granted access to, evaluated against a configurable per-environment permission matrix. Service tokens inherit their creator's live permissions and are hard-scoped to a single organization — a leaked CI token can't reach any other org.
Audit logging
Every mutating action and every secret reveal writes an immutable audit log entry — actor, action, target, and timestamp. Logs are exportable to CSV for your own review or compliance process.
Application hardening
Rate limiting on authentication endpoints, standard security headers (HSTS, X-Frame-Options, Content-Security-Policy) on every response, and dependency auditing as part of our release process.
Questions about our security posture for a vendor review? Reach out at security@envsync.io.