# ADR-009: Multi-tenancy via accounts and organizations

- **Status**: Accepted
- **Date**: 2026-04-19
- **Deciders**: alkdev

## Context

Initial schema was implicitly single-tenant. Multiple users, projects, and organizations need to coexist. But we don't replicate Gitea's user/team/repo model — Gitea handles VCS access control via operations. The hub handles session, key, and client ownership.

## Decision

Add three small tables — accounts (hub-local identity), organizations (top-level grouping), and organization_members (membership with levels). Link existing tables via FKs (api_keys.ownerId, clients.ownerId → accounts.id; projects.orgId → organizations.id). Bridge to Gitea via accounts.giteaUsername and organizations.giteaOrgName.

## Consequences

Minimal multi-tenancy layer. Doesn't handle fine-grained permissions (that's Gitea's job). Provides ownership tracking and grouping, enough for single-to-few-tenant case. Positive: lightweight, delegates VCS permissions to Gitea, easy to understand. Negative: if we need RBAC beyond owner/admin/member, must extend or add a permissions layer later.