Security overview

Silos is built so that every database is isolated, every connection is encrypted, and every action is attributable. This section describes the security model honestly: what protects your data today, and — on the compliance roadmap — what we are still working toward.

The model at a glance

Defense in depth

Silos layers several independent controls so that no single mechanism is the only thing standing between a tenant and another tenant's data.

• Compute isolation. Each database is served by its own sandboxed WebAssembly runtime. The sandbox constrains what code can do regardless of what runs inside it. See Isolation.
• Storage isolation. Durable state lives in object storage, scoped per database so one tenant's runtime cannot reach another tenant's snapshots or WAL.
• Transport encryption. Every client connection is encrypted with TLS 1.3, and connections that fail to negotiate TLS are refused.
• At-rest encryption. Snapshots and WAL segments are encrypted with AES-256-GCM before they are written to storage.
• Authentication. Database connections authenticate with SCRAM-SHA-256; the management API authenticates with API keys.
• In-database authorization. Standard PostgreSQL roles, privileges, and row-level security (RLS) apply, because the engine is real Postgres.

Your responsibilities

Security is shared. Silos secures the platform; you secure how you use it.

• Treat connection strings and API keys as secrets — keep them out of source control and load them from environment variables or a secret manager.
• Use least-privilege Postgres roles for your application, and enable row-level security where tenants share a database.
• Restrict access with IP allowlisting where your network topology allows it.
• Review the audit log periodically.