Data Protection
How Temps protects your data at rest, in transit, and inside the platform.
Because Temps is self-hosted, you own and control all data. Nothing is sent to third-party servers by default. The guarantees below apply to your Temps instance and the data stored within it.
Encryption at rest
Sensitive values are encrypted with AES-256-GCM before being written to the database. The encryption key is stored separately from the database (see Key management below), so a database leak alone does not expose the plaintext.
Encrypted at the database layer:
- Environment variable values marked as secrets
- TLS certificate private keys
- API keys and tokens (stored as ciphertext; the plaintext is only ever shown once at creation time)
- OIDC provider client secrets
- Email provider credentials (SMTP passwords, SES access keys, etc.)
- SSH keys generated for VPS provisioning
- Preview environment passwords
Encryption in transit
All traffic between clients and your Temps instance is encrypted with TLS:
- Automatic TLS via Let's Encrypt for every custom domain and the control-plane console
- TLS 1.3 preferred; TLS 1.2 retained for compatibility
- HSTS headers enforce HTTPS on supported browsers
- Internal service communication — traffic between the control plane and worker nodes passes over authenticated channels
What's encrypted
| Data | Encryption | Notes |
|---|---|---|
| Secret environment variables | AES-256-GCM at rest | Non-secret vars are stored plaintext |
| TLS private keys | AES-256-GCM at rest | Per-domain keys |
| API keys | AES-256-GCM at rest | Plaintext shown once on creation |
| OIDC client secrets | AES-256-GCM at rest | |
| Email provider credentials | AES-256-GCM at rest | |
| User passwords | Bcrypt hash | Hashed, not encrypted — plaintext is never stored |
| All HTTP traffic | TLS in transit | |
| Backup data | At-rest encryption on S3 | Depends on your S3 bucket settings |
Key management
The AES-256-GCM encryption key is stored at ~/.temps/encryption_key (or your configured TEMPS_DATA_DIR). It is generated automatically on first start and never changes unless you explicitly rotate it.
Protect this file. A backup of the database without the encryption key cannot decrypt any secrets. Conversely, the encryption key without the database is useless. Keep them in separate, secure locations.
Backup recommendations
- Back up
~/.temps/encryption_keyto a separate, access-controlled location (not alongside the database backup) - If running Temps in a container, mount the key from a secrets manager or encrypted volume rather than baking it into the image
- Rotate the key periodically by re-encrypting all secrets — currently a manual process; a key-rotation command is planned for a future release
Key loss
If the encryption key is lost, encrypted secrets cannot be recovered. You would need to re-enter all secret values manually. Non-secret environment variables, deployments, projects, and analytics data are unaffected.