Legal · Encryption
Encryption posture Every data class DevShot processes, the encryption mechanism that protects it at rest, who holds the key, and the residual risk that remains after that protection. Last reviewed 2026-04-15 .
Data stores Supabase Cloud Postgres (public.* tables) All non-secret application rows (users, servers metadata, audit log, billing identifiers, etc.)
Encryption at rest AES-256, vendor-managed Key management Supabase manages the KMS key; DevShot has no access Evidence Supabase SOC 2 Type II report — see https://supabase.com/security for the latest report and control list. The encryption-at-rest control ID is refreshed during the annual vendor review (spec 035 US-3). Residual risk Supabase staff with KMS access could theoretically read; mitigated by Supabase's SOC 2 controls Supabase Cloud Postgres — DevShot-encrypted secret columns servers.hmac_secret_enc (tunnel HMAC secret), storage_providers.secret_access_key_enc (customer S3 secret access keys)
Encryption at rest AES-256-GCM, application-layer (spec 036) Key management FIELD_ENCRYPTION_KEY in the Railway environment; rotation runbook at .specify/compliance/soc2/runbooks/rotate-field-key.md Evidence apps/console/lib/field-crypto.js + apps/console/lib/field-crypto.test.js (round-trip, tamper, rotation) Residual risk Full DB read yields ciphertext but not plaintext; both the DB and FIELD_ENCRYPTION_KEY must be compromised to recover the secret Supabase Cloud auth (auth.users, auth.sessions) Email addresses, bcrypt password hashes, session tokens
Encryption at rest bcrypt for passwords, AES-256 vendor encryption for the rest Key management Supabase managed Evidence Same Supabase SOC 2 report cited above Residual risk Same as application Postgres Customer Bring-Your-Own S3 (AWS / R2 / B2 / MinIO) qcow2 / raw VM overlay disks
Encryption at rest Customer-managed (each provider has its own at-rest policy) Key management Customer holds the keys (AWS KMS, Cloudflare R2 default encryption, etc.) Evidence Provider documentation (linked from each provider's docs) Residual risk DevShot is not the controller — the customer's S3 provider terms govern the data at rest Railway ephemeral container filesystem (console process) Stdout/stderr logs, /tmp scratch files
Encryption at rest Railway disk encryption (vendor) Key management Railway managed Evidence Railway compliance documentation Residual risk Logs are purged on container restart; no long-term storage DevShot Dom0 agent local files (.providers.json, .bucket-map.json) Cached storage-provider credentials (cache of the encrypted DB rows)
Encryption at rest Filesystem mode 0600 (no app-layer encryption); will move to tmpfs per spec 036 US-2 Key management Operator-managed (host disk encryption) Evidence apps/agent/go/providers.go Residual risk Dom0 root compromise yields cached credentials — same blast radius as a Supabase service-role compromise The full encryption-at-rest specification, including the rotation runbook for the application-layer key, is maintained internally as .specify/specs/036-encryption-at-rest/spec.md. Customer BYO storage providers are governed by the customer's own encryption-at-rest policy — DevShot is the controller of metadata only.