Hey, a small heads-up: TypeScript 7 was merged yesterday. type-check now uses tsgo, and in practice it can run up to 10x faster.

PR: https://github.com/archestra-ai/archestra/pull/4051

Announcement: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/

Visual Studio Code extension: https://marketplace.visualstudio.com/items?itemName=TypeScriptTeam.native-preview

I launched a new Slack stream to the website yesterday. Please let me know what you think 🙂 https://archestra.ai/community-stream/general/2026-04-24

New release! 🚀🚀🚀

Features

Bug Fixes

Dependencies

Miscellaneous Chores

^ Friday release to those who asked 😂

Hey team 👋 Nothing urgent here at all - hope you’re all having a great weekend and enjoying some downtime, I’ll just leave this thread here so you can share any thoughts whenever you have time.

Quick follow-up on the durable memory feature - I'll leave further detailed information inside the thread so as not to clutter the feed.

Hi @user, before I start the implementation https://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. ARCHESTRAORCHESTRATORPERSONALK8SNAMESPACE,

ARCHESTRAORCHESTRATORPERSONAL_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