Octop 1.0.3, hands-on: upgrade your self-hosted AI assistant and build your first expert team

Tencent's Octop has doubled to 11,753 stars since our first guide, and versions 1.0.2 and 1.0.3 add expert teams, a second-instance cloud bridge, memory you can edit by hand, and an agent MCP gateway. Back up, run octop update, and put the new features to work — every command verified against the current README and release notes.

• Project: TencentCloud/Octop (MIT) — a self-hosted, multi-user, multi-agent AI assistant; 11,753 stars on November 7, 2026, up from 5,500+ on September 28.
• Versions: 1.0.2 stable, October 18, 2026; 1.0.3b1, October 25; 1.0.3b4 beta, November 6, 2026 (latest).
• Upgrade: octop backup, then octop update — preserves ~/.octop/ (database, workspaces, secrets, config.json). Docker: ghcr.io/tencentcloud/octop:1.0.3b4 (lite, now the default tag); full is :1.0.3b4-full.
• Teams: a host expert dispatches tasks and writes the closing summary; member replies return to the chat and sync to instant messaging. Default modes: Ask, Plan, Craft (Craft is the default).
• Memory and bridge: USER.md and MEMORY.md are editable by hand and win conflicts; skill packs export as ZIP with copy policies snapshot, lock, or deny; the cloud bridge shares chat and a writable workspace while connectors, skill packs, and knowledge stay local-only.

Six weeks ago we installed Tencent’s Octop, a self-hosted, multi-user AI assistant, at version 1.0.1. Since then the project has more than doubled — from 5,500 stars to 11,753 — and shipped two releases that change what the assistant can do: 1.0.2 (October 18) adds expert teams, a bridge between two Octop instances, memory you can edit by hand, and an agent MCP gateway; the 1.0.3 betas (October 25 – November 6) add encrypted secrets, user groups, and a cloud-host operations page. This guide upgrades a running 1.0.1 install to the latest release and puts the three biggest new features to work.

The upgrade itself is the easy part. Octop’s own docs say octop update replaces only the wheel or binary and preserves everything under ~/.octop/ — the database, workspaces, secrets, and config.json — with the schema migrating automatically on the next boot. The work is what comes after: building a team of experts that actually collaborates, taking direct control of what your assistant remembers, and moving a skill pack to a second machine. Every command below was verified against the current README and the 1.0.2 / 1.0.3 release notes.

What you’ll need#

• An Octop 1.0.x install — the one from our first guide, or a fresh install via the one-line installer (curl -fsSL https://download.octop.cloud/octop/scripts/install.sh | bash). Fresh installs can skip Steps 1–2 and start at Step 3.
• A model provider key already wired in — any OpenAI-compatible provider. If you want a fully local model behind Octop, our Ollama hands-on guide sets one up.
• Docker (optional) if you run Octop in a container instead of the installer or PyPI package.
• Ten minutes and a backup habit. Cross-version upgrades are the one moment the docs explicitly tell you to back up first.

Step 1: Back up before you touch anything#

Octop keeps all runtime state under ~/.octop/, and the upgrade guide is blunt about it: always back up first (octop backup) before a cross-version upgrade. Run it while the current version is still healthy, so the backup you restore from is a known-good one.

octop backup

The command exports a backup of the instance — database, workspaces, and configuration — and the same command restores it if the upgrade goes sideways. If you run Octop in Docker, your data lives in the octop-data volume instead; the equivalent safety net is a volume backup before you pull the new image, for example docker run --rm -v octop-data:/data -v "$PWD":/backup alpine tar czf /backup/octop-data.tar.gz -C /data . — stop the container first so nothing writes mid-copy.

Step 2: Upgrade to 1.0.3#

For installer and PyPI installs, one command does the upgrade:

octop update          # fetch and install the latest octop, then restart the service if one is registered

Your ~/.octop/ directory is untouched; the schema migrates automatically on the next boot, and you only run octop init again if the setup wizard prompts for a migration. PyPI users can also pin the upgrade explicitly with pip install --upgrade octop.

For Docker, pull the new tag. Note the tag change in 1.0.3: the default tag is now the lite image, and the full image — desktop, OCR, local models — moved to the -full suffix.

docker pull ghcr.io/tencentcloud/octop:1.0.3b4        # lite (now the default tag)
# docker pull ghcr.io/tencentcloud/octop:1.0.3b4-full  # full image instead
docker compose -f docker/docker-compose.yml up -d

One version note before you commit: the newest release is 1.0.3b4, a beta from November 6. The latest stable is 1.0.2, from October 18. The beta is where the cloud-host page and the newest fixes live; the stable is the cautious pick for a machine you depend on. Everything in this guide works on 1.0.2 except the Step 7 note on the cloud-host page, which needs 1.0.3b4.

Step 3: Verify the upgrade and open the dashboard#

Start Octop the same way as before and open the dashboard:

octop run
# Custom host / port
octop run --host 0.0.0.0 --port 8088

Open http://127.0.0.1:8088. The visible proof that 1.0.2 landed is the Teams UI and the Memory page’s new tabs; on 1.0.3b4 the Workbench gains a cloud-host page at the end. If the dashboard asks for the setup wizard instead of your login, stop: the upgrade did not find your ~/.octop/ data directory, and restoring the Step 1 backup is the fix — do not create a second admin account on top of it.

Step 4: Build your first expert team#

This is the headline feature of 1.0.2, and the one that changes how Octop feels day to day. Until now every expert worked alone. Now experts can form a team: a host expert takes your request, splits it into tasks, dispatches them to member experts, and writes the closing summary. Member replies come back into the same chat — and sync to instant messaging if the team is wired to a chat channel.

Build one from the dashboard, not the CLI — teams are a dashboard concept:

1. Create the members first. Make two or three experts with narrow jobs — for example a researcher that reads and summarizes, and a writer that turns notes into a draft. Give each a tight system prompt and only the connectors it needs.
2. Create the team and pick a host. The host is the expert that talks to you; it dispatches work and owns the final summary. A good host prompt says what “done” looks like, so members don’t hand back half-finished work.
3. Give the team one real job. “Research the three cheapest nonstop flights to Tokyo next month and draft the booking email” exercises the whole loop: the host splits research from drafting, the members work in parallel, and the summary lands in your chat.

Two details from the release notes matter in practice. First, each expert can now set a default conversation mode — Ask, Plan, or Craft (Craft is the default) — so set members to Craft and let the host run in Plan when it needs to think before delegating. Second, team work is visible: the session list shows in-progress and pending states, and you can add a follow-up mid-turn without waiting for the current round to finish.

Step 5: Take control of what your assistant remembers#

1.0.2 also fixes the most common complaint about long-running assistants: memory you can’t inspect or correct. The Memory page now has two tabs you can edit directly — User profile, which edits USER.md, and Strong memory, which edits MEMORY.md. Agent file tools are read-only on these files; you are the editor.

Try it with something the assistant keeps getting wrong:

1. Open the Memory page and switch to the User profile tab. Add a line the assistant should treat as fact — your timezone, the tools you actually use, the spelling of your name.
2. Switch to Strong memory and write one durable fact the assistant has learned about your work — a standing instruction, a preference, a project it should always assume.
3. Ask it something that depends on the fact, and check the answer reflects the edit.

The safety rule is explicit in the release notes: your manual documents take priority, and when a new memory conflicts with what you wrote, it goes to review for your confirmation instead of silently overwriting it. That is the difference between a memory and a guess. Backups help here too — the Memory page supports backup and restore of the current expert’s memory, so an edit you regret is reversible.

Step 6: Export a skill pack and import it on a second machine#

Skills used to be stuck on the machine that created them. 1.0.2 lets you export a single skill — or a whole skill pack — as one ZIP, carry it to another Octop instance, and import it there. If you run Octop on a home server and a laptop, this is how the two stay in sync.

1. In the dashboard, open the skill or skill pack and choose Export. You get a ZIP containing the skill files.
2. On the second machine, import the ZIP into the same screen. The skill lands ready to attach to an expert.
3. If you share a pack with someone else’s instance, check its copy policy first: the pack owner can set copy_policy to lock (copies carry an origin/locked watermark and non-creators can’t write to the copied workspace) or deny (copying is refused outright). The default, snapshot, copies freely.

This pairs with the 1.0.3b1 change that lets skill packs be shared and edited as a file tree — if you maintain a pack for a team, the file-tree editor is the faster way to curate it than one-skill-at-a-time edits.

Step 7: Link a second Octop over the cloud bridge#

The second headline feature of 1.0.2 is the Octop-to-Octop cloud bridge: two instances can use each other’s experts. From your instance you can chat with a remote expert and edit files in its workspace; the bridge is deliberately partial — tools, plugins, and channels are only partly writable, and skill packs, the global ACP configuration, connectors, and the knowledge base stay local-only.

The practical setup is a home server plus a laptop. Put the heavy experts — the ones with local models, big knowledge bases, or always-on connectors — on the server, and call them from the laptop’s Octop over the bridge instead of duplicating them. The remote expert behaves like a local one in chat; the boundary only shows when you ask it to do something that lives on the other machine’s connectors.

On 1.0.3b4 there is one more new surface worth a look: the Workbench’s cloud-host page. After authorizing a Tencent Cloud account, it lists your CVM instances and lets a resident operations expert patrol them and make changes. It is Tencent Cloud-only for now — the page says so — so if your servers live elsewhere, skip it and keep the bridge as your multi-machine story.

What you built#

You now run Octop 1.0.3b4 (or stable 1.0.2) with a backed-up ~/.octop/, a team of experts that splits work and reports back in one chat, memory files you can read and correct, a skill pack that travels as a ZIP, and — if you have a second machine — a bridge to its experts. The single-expert assistant from the first guide is still there underneath; the upgrade adds the collaboration layer on top of it.

Honest limitations#

• 1.0.3 is still beta. 1.0.3b4 is the fourth beta, not a stable release. Expect rough edges, and pin 1.0.2 if the machine matters more than the newest features.
• The cloud-host page is Tencent Cloud-only. The CVM operations expert is genuinely useful if your infrastructure is on Tencent Cloud; otherwise it is a page you will never open.
• The bridge is partial by design. Remote experts chat and edit files, but their connectors, skill packs, and knowledge bases stay home. A remote expert can’t use a connector that only exists on the other instance.
• Some of the new surface is China-ecosystem first. The new connectors include Qichacha, Yuque, and DingTalk; the release notes are written in Chinese first. The core — teams, bridge, memory, MCP gateway — is language-neutral, but expect some docs to lag in English.
• The MCP gateway is an interface, not a product. 1.0.2 lets other programs call your agent through the Agent MCP gateway, but you still have to wire the client side yourself; there is no bundled client.

What else is new, in brief#

Two more 1.0.2 additions are worth knowing even if you don’t set them up today: experts can be reached through the Agent MCP gateway from other programs, ONNX models can load directly without touching Hugging Face, and LDAP login plus Telegram user restrictions cover the multi-user side. 1.0.3b1 adds user groups that can restrict which skills, knowledge bases, connectors, models, storage, and experts each group sees, support for the OpenAI Responses API, and secrets encrypted at rest instead of stored in plaintext. And 1.0.3b4 syncs new preset models on startup, with the Tencent Cloud channel now supporting HY4.

Sources#

• TencentCloud/Octop (GitHub) — README: install, octop update, octop backup, Docker images; read November 7, 2026.
• Octop v1.0.2 release notes — expert teams, cloud bridge, editable memory, skill-pack export, MCP gateway, new connectors; October 18, 2026.
• Octop v1.0.3b4 release notes — cloud-host page, system-notification reminders, HY4 support, lite default Docker tag; November 6, 2026.
• Octop v1.0.3b1 release notes — user groups, Responses API support, encrypted secrets, subpath deploy; October 25, 2026.