This page explains how to use the client-add-organization-id SQL template to backfill the organization_id column on existing application-schema tables and assign clients to organizations.

Warning

Rehearse this on a staging copy before running it in production. This migration has failed in the field: the failure modes and the safeguards that prevent them are listed under Failure modes below.

Download the template:

This page lists the changes in CYPEX v2.0.0 that alter the default behavior of the platform without breaking existing integrations. You should be aware of these changes, but they typically do not require action.

A new row is inserted into cypex.t_config with key password_policy and value:

An Organization sits at the centre of two independent mappings, not at the end of a chain. One mapping says which roles belong to the organization; the other says which schemas it may use. Both point at cypex.t_organization, and neither knows about the other:

pg_roles                          cypex.t_module
(login identity, grants)          (schema registry)
    │                                   │
    │  cypex.t_role_organization        │  cypex.t_module_organization
    │  (role_name ↔ organization)       │  (module_id ↔ organization)
    │                                   │
    └──────────►  cypex.t_organization  ◄──────────┘
                  (the tenant boundary)

A user sees a row only when both mappings agree: their role is mapped to the organization, and the schema holding the object is granted to that same organization. Satisfying one without the other produces an empty result, not a partial one.

In CYPEX, an Organization is the unit of multi-tenancy. Isolation is enforced in PostgreSQL by Row-Level Security policies that read the request JWT, not by filters in application code. Application traffic — the generated UI, PostgREST API clients, and the backend’s end-user request path — is subject to the same policies, so reaching the database through a different client does not widen what a user can see.

Organizations are not an authorization system on their own. They add a per-request data scope on top of the PostgreSQL role grants that decide what a user may do.

This page lists the purely additive changes in CYPEX v2.0.0. These do not modify the behavior of existing functionality — they add new tables, functions, indexes, and roles that integrate with the Organizations model.

The central tenant table. Created by the v2.0.0 upgrade with one row already inserted: the Default Organization (organization_domain = 'default').

This page is the operational counterpart to the conceptual pages in the Organizations section. It targets operators who run CYPEX, the PostgreSQL Application Platform, in production and need to perform the four day-to-day jobs: create, edit, and disable organizations; give users access to an organization; configure org-scoped application visibility (Schema Access); and troubleshoot misconfigurations.

For the why behind the model, see the conceptual pages linked below.

Read these four pages before walking through the procedures:

After running the client-assignment migration, walk through the verification queries on this page. If verification fails, follow the rollback procedure.

For every migrated table:

Run through this checklist before applying the v2.0.0 migration scripts. Each item links to the page that explains why it matters.

• Full logical backup with pg_dump:

  ```bash
  pg_dump --no-owner --no-privileges -Fc -f cypex-pre-v2.dump cypex
  ```
  

• Filesystem snapshot of the PostgreSQL data directory, if your infrastructure supports it.

CYPEX federates login to an external identity provider in two ways. OIDC and OAuth2 logins go through a standalone SSO Gateway service; LDAP is handled inside CYPEX itself and does not involve the gateway. Both paths end the same way: a successful federated login issues a PostgREST-compatible JWT, and the organization and role claims on that token drive the same PostgreSQL Row-Level Security (RLS) policies as local username/password auth. There is no separate SSO security path.

Info

This is the conceptual / architecture reference. For the hands-on, step-by-step walkthrough with screenshots and a real sanitised request/response, see the Setup guide. For the admin-panel GUI reference (screenshots, field-by-field), see Connectors, Connector Secrets, Connector Allowlist, and Connector Enablement.

1. This page — the conceptual / architecture reference.
2. Setup guide — the hands-on E2E walkthrough: rollout, allowlist, credentials, the guided builder, publish, execute, and audit.

A Connector is a governed, server-side definition for calling a third-party REST API and mapping its response into a typed shape a CYPEX application can render — an authenticated CYPEX user’s page can show a table backed by a live external API call, next to tables backed by CYPEX’s own PostgreSQL data.