One process owns the dashboard, agents, chat bridges, and cron
Octop packages a surprising amount into one Python service. Its FastAPI server feeds a React dashboard, while the same process runs agents, instant-messaging connections, scheduled jobs, and an HTTP, SSE, and WebSocket API. SQLite is the default control-plane database, with PostgreSQL available. Users get separate agents and workspaces, and each agent can have its own provider, channels, skills, memory, and schedule.
That consolidation is the appeal and the risk. Our checkout had 3,195 files, about 361,061 source lines, and occupied 40.4 MB before installation. The architecture deliberately avoids an external queue or message broker. Restarting rebuilds state from the database, which is pleasantly direct for one household server. It gives operators fewer process boundaries for scaling, fault isolation, or assigning different trust levels to browser, shell, and chat work.
Octop is built for one household or team, not separate tenants
The README describes one administrator and a shared household or small team. JWT authentication separates users, agents, and workspaces inside that deployment. That is useful for a family, a lab, or one department. It does not create an organization boundary suitable for hosting unrelated customers on the same instance.
Issue 107 states the distinction plainly: current resources are owned by users, and Octop has no first-class tenant entity. The proposed design would add tenant ownership across agents, providers, connectors, workspaces, and cron jobs, but it is still an open request. The 233-package environment we installed should therefore be evaluated as one trusted deployment, not as a ready-made multi-tenant service. Separate organizations need separate instances or a completed isolation design with tests.
What happened when we ran it
Our sandbox installed commit 9d9a501 in 42 seconds. That pulled 233 Python packages and left 787 MB on disk. The build then completed successfully in 2 seconds. Pip-audit found 0 known vulnerabilities in the installed packages. These results make a source trial straightforward, though 787 MB is worth noticing before model caches, document collections, browser binaries, and user files arrive.
The test command did not finish inside 900 seconds. Its last output was around 6% progress, showing rows of passing dots and several skipped cases. There was no failing assertion in the supplied tail, so calling the suite broken would overstate the evidence. The defensible result is that Octop's full test path exceeded a 15-minute limit on 3 CPUs and 8 GB of RAM. Teams with shorter CI jobs will need to split or selectively run it.
Our scan found 9 CI workflow files and a tests directory, but no Dockerfile in the 3,195-file checkout. The README still recommends Docker Compose for production and points to docker/docker_build.sh for a manual image build. That mismatch deserves a look at the packaging path for the exact release you deploy. It does not change the measured result: install and build passed, while the suite timed out without reaching completion.
The easy installer leads to privileged features
Octop's installer provisions Python 3.12 under ~/.octop/, so it does not replace system Python. octop init creates the database, JWT secret, and first administrator. A single octop run then exposes the dashboard on port 8088. Desktop artifacts exist for Windows, macOS, Linux, and FnOS, and optional packages add Playwright browser support or local embedding weights.
An operator still has sensitive work after those 42 install seconds. Provider settings decide where prompts go. Feishu, DingTalk, QQ, Discord, and WeCom each need platform credentials. Agents may gain shell commands, persistent browser profiles, remote desktop input, OAuth connectors, MCP tools, and outbound access to coding agents such as Claude Code or Codex. The README documents approvals, command rules, JWT isolation, and PII redaction, but policy defaults must be tested against your own threat model.
Deleted conversations may leave storage behind
Everything accumulates under ~/.octop/: the database, secrets, logs, agent workspaces, uploads, generated files, and optional model caches. Backups and upgrades are documented, with schema migration on boot. What is missing from the operator story is equally important: retention limits and verifiable reclamation after users delete work.
Issue 725 describes a server used for half a month whose disk kept filling after conversations were deleted. The reporter found remaining agent directories, uploads, generated outputs, and database space, with no cleanup control in the dashboard. One report does not establish every cause it proposes. It does establish a practical check for a shared service: create and delete representative data, measure the filesystem before and after, and decide who owns vacuuming and orphan cleanup. The initial 787 MB environment is only the floor.
Version 1.0.0 is active, but some foundations remain private
Octop released v1.0.0 on September 14, 2026, and GitHub recorded another push on September 16. The repository showed 2,874 stars and 208 combined issues and pull requests. Activity on September 16 included fixes and proposals for model selection, expert visibility, locale handling, tenant design, disk cleanup, and an offline Windows startup failure. This is active development rather than an abandoned release tag.
The public repository does not yet cover the whole named stack. Its README says harness-agent, harness-gateway, harness-memory, and harness-browser are being prepared for open sourcing, with links to come later. That weakens independent review of the runtime beneath many headline features. Octop is still an interesting private-team trial because the surface area is difficult to assemble elsewhere. Run it as one trusted service, measure storage growth, and keep powerful tools behind explicit approval until the supporting layers are available to inspect.