Organizations, Projects, Members
Multi-tenancy model — how organizations contain projects, how projects map to apps, and how members get access.
Layers' multi-tenancy is three levels deep:
Organization (your company)
└─ Project (one app or one brand)
└─ Layer (one capability — Social Distribution, Meta Ads, …)Organization
The billing boundary, the member-management boundary, the integration boundary. You should have one Organization per legal entity:
- A solo indie founder has one Organization for all their apps.
- A startup has one Organization, with many Projects.
- An agency has one Organization, with one Project per client.
- An enterprise with EU + US business units may want two Organizations for legal and data-residency separation.
Within an Organization you manage:
- Members and roles
- Billing & subscription
- Wallet (for agency-mode ad spend)
Project
One Project = one app or one brand. A Project has its own:
- Brand voice, audience, target geos.
- Connected social accounts.
- Connected ad accounts (or wallet-funded agency-managed accounts).
- Connected app store listings (App Store + Google Play).
- Installed Layers.
- Members (a subset of the Org with explicit Project access, or inherited).
A Project lives at /project/{projectId}/.... Projects can be created from a
GitHub repo, an App Store listing, or a website URL — see
Create a project.
Members and roles
Membership is managed at the Organization level via organization_members,
with three roles:
| Role | Can do |
|---|---|
| Owner | Everything; including delete the Org. |
| Admin | Manage members, billing, integrations, all Projects. |
| Member | Access Projects within the Organization according to application-level access checks. |
See Members management for the UI flow.
Switching context
The top-left switcher in the app shell lets you flip between Org and Project.
You'll find it in every authenticated view. Bookmarkable URLs include the
projectId, so direct links always preserve context.