Authentication & access control

Silos authenticates two distinct surfaces: database connections (clients connecting to run SQL) and the management API (creating databases, branches, and keys). It also gives you network- and row-level controls to narrow who can reach what.

Database authentication: SCRAM-SHA-256

Database connections authenticate with SCRAM-SHA-256, the modern challenge-response password mechanism in PostgreSQL. Your driver implements it automatically — you provide the role and password in the connection string and the handshake is handled for you, over TLS 1.3.

psql "postgres://user:password@db-xxxx.silos.sh/main?sslmode=require"

Because the engine is real Postgres, you manage database roles and their privileges with standard SQL (CREATE ROLE, GRANT, REVOKE). Use least-privilege roles for your application rather than connecting as a superuser.

Management API: API keys

Programmatic access to the platform — creating and destroying databases and branches, reading usage — authenticates with API keys passed as a bearer token:

curl "https://api.silos.sh/v1/projects/{project_id}/databases" \
  -H "Authorization: Bearer $SILOS_API_KEY"

Manage keys from the Console, or from the CLI:

silos auth keys

IP allowlisting

You can restrict which source IP addresses are allowed to connect to a database with an IP allowlist. When an allowlist is configured, connections from addresses outside the list are refused before authentication. This is a useful additional boundary when your clients run from known networks — a fixed set of application servers, a VPC, or a CI runner pool.

Configure allowlisting from the Console for the databases that need it.

Row-level security

Because Silos runs genuine PostgreSQL, row-level security (RLS) works exactly as it does upstream. RLS lets you attach policies to a table so that each query only sees the rows it is permitted to — the cornerstone of safely sharing one database across many tenants.

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Your application sets app.tenant_id per session, and Postgres enforces the policy on every read and write. Combine RLS with least-privilege roles for layered in-database isolation. For stronger separation, give each tenant its own database — see Isolation.

Next steps