Editions & admin identity

Greenlight ships in three editions. Community (this repository) is what you self-host today. Enterprise and Cloud are proprietary and add organization-aware identity, RBAC, and audit. The HTTP API shape is the same across editions; who can sign in and what they can see differs.

At a glance

See Licensing for what is in the community repo vs commercial editions.

Community self-host (this repo)

Every instance is independent:

1. First visit to /setup creates the super admin (admin_users table).
2. That human signs in with NextAuth (AUTH_SECRET).
3. The UI calls core with GREENLIGHT_API_KEY — a database key with admin scopes (bootstrapped from GREENLIGHT_API_KEY on first boot, or created in Settings).
4. Agents and automation use their own scoped X-API-Key values.

There is no organization picker and no multi-user admin in community today. The whole Postgres database is one tenant. Operators who need a second human account reset admin_users or use shared credentials (not recommended).

Enterprise self-host

Same deployment model as community (your infrastructure, one Greenlight stack), but with commercial add-ons (commercial license required):

• One organization exists logically; it is not exposed as a separate entity in the UI (no org switcher).
• Multiple human users can sign in — not only the first /setup account.
• Role elevation: admins invite users and assign roles (admin, operator, viewer, member).
• Audit log, RBAC, and SSO (OIDC) — unlocked with a valid enterprise license on the standard greenlight / greenlight-ui images.

API keys and channel data still belong to that single company instance; keys should be attributable to teams or integrations, not shared as one global admin secret.

Cloud (hosted)

Multi-tenant SaaS operated by the Licensor:

• A user (identity) can belong to multiple organizations.
• In org A they may be admin; in org B only member (or no access).
• All API and UI operations are scoped to the active organization — no cross-org reads or writes.
• Billing, provisioning, and control-plane are operated by the Licensor (not part of this repository).

Org admins manage members, keys, and settings for their org only. Platform operators have separate internal tooling (not customer-facing).

How this relates to API keys (community today)

Community edition implements scoped API keys at instance scope:

• Keys are rows in api_keys with scope arrays (admin, agent, readonly, …).
• Outbound messages record api_key_id when stored.
• GREENLIGHT_API_KEY in env bootstraps the first admin key only when the table is empty.

That matches a single-tenant self-host. Enterprise and Cloud extend the same ideas with organization_id on keys and resources, human actor on UI actions, and a dedicated audit log — see Security.

Edition roadmap (identity & audit)

For commercial editions, contact the Licensor — see Licensing.