v2.0.0 is the release in which CYPEX becomes a multi-tenant PostgreSQL application platform. Tenancy is a first-class object (Organizations), isolation is enforced in the database (Row-Level Security), authorization is two-dimensional (Capabilities × Data Scope), schema exposure is explicit (Schema Access), identity can be federated (SSO Gateway), and outbound integrations are governed (allowlist, credentials, enablement, audit).

Warning

This is not a drop-in patch. v2.0.0 changes the permission and tenancy model. Read the Upgrade to v2.0.0 operator guide before planning a maintenance window, then the Upgrading to v2.0.0 technical reference for the database detail.

A CYPEX deployment can serve more than one tenant — an Organization — from the same PostgreSQL database. Isolation is enforced by Row-Level Security in the database, not by UI filtering.

The CYPEX permission model is two-dimensional. A request succeeds only when both dimensions allow it:

1. Capabilities — what the user is allowed to do. Defined by PostgreSQL role grants on queries, functions, and tables.
2. Data Scope — which rows the user is allowed to act on. Defined by Organization membership and enforced by Row-Level Security policies that read the request JWT.

The two are deliberately independent. Granting a capability and assigning an organization are separate operations, and neither implies the other.

The next important step is to define roles. Remember, roles are connected to CYPEX users and represent real database-side users. Role Management lets you manage PostgreSQL database roles and application permissions for your CYPEX platform:

Role Management

Roles define capabilities — what operations a user can perform — which is a separate concern from organization membership, the data scope those operations apply to.

Permissions in CYPEX have two independent dimensions, both required for access:

This page describes the v2.0.0 role model and how roles, JWTs, and RLS policies work together to enforce multi-tenant isolation.

All three roles are created as NOLOGIN group roles. Humans (and the authenticator pool) log in as other roles that are granted membership in these groups — they never LOGIN as cypex_admin, cypex_user, or organization_admin themselves.

Info

This page is the admin-panel walkthrough: where each dimension lives in the GUI, and how they combine at query time. For the full conceptual write-up (JWT claims, RLS SQL, the roleType API contract), see Capabilities vs Data Scope under Organizations.

The v2.0.0 access model has two independent dimensions. A request only returns rows when both agree:

A role with broad capabilities but no organization mapped sees no tenant rows. A role mapped to an organization but with read-only capabilities sees all of that organization’s rows but can’t change them. Neither dimension substitutes for the other.

A high level of protection must be assured of your data. We put great emphasis on security, and ensure that data is protected at all times. As part of that, our user management is based on a solid, well-tested user concept.

The first question we have to answer when talking about security is: “What is a user?”. Having a clear picture in mind is important to understand the big picture.