/updatemcp

description: Re-download the 1C MCP server distribution from vibecoding1c.ru, pull new images, refresh keys and restart installed servers
userOnly: true

/updatemcp — update MCP servers from a fresh vibecoding1c.ru distribution

This command updates already installed 1C MCP servers. It re-downloads the latest distribution from `https://vibecoding1c.ru/mcpserver` (download flow — `/installmcp` → *1.1. Distribution download flow*), unpacks the new archive into a **staging** directory, merges new license keys into the existing `config.env`, pulls fresh Docker images, and recreates the running containers. Reindexing is preserved by reusing existing volumes whenever possible.

Use `/installmcp` for the very first installation (no existing containers, fresh `config.env`). Use `/checkmcp` to inspect the current state at any point.

Load `content/rules/mcp-deployment.md` before locating the installation. Reuse the recorded local or shared host/context, bind address, allocated host ports, full client URLs and daemon-host paths. Run Docker commands against that target explicitly; a remote Debian/Ubuntu Engine needs no local Docker Desktop. Without access to its host, report update work as blocked instead of creating a local replacement. An update never automatically reallocates existing shared ports.

Image variant and outdated tags

The tag contract (variants `latest` / `light` / `arm64`, `IMAGE_VARIANT` and the optional `IMAGE_TAG` override, which tags exist, how to verify a tag, the boundaries) is defined once in **`/installmcp` → `## Image variant`**. Read it there. An update keeps the installed variant; changing it happens only on the user's explicit request.

Since 27.09.2026 there is one channel — stable. An installation still on a `*-beta` tag (`latest-beta`, `light-beta`, `arm64-beta` in `config.env` or on a container) or on an image created before 27.09.2026 is outdated: this update moves it to the same variant without the suffix (`light-beta` → `light`), with the new `LICENSE_KEY_<SERVER>` keys from the archive and the index and container-name handling of the upgrade table in the distribution's `INSTALL.md`. Name the migration in the Step 4 plan; no separate confirmation beyond that plan is needed.

Steps

1. Locate the existing installation

Reuse the known installation root on the selected host. Only if missing, ask **one** question (adapt the path example to that host's OS):

> Где лежит текущий распакованный дистрибутив (`INSTALL.md` + `config.env` + папка `servers/`)? По умолчанию — `C:\Work\MCP_Distr`. Введите путь или нажмите Enter.

Verify that `<EXISTING>\INSTALL.md` and `<EXISTING>\config.env` exist. If not — stop and tell the user that this looks like a fresh install (run `/installmcp` instead).

Read `<EXISTING>\config.env` into memory (parsed key=value); these are the **current** values that will be merged with the new archive in Step 3.

2. Download the fresh distribution

Download and unpack — `/installmcp` → *1.1. Distribution download flow* (`content/commands/installmcp.md`): Tilda credentials from `memory.md` or asked once (storage only with consent — the policy is owned there), stub → `POST /api/login/` → `POST /api/getpage/` → Yandex Disk public link → Yandex Disk Public API → `Invoke-WebRequest`, with the browser-automation / manual fallback. Run it with two update-specific differences:

2.1. Change check before the download

After the archive metadata is resolved (`$meta` from the Yandex Disk Public API), compare `$meta.modified` against the modification time of `<EXISTING>\INSTALL.md` (or any record kept from the previous installation). If the archive on Yandex Disk is older or equal, ask the user:

> На Яндекс.Диске лежит архив `<NAME>` от `<MODIFIED>`, размер `<SIZE>`. Текущая установка в `<EXISTING>` уже использует эту же или более свежую версию. `/updatemcp` может ничего не дать. Продолжать обновление (полезно если нужен `docker pull` под двигающимися тегами типа `latest`) или прервать команду?

Download only if the user proceeds (name + size are shown and confirmed before `Invoke-WebRequest`, as in the canon).

2.2. Unpack into a staging directory (never over the user's `config.env`)

$existing = '<EXISTING_DIR>'                                                   # e.g. C:\Work\MCP_Distr
$staging  = "$existing.new_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
$archive  = '<PATH_TO_DOWNLOADED_ZIP>'                                         # from the download step
New-Item -ItemType Directory -Force -Path $staging | Out-Null
Expand-Archive -LiteralPath $archive -DestinationPath $staging -Force
Get-ChildItem -LiteralPath $staging -Force | Select-Object Mode, Name, Length | Format-Table -AutoSize

Verify that `$staging\INSTALL.md`, `$staging\config.env`, `$staging\servers\` and `$staging\Graph_metadata_search\` exist. If not — the archive layout changed; stop and ask the user to recheck the source.

3. Merge `config.env` (keys-only update, do not lose user data)

Open `$staging\config.env` and `<EXISTING>\config.env` and merge them with the following rules:

| Field class | Source of truth | Action | |---|---|---| | `LICENSE_KEY_*` | new archive | **always overwrite** existing values with values from `$staging\config.env` (these are the new license keys included in the release) | | `IMAGE_VARIANT` / `IMAGE_TAG` | **the existing file** | Keep the installed variant — an archive default must not silently switch `light` to `latest` or the reverse. A `*-beta` value becomes the same variant without the suffix (`## Image variant and outdated tags`). An older file with only `IMAGE_TAG` keeps that key. Show old vs new only when a value actually changes. | | `USE_GPU`, `SSL_VERSION` and other release-version-coupled parameters | new archive default + user confirmation | show old vs new, ask explicitly whether to keep the user's existing value or switch to the new default | | `PATH_1C_BIN`, `PATH_METADATA`, `PATH_CODE`, `PATH_B