Skip to main content
Every site generated by REG121 is a real React application — not a static export. It communicates with a dedicated REST API layer that is scoped to that site, and all persistent data is stored in an isolated Postgres schema provisioned specifically for that site. This page describes how those components fit together.

​
Site Structure

A generated REG121 site consists of three distinct layers:

React Frontend

The client-side application is a React app. It is not a statically exported HTML site — it runs as a full React application and communicates with the per-site API layer at runtime.

Per-Site REST API Layer

Each site is provisioned with its own REST API layer. The React frontend communicates with this API to read and write data. The API layer is scoped exclusively to the site and its associated Postgres schema.

Isolated Postgres Schema

Persistent data for the site lives in a dedicated Postgres schema. This schema is provisioned automatically when the site is created. You do not configure or manage the database directly.
Schema provisioning happens at site creation. By the time you interact with a site, its Postgres schema and API layer are already in place.

​
Tenant Isolation

Isolation between sites is enforced at the database level. Each site’s data lives in a separate Postgres schema. The application layer for one site has no structural path to the schema of another site — this is not a policy enforced only in application code. To be precise:
  • Each site maps to exactly one Postgres schema within the shared cluster.
  • The per-site API layer is bound to that site’s schema. Requests routed through one site’s API cannot reach another site’s schema.
  • Schema-level isolation means that even if application-layer logic were misconfigured, the database boundary would remain intact.
  • Row-level isolation applies within the schema to enforce access control within the site’s own data.
This structure means tenant isolation is a property of the storage architecture, not solely a runtime guarantee. You do not need to implement cross-tenant access controls in your own application code — the boundary is structural.

​
Authentication Layer

Each site is provisioned with its own authentication infrastructure. This covers end-user account creation, login, and session management. The auth system is tied to the site’s isolated Postgres schema — user records and session state are stored within the same schema boundary as the rest of the site’s data, not in a shared auth store. Because auth state is scoped to the site’s schema, authenticated sessions for one site have no relationship to sessions on another site, by construction.
The specific implementation details of the authentication layer — including token format, session duration defaults, and supported auth flows — are pending confirmation from the REG121 engineering team. The structural guarantees described above (per-site auth, schema-scoped storage) reflect the platform’s stated architecture, but you should verify specifics against current API documentation or direct engineering sources before building auth-sensitive integrations.