CubePlex: a self-hosted workspace platform for managed AI agents

What CubePlex solves for teams running agents together

Most agent tooling assumes one person at one keyboard. CubePlex starts from the opposite assumption: an organisation with several workspaces, several people, and agents that need to keep working between sessions. The README describes it as a cloud-native platform for managed agents in team workspaces, covering skills, shared memory, MCP tools, persistent sandboxes, governed access and self-hosted deployment.

The audience is therefore an engineering or platform team, not an individual developer. The feature table lists organisations, workspaces, roles, model access policies and cost tracking as first-class concerns. That is a different product category from a chat client with plugins: the unit of work is a workspace, and the agent inherits the workspace's memory, tools and sandbox rather than the operator's local machine.

The persistent sandbox is the part that changes day-to-day behaviour. The README states that per-workspace isolated runtimes keep persistent storage, so files, packages and the working tree survive restarts and agents resume the same work site. Without that, every restart resets an agent to a blank environment. With it, the workspace becomes a long-lived place rather than a session.

How the runtime, sandboxes and trust boundary fit together

The architecture diagram in the README separates clients, the application and agent runtime, workspace sandboxes, external services, and persistent infrastructure. The agent runtime itself is not written from scratch: the README says CubePlex's runtime is built on CubeLoop, described as an async-native agent framework for multi-provider model access, tool execution, streaming, middleware and durable checkpoints. Durable checkpoints are what make a long-running agent recoverable rather than a single in-memory loop.

The repository layout matches that split. backend/ holds the FastAPI API and the CubeLoop-based agent runtime, frontend/ holds a Next.js web app plus shared TypeScript packages, deploy/ holds Docker Compose and Kubernetes/Helm assets, and docs/ holds the product documentation site. Both deployment modes use the same backend and frontend images, so the difference between them is orchestration, not code.

The trust boundary is stated explicitly: external model providers, MCP servers and IM platforms remain outside CubePlex's trust boundary. That has practical consequences. Credentials for those services, whether static or OAuth per the MCP feature row, are configuration you supply, and the platform does not claim to secure them for you. Governance in CubePlex means roles, model access policies and per-workspace tool grants, not isolation from third-party providers.

Installing CubePlex and running a first agent workspace

The README points production installs at two guides rather than inline commands: a Docker Compose installation guide for a single host, and a Kubernetes with Helm guide. Both are linked from cubeplex.ai/docs/deployment. The README does not reproduce the compose file or chart values, so treat those pages as the source of truth for images, configuration and secrets.

For local development the README is concrete. Prerequisites are Python 3.12+, Node.js 20+, pnpm 10+, and Docker, which it recommends for local services. Clone the repository and run the install target:

git clone https://github.com/cubeplexai/cubeplex.git
cd cubeplex
make install

make install installs backend and frontend dependencies according to the Makefile help text. The same Makefile exposes skills-restore, which restores vendored skills from skills-lock.json and wires symlinks, so a fresh clone can end up with skill directories that are linked rather than committed.

Run the two processes in separate terminals. The backend is started directly with Python, and the web UI with pnpm:

# Terminal 1 - API
cd backend && python main.py

# Terminal 2 - web UI
cd frontend && pnpm dev

The README lists the backend at http://localhost:8000 and the frontend at http://localhost:3000. Reaching the frontend on port 3000 is the first sign the pair is wired correctly; the README also notes that local setup needs backend env/config files described in CONTRIBUTING.md, so an unconfigured backend is the likely failure point before any agent runs.

Database schema is not created by make install. The Makefile has a separate target:

make backend-migrate

make backend-migrate runs backend Alembic migrations. Skipping it is a plausible reason for a backend that starts but cannot serve workspace data.

Where CubePlex is the wrong choice

The licence is the first thing to check and the hardest to resolve from the repository alone. The GitHub metadata reports NOASSERTION, and the repository contains a LICENSE file plus a CLA.md and a THIRD_PARTY_NOTICES.md. NOASSERTION means the platform could not classify the licence automatically; it does not mean there is no licence, and it certainly does not mean permissive. If your organisation has a policy against copyleft or against custom terms, read LICENSE directly before you build anything on top of it. Nothing in the README substitutes for that.

Operationally, CubePlex is infrastructure. It expects Docker or Kubernetes, a database, migrations, and configuration for every model provider and MCP server you connect. A developer who wants an agent on a laptop for a one-off script will spend more time on deployment than on the task. The README's own development path needs two terminals, a migration step and env files before the UI is useful.

The trust boundary is the second limit. Because external providers and MCP servers sit outside it, CubePlex cannot make a third-party connector safe. Granting a tool per workspace controls which workspace can call it, not what the remote service does with the data. Teams in regulated environments should read the governance features as access control, not as data residency or provider assurance.

Finally, the README does not document rollback for a failed upgrade, and it does not state an upgrade procedure beyond pointing at the deployment guides. If you need a documented downgrade path before you commit, that gap is real.

How CubePlex differs from building on an agent framework directly

The closest alternative is composing your own stack from an agent framework such as CubeLoop, which CubePlex itself uses. That route gives you the runtime, multi-provider model access, tool execution, streaming and durable checkpoints, and nothing else. You would then write your own workspace model, your own memory scoping, your own role checks, your own sandbox lifecycle and your own web UI.

The difference is where the work sits. With a bare framework, persistence and multi-tenancy are your problem, and a sandbox that survives restarts is a design you build. With CubePlex, those are product features: personal, workspace and org-scoped memory; organisations, workspaces and roles; per-workspace tool grants; and sandboxes with persistent storage. The cost is that you accept CubePlex's opinions about how workspaces, skills and memory are structured, and you operate its backend and frontend images.

A second alternative is a hosted agent platform, where the workspace model and governance may be similar but you do not run the infrastructure. CubePlex's answer is self-hosting on Docker Compose or Helm, with the same images in both modes. Choose the hosted route when you cannot operate a database and a cluster; choose CubePlex when the deployment has to live inside your own network.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-17. Release history in the metadata shows v0.8.0 on 2026-09-16, v0.7.2 on 2026-09-07 and v0.7.1 on 2026-09-02. That cadence is fast, and the version numbers are still in the 0.x range, which is the honest signal here: interfaces and deployment assets can change between minor releases.

Upgrade cost is therefore dominated by migrations and deployment assets, not by the application code you write. The Makefile exposes make backend-migrate for Alembic migrations, and the deploy/ directory holds both Docker Compose and Kubernetes/Helm assets, so a version bump can touch schema, compose files and chart values. The README does not describe a rollback procedure for a failed migration or a failed chart upgrade. Plan for a database backup before running migrations, and read the release notes for the version you are moving to.

On licensing, the practical point is that NOASSERTION blocks automated compliance checks. The repository carries LICENSE, CLA.md and THIRD_PARTY_NOTICES.md, and the README does not summarise their terms. Whether you can redistribute a modified CubePlex, or offer it as a service, depends on text you have to read yourself; this article is not legal advice and cannot classify the licence for you.

Editorial conclusion

Adopt CubePlex if you need agents shared across a team with workspace-scoped memory, governed tool access and sandboxes whose files survive restarts, and you are willing to run the stack yourself on Docker Compose or Helm. Do not adopt it if you want a single-user chat client, a managed SaaS with no infrastructure, or a project with a conventional open source licence, since the repository ships a LICENSE file marked NOASSERTION. Verify first that your Python 3.12+, Node 20+ and pnpm 10+ toolchain matches the local development prerequisites, that make install completes, and that the deployment guide for your target platform actually covers the secrets and configuration your environment requires.

Frequently asked questions

Official sources

1. cubeplexai/cubeplex on GitHub
2. Issues
3. Project website
4. README
5. Releases