Multitenancy & RBAC

How team-based access control and organization-level isolation work.

The starter ecosystem supports multi-organization accounts out of the box, with built-in Role-Based Access Control (RBAC).

Organization Model

Users are assigned a Default Team upon registration, allowing them to start working immediately.

• Teams / Organizations: Logical groupings for users and resources.
• Isolation: Each team has its own data, API keys, and settings.

Roles & Permissions (RBAC)

Strict control is maintained via the backend middleware, with roles and permissions defined for each user's membership in a team.

• Owner: Full access to all team settings, including billing, API keys, and deletion.
• Admin: Can manage team members, resources, and most settings.
• Member: Can view data and perform basic operations within the team.

RBAC Middleware

The API server uses a custom middleware to enforce RBAC rules based on the user's role in the current team.

// apps/api/src/middleware/rbac.ts
import { requireRole } from "./rbac";

// In your routes:
router.post("/teams/:slug/settings", requireRole("admin"), async (req, res) => {
  // Only owners or admins can update team settings
});

Team Switching

Users can switch between different teams they are members of. The frontend maintains the active_team in the user's session, which is then used by the API to identify the current team context.

• Team Switcher: A UI component allows users to switch between their teams seamlessly.
• Persistent Selection: The last active team is remembered across sessions.

Workspace Isolation

All data in the database is associated with a teamId (or organizationId). This ensures that users only have access to the resources they are authorized to see.

• Data Privacy: No data leakage between organizations.
• Tenant-Level Settings: Each team can configure its own settings, such as API keys and integrations.