LobeHub: Self-Hosted Agent Operations, Docker Deploy, and What the Docs Leave Open

The problem LobeHub targets: agents that cannot be operated as a team

The README opens with a blunt diagnosis: agents today are "one-off, task-driven tools" that lack context, live in isolation, and need manual hand-offs between windows and models. That is a fair description of how most people actually use LLM chat interfaces. You keep five browser tabs open, paste the same background into each one, and lose the thread when you switch models.

LobeHub's answer is a change of unit. It treats the agent, not the conversation, as the thing you manage. The README calls this "Agents as the unit of work" and frames the product as a Chief Agent Operator that "hires, schedules, and reports on your entire AI team." The target user is someone running several recurring tasks (research, drafting, triage) who wants them scheduled and reported on rather than manually re-prompted.

The audience is narrower than the marketing suggests. This is a self-hostable Next.js application with Postgres and Redis dependencies. If you want a chat window and nothing else, the operational surface here is larger than the payoff.

How LobeHub is put together: Next.js, Postgres, Redis, and a plugin layer

The repository is a Bun workspace with a Next.js application at its core. The package.json declares workspaces for packages/*, packages/business/*, e2e, apps/desktop/src/main, apps/share, and apps/workbench, and the build script chains several SPA builds (auth, workbench, share) before the Next.js build. That layout tells you the desktop app and the web app share the same source tree rather than being separate products.

Persistence is split. The Dockerfile sets DATABASE_DRIVER="node" and a DATABASE_URL pointing at Postgres in its build-time defaults, and .env.example carries a Redis block with REDIS_URL, REDIS_DATABASE, REDIS_USERNAME, REDIS_PASSWORD, REDIS_TLS, and REDIS_PREFIX. Redis is described as the store for cache and queue keys, so scheduled agent runs depend on it being up.

On top of that sits the extension layer. The README claims a library of "over 10,000 tools and MCP-compatible plugins," and the repository ships a plugins-related section in its table of contents. MCP compatibility is the part that matters architecturally: it means the tool surface is not fixed by LobeHub and can grow without a release.

One detail worth flagging: .env.example documents an SSRF protection toggle. SSRF_ALLOW_PRIVATE_IP_ADDRESS defaults to disabled, and SSRF_ALLOW_IP_ADDRESS_LIST lets you whitelist specific internal addresses. That is a sensible default for a hosted product and an inconvenience for anyone who wants agents to reach an internal service.

Installing LobeHub with Docker and running a first agent

The README lists two self-hosting paths: deployment to Vercel, Zeabur, Sealos, or Alibaba Cloud, and deployment with Docker. The repository also contains a docker-compose/ directory and a Dockerfile at the root, so the Docker path is the one with the most visible supporting files.

Start by copying the environment template. The .env.example file is the authoritative list of keys; do not invent variables beyond it.

cp .env.example .env

Then open .env and set at least the database and cache endpoints plus one provider key. The template shows the Postgres driver name and a Redis URL, and the OpenAI key is the provider example the file ships with.

DATABASE_DRIVER=node
DATABASE_URL=postgres://postgres:password@localhost:5432/postgres
REDIS_URL=redis://localhost:6379
OPENAI_API_KEY=sk-xxxxxxxxx

With the environment in place, bring the stack up. The repository provides a docker-compose directory for exactly this purpose; the README's Docker section is where the project documents the flow.

docker compose up -d

After the containers report healthy, open the app in a browser and create your first agent. The README describes the Agent Builder as the entry point: you describe what you need once and the setup applies auto-configurations. The README does not document the exact builder fields, so expect to read the UI rather than a spec.

If you prefer to run from source, the repository is a Bun workspace. The package.json declares a build script that chains the SPA builds and the Next.js build, and a separate build:docker script that sets DOCKER=true. The README's Local Development section is the place to check for the current dev command.

Where LobeHub gets in your way

The release channel is the first constraint. The most recent releases at the time of writing are v2.2.16-canary.4, v2.2.16-canary.3, and v2.2.16-canary.2, all published on 2026-08-29, and the default branch is named canary. The package.json version is 2.2.17, ahead of the published canary tags. If you pin to a tag, you are pinning to a canary build, and the README does not document a rollback procedure or a stable channel.

The licence is the second. The repository root contains a LICENSE file and the package.json declares "MIT", but the metadata supplied for this project lists the licence as unknown. Those two signals disagree. Anyone deploying this inside a company should read the LICENSE file directly rather than trusting either the badge row or the package metadata.

The third is the SSRF default. Private-IP access is off unless you set SSRF_ALLOW_PRIVATE_IP_ADDRESS=1 or enumerate hosts in SSRF_ALLOW_IP_ADDRESS_LIST. If your agents are supposed to query an internal wiki or a staging API, the default configuration will block them, and the warning in .env.example is explicit that enabling it is only for trusted environments.

Finally, the README is written as product copy. It describes capabilities (IM Gateway, Agent Groups, Pages, Schedule) in one line each and does not specify their limits: no concurrency ceiling for scheduled runs, no retention policy for agent memory, no statement of what happens when Redis is unavailable. Those are the questions to ask before you put real work on it.

LobeHub against LibreChat, Open WebUI, and Cherry Studio

The comparison people search for is LobeHub versus LibreChat, Open WebUI, and Cherry Studio. The difference is not the model list; all of them connect to multiple providers. The difference is what the product thinks it is managing.

LibreChat and Open WebUI are, in the way they present themselves, chat front ends: you bring keys, you get a conversation UI, and configuration is mostly about providers and auth. LobeHub's README pushes past that framing toward operations. It talks about hiring, scheduling, and reporting on agents, and about an IM Gateway that puts agents where you already chat. Agent Groups, which the README describes as assembling the right agents for a task and running them in parallel, has no direct equivalent in a single-conversation interface.

Cherry Studio is a desktop client, so the comparison is about deployment shape as much as features. LobeHub ships a desktop build (the repos include apps/desktop/src/main and .env.desktop) but its primary artefact is a server you host, which is what makes scheduling and multi-user collaboration possible at all.

The trade-off is honest: LobeHub asks for Postgres and Redis and a container runtime, where a desktop client asks for a download. If your need is one person talking to one model, the extra infrastructure buys you nothing.

Maintenance cadence, upgrade cost, and licence checks

The last push to the repository was on 2026-08-29, and the three most recent releases were all published that same day, hours apart. That is a fast canary cadence, not a slow stable one. Expect to re-read .env.example on upgrade, because new keys appear there: the SSRF and Redis blocks are the kind of configuration that grows between versions.

Upgrade cost is dominated by the database. The Dockerfile wires DATABASE_DRIVER and DATABASE_URL, and the repository root carries drizzle.config.ts, which means schema changes are managed through Drizzle migrations. The README does not describe a migration command or a downgrade path, so the practical advice is to snapshot the Postgres volume before pulling a new image, and to keep REDIS_PREFIX namespaced if you share a Redis instance with anything else.

On licensing: the package.json says MIT and a LICENSE file exists at the root, but the project metadata lists the licence as unknown. MIT would be permissive, but do not take the package.json field as the final word. Open the LICENSE file, and if you are embedding LobeHub in a commercial product, have someone who is qualified read it. Nothing here is legal advice.

There is also a sponsorship section and a set of "More Products" links in the README, which is normal for a project with a hosted counterpart at lobehub.com. If you self-host, check whether the features you want are gated to the cloud offering before you plan around them.

Editorial conclusion

Adopt LobeHub if you want a self-hosted agent workspace with MCP plugins and an IM gateway, and you are comfortable running a canary channel that gets multiple pushes per day. Do not adopt it if you need a frozen, documented release line with a rollback procedure, because the README does not describe one. Before you commit, verify the LICENSE file in the repository root, check that your Postgres and Redis are reachable from the container, and confirm which environment variables your chosen model provider requires.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes