Igor Kutiavin —
Hi @user, before I start the implementation github.com/archestra-ai/archestra/issues/3857 I'd like to confirm a few design choices that the issue doesn't make explicit. The answers will significantly shape the PR. 1. Where should these settings live? - Platform-level only - env vars / Helm values set by DevOps at deploy time (e.g. ARCHESTRA_ORCHESTRATOR_PERSONAL_K8S_NAMESPACE, ARCHESTRA_ORCHESTRATOR_PERSONAL_KUBECONFIG) - Per-organization, configurable by admins via the UI (stored in DB) - Per-team - Per-user (each user configures their own) The phrasing "through KUBECONFIG" suggests env/Helm, but I want to confirm. 2. One shared personal namespace, or one per user? - A single shared namespace for all personal MCP servers across the org - Namespace-per-user (e.g. personal-{userId}) for full isolation between users 3. Fallback behaviour when personal config is NOT set? - Fall back to the current default namespace (no-op for existing installations, safe rollout) - Hard-fail: installing a personal MCP server is rejected until the operator configures the personal target 4. What about existing personal MCP servers after the release? - Leave them in the old namespace (no migration) - Auto-redeploy them into the new namespace on next runtime startup - Require manual reinstall 5. UI scope? - No UI changes - env/Helm + docs only - Read-only badge on personal MCP servers showing "deployed to namespace X / cluster Y" - Full admin settings page to view/edit the personal target 6. PR scope you want to see? - Backend runtime (manager, k8s-deployment, config) + tests + docs only - Backend + UI badge - Backend + full admin settings UI
