Build process

The pnpm workspace links the APIs, UIs and shared libraries. Each component image contains its API and UI and is built with its own Dockerfile-<component> at the repository root. EMBEDDED_FRONTEND enables the bundled UI; the Docker images set it automatically and serve API routes under /api after any public subpath.

From the repository root, use the pinned pnpm version and build the libraries before starting an API:

pnpm install --frozen-lockfile
pnpm build:libs

Run a package script with pnpm --filter @apps/http-data-plane-api <script>.

Development

Use the managed HTTP sample for the coordinated stack. App-local YAML files are individual service examples; register the exact SSO clients, receiving audiences and provisioning identities before using them. Tenant Management creates or explicitly imports participants.

First configure authenticated signaling, stable worker IDs, explicit canonical execution scopes and a persistent signing JWK. The checked-in API configuration is an example, not a provisioned participant. A worker does not register itself. Use the sample for organization provisioning and tenant-local Control Plane registrations.

VS Code settings are included for formatting and debugging. Run the relevant test scripts explicitly when checking a change.

To run the http-data-plane-ui and http-data-plane-api in watch mode use the following command:

pnpm dev:http-data-plane-api

and

pnpm dev:http-data-plane-ui

Another option is to run them in parallel by running:

pnpm dev:http-data-plane

For another local instance, copy the app's configuration to a separate file, use a distinct database and port, and register the corresponding clients and public URLs. Set CONFIG_PATH for the API and BACKEND for its UI to those addresses. A second process alone does not create another managed participant.

Docker

Build from the repository root:

docker build -f Dockerfile-http-data-plane -t http-data-plane:local .

Run it with your configured worker file, persistent database and signing key mounted, and CONFIG_PATH pointing to that file. Publish the configured server port. The default image alone does not supply accepted execution owners, trusted SSO configuration, tenant registrations or durable credentials. See the HTTP Helm chart for the required deployment values.

Database schema migrations

Changes to data access objects (*.dao.ts) can require migrations. Keep separate SQLite (*-sqlite.ts) and PostgreSQL (*-postgres.ts) migrations under src/migrations. Generate them and check for remaining schema changes with:

pnpm --filter @apps/http-data-plane-api migrations:generate
pnpm --filter @apps/http-data-plane-api migrations:check

Back up existing databases before applying an upgrade. Schema checks do not establish that an existing participant has been imported into Tenant Management.

Continuous integration

The GitLab pipeline builds components, runs tests and schema checks, scans dependencies and containers, and checks generated configuration and API references. Release publication uses the repository's release jobs. Consult the current pipeline definition for job rules and release parameters.