Tenant & workspace

prom.codes is multi-tenant. Two levels of isolation matter:

1. Tenant — the billing account. One per organisation. Owns API keys, members, and a Postgres row-level-security identifier.
2. Workspace — a single indexed codebase inside a tenant. Tenants commonly have one workspace per monorepo or per service group.

Data model

tenant (1) ── (N) workspace (1) ── (N) file ── (N) symbol ── (N) embedding
       │                       │
       └── (N) api_key         └── (N) index_run

Every row in every table carries tenant_id. Postgres row-level security policies enforce that an API key scoped to tenant_id = T cannot see rows from any other tenant — not via the worker, not via the MCP server, not via direct Postgres if a key leaked.

API keys

Each API key is scoped to exactly one tenant and grants access to all of that tenant's workspaces. Per-workspace scoping is on the roadmap (Phase 4) for customers who want CI-only keys.

Keys have the four-segment shape prom_live_<tag>_<secret> (or prom_test_… for staging tenants) — a short public tag for identifying the key in logs and the dashboard, plus the secret. The API hashes the key with Argon2id before lookup — cleartext never hits the database after issuance. Full anatomy in the API key lifecycle.

Workspace creation

In the local-first default there is nothing to provision: the context server registers a workspace automatically from the folder you open (one local index per workspace root). Hosted-index workspaces (the optional server-side path) are provisioned by us during the beta — mail info@e-networkers.de.

RLS verification

The Postgres migration 0001_initial.sql ships explicit CREATE POLICY statements for every table. Internal integration tests round-trip an insert under two distinct SET LOCAL request.jwt.claim.tenant_id identifiers and assert cross-tenant reads return zero rows. The test suite runs on every CI build — an RLS regression breaks the pipeline before deploy.