Tenancy
Series: Tenancy · Members & Roles · Keys · Visibility
Why tenancy matters
A multi-tenant backend has to answer one question on every request: which tenant does this row belong to, and who may touch it? Blarass answers it with a two-level model, enforced in the database (row-level security), not just in application code.
The two levels
workspace (tenant: members, keys, projects — fully isolated)
└── projects (a roadmap: milestones, modules, tasks)- Workspace = tenancy boundary. Its members, keys, and projects are invisible to other workspaces — enforced by RLS, not conventions.
- Project = the roadmap unit inside a workspace. Every task, milestone, and module belongs to exactly one project.
Why it's shaped this way
- Keys are scoped to a member, and members live in exactly one workspace. A leaked key can only ever expose one tenant. Nothing to re-configure — the data model does it.
- Project-level isolation is the finer line: even inside a workspace, private projects keep sub-teams from seeing each other's work. See Visibility.
- When you signed up, your workspace was created along with your owner member and its key — so every member key implicitly carries its workspace context. When you call any route, your key's member row tells the system which workspace you're in.
What this means for you
| You want to... | You need... |
|---|---|
| Create a project | workspace owner/admin role |
| Create tasks in a project | editor project role (or admin/owner) |
| Share with an outside member | add them to the project with a role — see Roles |
| Keep a project sub-team-only | visibility: private — see Visibility |
Related: Members & Roles · Quickstart