NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #1721 by repository stars
Last release today
08 Oct 2026
Ships on a steady schedule
a new release about every 8 days
Some releases are documented
notes for 17 of 56 stable releases
Nothing withdrawn
no release was ever pulled
2 years old
2760 releases · first in 2024
One column per month.
This is a patch release for v0.26.2. It repairs static configuration on connections migrated during the v0.26 upgrade, restores the MCP server Tools a
This is a patch release for v0.26.2. It repairs static configuration on connections migrated during the v0.26 upgrade, restores the MCP server Tools and Troubleshooting tabs, and fixes OAuth with ChatGPT CIMD clients and with servers such as AWS Knowledge MCP.
If you are upgrading from v0.25.x, you can upgrade directly to v0.26.3 and follow the Upgrade Notes in v0.26.2.
frontend identity unavailable.private_key_jwt client assertions addressed to the scoped token endpoint it advertises for each vMCP (/oauth/token/{mcp_id}).Content-Type and Accept headers that the MCP specification requires when it probes a remote server during OAuth setup. Servers that reject requests without these headers, such as AWS Knowledge MCP, no longer fail OAuth metadata sync over and over with resource is required but not provided.${API_HOST} correctly again.Full Changelog: v0.26.2...v0.26.3
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
We're excited to announce the v0.26.2 release of the Obot Platform. This is the upgrade release for v0.26: existing v0.25.x installations can now upgr
We're excited to announce the v0.26.2 release of the Obot Platform. This is the upgrade release for v0.26: existing v0.25.x installations can now upgrade. On startup, Obot migrates existing MCP servers and composite servers to virtual MCPs (vMCPs) while keeping the access users already have. If you maintain catalogs in Git, you need to update them yourself, as described in the Upgrade Notes.
Important
Existing installations can now upgrade to v0.26. The v0.26.0 and v0.26.1 notes said that existing installations should not upgrade, and that upgrade support would follow in a patch release. This is that release. Upgrade directly from v0.25.x to v0.26.2, and follow the Upgrade Notes below. They include required steps for Kubernetes deployments with more than one replica and for anyone who maintains catalogs in Git.
If you are upgrading from v0.25.x, this release includes everything from v0.26.0 and v0.26.1. Read both sets of notes. The main changes are:
The upgrade to v0.26.2 runs a data migration on startup, so it needs extra care when Obot runs with more than one replica.
If you run Obot on Kubernetes, follow these steps. They apply whether you use helm directly or a continuous deployment system.
Recreate in the same change. In the Helm chart, use the updateStrategy value. If you use the helm CLI directly, also pass --server-side=false so Helm can remove the rollingUpdate config.Recreate override. Do not scale above one replica until the migration and startup have finished.If you run Obot as a single-node Docker deployment, follow the normal upgrade procedure.
See #8093 for details or to comment with follow-up questions.
During the upgrade, Obot creates a vMCP for every MCP server that an access control rule explicitly exposes. Each vMCP gets the same access as the original server, enforced through profiles on the vMCP. The upgrade does not grant any user or group new access.
Installations with broad access rules will see many new vMCPs, because every MCP server covered by a rule gets one. This applies to both composite and non-composite servers. After the upgrade, administrators can review these vMCPs and delete any that users no longer need. If users still need a server, keep its vMCP.
This release changes the catalog configuration schema and replaces composite catalog entries with vMCPs. If you maintain your own catalog sources in Git, you must update them using the Obot CLI from this release. Composites created in the Obot UI are converted on startup and need no further action.
All the command run in these steps need the base URL of the Obot instance you are connecting to. The easiest way to do this is to
export OBOT_BASE_URL=https://obot.example.comComplete the deployment upgrade using the steps above and confirm that Obot starts. Use the new Obot CLI and work from a local checkout of your catalog repository. Repeat the remaining steps for each catalog.
Optional: generate vMCP definitions for migrated composites. If your catalog had composite entries, you can have the catalog take over management of the migrated vMCPs. Sign in as an administrator, let the catalog sync finish, and generate replacement definitions:
obot mcp generate-vmcp-catalog https://github.com/example/catalog --mode dir ./vmcpsUse the source URL configured in Obot, including any branch path. The command writes one YAML file for each migrated vMCP waiting to be adopted. It does not change anything in the Obot instance. Resolve any Skipping vMCP messages before you continue. You an also include --format json if you would like the output to be in JSON instead of YAML.
Remove composite definitions. Catalog sync no longer supports runtime: composite. These entries should be removed from the catalog.
Convert the remaining catalog YAML: The remaining catalog entries need to be migrated to the new schema. Use the following command:
obot mcp convert-catalog .This updates files in place. It moves legacy environment variables and configurable headers into the unified config schema and removes serverUserType fields. Similar to the above, you an also include --format json if you would like the output to be in JSON instead of YAML.
Validate the catalog:
obot mcp validate-catalog .Publish and sync. Push the updated catalog to its configured branch, then click Sync under Admin > MCP Servers > Click the Sources tab. Ensure the Git Source URLs contains no errors.
Optional: confirm adoption. Run obot mcp generate-vmcp-catalog-yaml again for the same source. If catalog sync was successful and all vMCP were properly adopted, it reports that none are waiting for catalog sync.
See #8094 for details or to comment with follow-up questions.
The REST endpoints for managing standalone MCP servers have been removed, because vMCPs now cover that work. This includes the server management routes under /api/mcp-servers, /api/mcp-server-instances, and /api/mcp-catalogs/{catalog_id}/servers. The Obot UI already uses the vMCP APIs. If you have scripts or automation that call these endpoints, update them to use vMCPs before you upgrade.
secretBinding, so values such as access tokens can come from a Kubernetes Secret instead of clear text.OBOT_SERVER_PRODUCT_ANALYTICS_MODE. on and off have the same effect as opting in or out in the UI, and the consent prompt and setting are hidden. The default, consent, keeps the current behavior of asking an administrator in the UI.Full Changelog: v0.26.1...v0.26.2
Nothing published for this version
Nothing published for this version
a7220f5 fix: ignore ACRs with no subjects on migration
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
chore: docs and UI dependabot security fixes by @ivyjeong13 in #7972
This is a patch release for v0.26.0. It fixes bugs in vMCP profiles and the vMCP UI, makes group lookups against the auth provider more resilient, and adds support for Bitbucket Cloud catalogs.
Important
This is not the upgrade patch release. The v0.26.0 notes said that existing installations should not upgrade to v0.26.0, and that upgrade support for vMCPs would follow in a patch release. v0.26.1 does not include that upgrade support. The patch release with upgrade support is planned for next week. Until then, the guidance from v0.26.0 still applies: existing installations should not upgrade to v0.26.1, and only net new installations should install it. See #7802 for details.
npx/uvx servers rejected valid MCP list requests that omitted the optional params field..git. Private repositories can authenticate with a personal API token or a repository access token.--git-max-repo-size-mb or OBOT_SERVER_GIT_MAX_REPO_SIZE_MB. The default is still 100 MB.Full Changelog: v0.26.0...v0.26.1
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Note The AntV Charts, Brave Search, Browserbase, Chroma Cloud, MarkItDown, and Playwright MCP servers have been deprecated and will be removed from a…
We're excited to announce the v0.26.0 release of the Obot Platform. This release replaces composite MCP servers with virtual MCPs, adds an in-app MCP tester, and adds opt-in product analytics.
Important
Existing installations should not upgrade to this release. vMCPs do not fully support upgrades in v0.26.0, and upgrade support will follow in a patch release. Only net new installations should install v0.26.0. See #7802 for details.
Virtual MCPs (vMCPs) are now the resource used to expose newly created MCP endpoints. A vMCP holds one or many catalog components, so a single server and an aggregation of several now use the same resource and the same connection model. Standalone and composite servers remain available for migration compatibility.
Each component stores a snapshot of its catalog entry instead of resolving against the live entry at runtime. A catalog edit, a failed sync, or a deletion no longer changes or stops a running server on its own. Drift and missing sources are reported, and a snapshot changes only through an explicit, validated upgrade. Each component also carries a configuration policy that classifies every input as preconfigured, provided at connection time, or ignored.
Access and tool grants come from additive user and group profiles on the vMCP. A profile can grant every tool or map specific tools per component, and a user connecting to the vMCP can narrow their grant but never widen it. Administrators can create vMCPs that other users consume, and a user can create a personal vMCP from catalog entries they already have access to, but cannot share it.
Users can now connect to any vMCP server they have access to and exercise it directly inside Obot. With the tester, users can chat with the configured default model and make real tool calls against the server. An inspector lists the server's tools, prompts, and resources so they can be viewed and invoked individually.
Conversations are ephemeral and are not stored. Chat traffic both show up in the audit logs like any other activity.
Removing an entry from a Git-backed MCP catalog no longer deletes the servers that people have already deployed from it. When a sync removes an entry that still has connections, Obot marks that entry detached and keeps it in a read-only state, so the deployments that depend on it keep working. An administrator can then accept ownership of a detached entry, which converts it into an Obot-managed entry they can edit. If the entry later reappears in the catalog source, the sync reports the conflict instead of silently overwriting the version Obot is holding.
Note
The AntV Charts, Brave Search, Browserbase, Chroma Cloud, MarkItDown, and Playwright MCP servers have been deprecated and will be removed from a future release. Update instructions will be provided one minor-version release prior to their removal. See #7626 for details.
Obot will now report anonymous product usage data; this is disabled until an administrator explicitly opts in. Consent is stored installation-wide as an explicit three-state value, undecided, granted, or declined, and only an Owner or Admin can read or change it.
Administrators are asked once and can change the answer later. In deployments where product analytics is force-enabled through configuration, the consent API is not exposed at all.
system mcp validate command checks a configured MCP server.One security advisory is published alongside this release.
GHSA-6fwv-3h4c-37j9: Authorization bypass through the composite MCP connect route (High). The fix for GHSA-vw82-7fv8-r6gp guarded the /mcp-connect/ route but not the sibling composite route, which reaches the same gateway handler. Any authenticated user, including one with the Standard role, could therefore connect to and use MCP servers through that route without the access control rules that were meant to gate them. This affects v0.21.1 through v0.24.1 and was fixed in v0.25.0. Note that upgrading in response to GHSA-vw82-7fv8-r6gp does not by itself cover this issue, because the fix that advisory describes is the incomplete one. If you are still running v0.24.1 or earlier, upgrade. Reported by @arpitjain099.
Okta users on versions earlier than v0.19.0 must upgrade to v0.25.x first. This release removes an Okta group migration that has been present since v0.19.0 and that pre-v0.19.0 installations still need. Upgrade to v0.25.x so that migration runs, then move to v0.26.0. See #7779 for details.
Replicas in an HA deployment can briefly fall behind during the rolling upgrade. kinm watches now use Postgres LISTEN/NOTIFY instead of polling every two seconds, which cuts idle database load from watches by roughly 15x and propagates a change from one replica to another in tens of milliseconds rather than up to two seconds. During the first rolling deploy of this version, a replica that has already upgraded does not hear from a replica still running the previous version, so it can take some additional time to upgrade. This happens once, closes on its own, and needs no action. Each replica also opens one additional Postgres connection, and connection poolers running in transaction mode do not carry LISTEN, in which case kinm detects it on connect and keeps the previous polling behavior. See #7737 for details.
Note truncated.
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →