> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lanesync.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-tenancy

> How LaneSync isolates GitHub organizations as tenants with PostgreSQL row-level security.

LaneSync is a **multi-tenant SaaS**. Each GitHub organization (or personal account installation) maps to an isolated tenant. Data from one org never leaks into another.

## Tenant model

```mermaid theme={null}
flowchart TB
  subgraph tenantA [Tenant — acme-corp]
    reposA[Repositories]
    milestonesA[Milestones]
    evidenceA[Evidence]
  end

  subgraph tenantB [Tenant — other-org]
    reposB[Repositories]
    milestonesB[Milestones]
    evidenceB[Evidence]
  end

  db[(PostgreSQL + RLS)]
  tenantA --> db
  tenantB --> db
```

| Entity                            | Scope                           |
| --------------------------------- | ------------------------------- |
| Organization                      | One tenant per GitHub org login |
| Repository                        | Belongs to one tenant           |
| Milestone, evidence, quality data | Scoped to repository → tenant   |
| User session                      | Active tenant selected at login |

## Row-level security (RLS)

PostgreSQL **row-level security** policies filter every query by `tenant_id`. Application code sets tenant context per request from the authenticated session.

<Check>
  Even if application code has a bug in a `WHERE` clause, RLS prevents cross-tenant reads at the database layer.
</Check>

## Authentication

| Flow                        | Description                                                                                                          |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **GitHub OAuth**            | Primary sign-in for dashboard users at [lanesync.dev](https://lanesync.dev)                                          |
| **Workspace picker**        | Users in multiple orgs choose which tenant to act as                                                                 |
| **GitHub App installation** | Creates or links tenant on `installation` webhook                                                                    |
| **CI evidence upload**      | Tenant from verified GitHub OIDC token (`repository_owner`) or scoped API key — not from unauthenticated body fields |
| **Webhooks**                | Tenant resolved from GitHub org login on the repository                                                              |

Session-protected routes return `401` without a session and `403` when the user is not a member of the active workspace.

## Who can access a workspace

| Path                       | Who gets access                                                                                                               |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **First installer**        | The GitHub user who installs the LaneSync App on a new org or personal account becomes the workspace **admin** automatically. |
| **Invited teammates**      | Everyone else joins only via an admin invite link (`Settings → Team`).                                                        |
| **GitHub org admin alone** | Does **not** grant LaneSync access — org admins must be invited like any other teammate.                                      |

## Team management

Workspace admins can invite members:

1. `POST /api/team/invite` → invite link
2. Invitee opens link → `POST /api/team/join`
3. Session switches to the invited workspace

Invite tokens are HMAC-signed with a 7-day expiry.

## Self-hosted considerations

Self-hosted LaneSync deployments still use the same RLS model. Each installation typically serves one or more orgs depending on your GitHub App registration. See [Enterprise security](/enterprise/security).

## Public vs session endpoints

| CI-authenticated              | Session required                     |
| ----------------------------- | ------------------------------------ |
| `GET /api/health`             | `GET /api/dashboard`                 |
| `GET /api/auth/*`             | `GET /api/repos`                     |
| `POST /api/evidence/*`        | `GET /api/quality`                   |
| `POST /api/webhook`           | `POST /api/sync/*`                   |
| Selected milestone GET routes | `GET /api/projects`, `GET /api/team` |

See [API introduction](/api-reference/introduction) for the full auth model.