Secrets & Encryption
5 min read
How Staxa Protects Your Data
Staxa encrypts sensitive data at multiple layers:
Environment Variable Encryption
Environment variables marked as secret are encrypted using AES-256-GCM before being stored in the database. The encryption key is managed at the platform level. Secrets are:
- Encrypted at rest in PostgreSQL
- Decrypted only when injected into a Kubernetes Secret at deploy time
- Redacted in the UI: once set, secret values are displayed as
•••••• - Never logged or exposed in API responses
API Key Hashing
API keys are hashed with SHA-256 before storage. When you authenticate with an API key, Staxa hashes the provided key and compares it to the stored hash. The original key is never stored.
Container Registry Credentials
Private registry credentials (passwords, access tokens) are encrypted with AES-256-GCM at rest. When a deployment pulls from a private registry, the decrypted credentials are used to create a Kubernetes docker-registry Secret in the tenant namespace. These Secrets persist in the namespace because the kubelet needs them for Pod restarts.
Database Credentials
Tenant database credentials (username, password) are generated automatically and stored as encrypted environment variables. They're injected into your application as DB_USER, DB_PASSWORD, and DATABASE_URL.
Tenant Isolation
Each tenant runs in its own Kubernetes namespace with:
- Resource quotas: CPU and memory limits prevent one tenant from starving others
- Network isolation: Services within a tenant can communicate internally, but tenants cannot reach each other's internal services
- Separate databases: Each tenant gets its own database instance, not just a separate schema
Still have questions?
Email us and a person will answer, or look it up in the API docs.