Unified config across API-platform products

[Piumal1999]

1. What is the problem

Today the developer-portal and ai-workspace distributions each bundle the platform-api image together with a platform-api config subset.

However, since platform-api is meant to be a single shared service, the current setup has the following issues:

• If someone running ai-workspace also wants the developer-portal, there is only one platform-api that must serve both — but each distribution assumes it owns its own. So the two distributions cannot simply be run side by side.
• If everything runs within one distribution, there needs to be one shared config for the whole thing rather than separate, overlapping per-product configs.
• The platform-api config subset bundled in each portal is a hand-maintained duplicate that drifts from the real platform-api config, and forces workarounds in the setup scripts (e.g. the same JWT secret written under two different env-var names).

2. Why we are solving it

• Run both portals against one shared platform-api — enable a single distribution where developer-portal and ai-workspace coexist, sharing exactly one platform-api instance.
• One source of truth per product — remove the duplicated platform-api config from the portals so there is no drift and no config to keep in sync by hand.
• Simpler, consistent config model — one config shape across all products, so operators learn it once.

3. Proposed solution

3.1 One namespaced config, merged at build time

• Every config section is prefixed by product: [platformapi.*], [devportal.*], [aiworkspace.*]. No unprefixed/global sections.
• Each product owns only its own prefixed sections — platform-api owns [platformapi.*], developer-portal owns [devportal.*], ai-workspace owns [aiworkspace.*]. No duplicated config anywhere.
• At build time, building a product produces one config that contains only that product's own sections plus platform-api's sections — e.g. the developer-portal distribution ships [devportal.*] + [platformapi.*], and the ai-workspace distribution ships [aiworkspace.*] + [platformapi.*]. The old separate config-platform-api*.toml files go away. If needed, the user can add the additional config for the optional product.
• Each product reads only its own sections at runtime and ignores the others.

3.2 One distribution, the second portal optional

• The distributed docker-compose contains both portals plus the shared platform-api.
• By default only the owning product (and platform-api) starts; the other portal is optional and can be started with a flag in the shipped .env or through profiles.
• Example: in the developer-portal distribution, docker compose up starts developer-portal + platform-api; setting the flag in .env also brings up ai-workspace against the same platform-api. The ai-workspace distribution is the mirror.

3.3 Supporting cleanups

• Unify the setup script into one that provisions the shared environment for all services, and write the JWT secret once (dropping the duplicate env-var name).
• Single shared platform-api version used consistently across both distributions.

4. Needs further discussion

The developer-portal currently depends on platform-api only for demo-mode (file-based) auth. In production, once an IDP is configured, the portal authenticates against the IDP directly and no longer requires platform-api for auth. So the portal ↔ platform-api coupling is primarily a quickstart/demo concern, not a hard production dependency in standalone mode. When used in an all-in-one setup, platform-api has to be connected to the developer-portal only through webhooks. So do we actually need to include ai-workspace image in the devportal distribution?