Multi-tenancy & isolation
Beakr is a multi-tenant platform where every customer's data is isolated at the database layer — not in application code. Even in a shared infrastructure model, no tenant can access another tenant's data.
How multi-tenancy works
All Beakr customers share the same application infrastructure — compute, networking, and database — but every query is scoped to the authenticated tenant by PostgreSQL itself. This is enforced through Row Level Security (RLS), a database-native isolation mechanism that cannot be bypassed by application code.
Database-enforced Row Level Security
Tenant isolation is not a filter in a WHERE clause — it is enforced by PostgreSQL at the database engine level:
- Every query runs under a restricted database role (
beakr_app) that is subject to RLS policies. - Before any query executes, the authenticated user's organization ID is bound to the database session via transaction-scoped configuration (
SET LOCAL). This context is locked to the current transaction and cannot leak between requests. - PostgreSQL RLS policies automatically filter every
SELECT,INSERT,UPDATE, andDELETEto the authenticated organization. - There is no way to query another organization's data, even with raw SQL, even if application code has a bug.
Fail-closed design
If tenant context is missing from a request, the database returns an error — it does not fall back to unfiltered data. This means a misconfigured request fails safely rather than exposing data.
Role separation
| Database role | Purpose | Can bypass RLS? |
|---|---|---|
beakr_app | All application queries | No |
beakr_migrator | Schema migrations only | Cannot read tenant data |
beakr_admin | Infrastructure operations only | Restricted to infra tasks |
Organization model
Each customer operates within their own organization. Organizations are the primary isolation boundary:
- All resources — projects, files, workflows, connectors — are scoped to an organization.
- Users belong to one or more organizations with explicit role-based membership.
- Cross-organization data sharing requires explicit access grants and is fully auditable.
- Personal organizations are available for individual users.
What is shared, what is not
| Layer | Shared? | Isolation mechanism |
|---|---|---|
| Application code | Shared | Same codebase for all tenants |
| Compute (ECS) | Shared | Requests authenticated and scoped per-tenant |
| Database (RDS) | Shared instance | Row Level Security — PostgreSQL enforces tenant boundaries |
| File storage (S3) | Shared bucket | Object keys scoped to organization ID |
| Cache (Redis) | Shared | Cache keys namespaced to organization |
| Network (VPC) | Shared | All traffic encrypted, no tenant-to-tenant communication |
| Encryption keys | Shared (AWS-managed) | AES-256 at rest for all data stores |
When to choose single-tenant
For most customers, our multi-tenant architecture with database-enforced RLS provides stronger isolation than a typical single-tenant deployment. However, some organizations require dedicated infrastructure for regulatory or contractual reasons: