Skip to main content
CYPEX Documentation
Support
v2.0.0 Latest stable release View changelog ->

CYPEX Documentation · v2.0.0

Applications generated from a PostgreSQL schema.

The schema is the source of truth: it generates views, the PostgREST data API, and the application UI. Access is enforced by PostgreSQL roles and Row-Level Security — checked by the database on every request, not by application code.

Evaluating CYPEX? See the product overview ↗ on cybertec-postgresql.com.

The platform model

Six steps, in dependency order. Each one builds on — or is gated by — the step before it.

  1. 1

    Organizations

    The top-level tenancy container. Every installation gets a Default Organization; every module, role assignment, and row of data is scoped to one.

  2. 2

    Schema Access

    An Organization's module mapping decides which PostgreSQL schemas it may use at all — the one access decision that doesn't depend on the schema's contents, with one module marked primary as the default namespace.

  3. 3

    Roles & Capabilities

    Roles (System Administrator, Organization Administrator, Organization Member) are assigned per Organization. Capabilities are ordinary PostgreSQL GRANTs issued at the query level, so they can only be granted once the query exists.

  4. 4

    Data Model

    Within an accessible schema (a module), tables are the source of truth. Tracked tables become entities, with generated queries (views in cypex_generated) and workflows (states/state changes, enforced by a CHECK constraint and a row-level trigger) on top.

  5. 5

    Users

    Users hold a Role within an Organization and inherit its Capabilities. Row visibility is enforced separately by Data Scope — PostgreSQL Row-Level Security keyed on Organization membership — so a Capability and a matching RLS policy must both agree before a row comes back.

  6. 6

    Applications

    The Application Designer renders forms, tables, and workflows from the data model above, enforcing the same Roles, Capabilities, and Data Scope. The data API publishes cypex_generated through PostgREST, checking the JWT and RLS policy on every request; CYBERTEC sponsors the PostgREST project.

What's new in v2.0.0

The most significant schema and permission-model change since v1.0.0. Read the upgrade guide before planning a maintenance window.

Organizations

Multi-tenancy as a first-class object. 37 tables gained Row-Level Security policies; isolation is enforced in PostgreSQL, not by UI filtering.

SSO Gateway

A dedicated service for OIDC and OAuth2 federation, with a pending-approval gate. LDAP and local login continue to work unchanged.

Connectors

Governed outbound REST integrations: allowlisted hosts, encrypted per-organization credentials, two-level enablement, and execution audit.

Breaking permission changes

RLS on 37 tables, new required JWT claims, and Organization Member becoming SELECT-oriented on core tables. Audit direct database consumers before upgrading.

Deployment & ownership

CYPEX is self-hosted: Docker Compose brings up the application, PostgreSQL, PostgREST, and the SSO Gateway on infrastructure you control, with no product call-home. Deployment covers the trial and enterprise editions, an internal or external PostgreSQL database, and the secrets each service needs — see Getting started for the path from a fresh stack to a first working app.

CYPEX is available as a Structured Infrastructure Component within CYBERTEC ScaleField.

The Element Dictionary

Every Application Designer element is a configurable UI component bound directly to a PostgreSQL query or function — forms, tables, charts, GeoJSON fields, PDF reports, file uploads, and more.

Explore the Element Dictionary