The outcome

Give authenticated users a recoverable AI workspace without exposing provider keys, registrations, conversations, files, or administration surfaces.

LobeHub is a Open-source AI workspace centered on LobeChat, with multi-provider chat, agents, knowledge bases, files, plugins, MCP, and self-hosting. Using multiple AI providers in one workspace, building reusable assistants with files and knowledge, and operating a private multi-user LobeChat service with controlled extensions. This guide narrows that broad capability into one repeatable outcome, with checkpoints that keep the source material and your judgment in the loop.

Before you begin

Set the boundary before the tool starts.

Choose one real task, identify who will use the result, and decide what evidence or test will make the result acceptable. Gather only the source material needed for that task. If the work contains confidential, personal, regulated, or client-owned information, confirm that the platform and account are approved before sharing it.

Troiana principle

AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.

Step by step

A workflow you can repeat.

  1. 01

    Define users, tenants, domain, regions, providers, data classes, authentication, registration, database, vector and object storage, retention, SLO, backup, and incident ownership.

  2. 02

    Pin reviewed container images and configuration, deploy PostgreSQL with vector support, private object storage and supported SSO, use HTTPS, and restrict databases and administration to internal networks.

  3. 03

    Store provider and application secrets outside images and source, disable open registration, assign least privilege, separate environments, set resource limits, and redact logs and traces.

  4. 04

    Test login and logout, tenant and file isolation, provider-key leakage, uploads, knowledge retrieval, failed storage, database migration, restore, dependency outage, rate limits, and account removal.

  5. 05

    Canary pinned updates, back up before migrations, verify restore on a separate instance, monitor access and spend, rotate secrets, and delete retired files, sessions, buckets, volumes, and accounts.

Working standard

What good use looks like.

  • Never expose an unauthenticated instance.
  • Back up before every migration.
  • Test tenant isolation and restore.

Self-hosting the interface does not make remote model, embedding, search, storage, sync, or plugin traffic local. A database deployment adds authentication, database, vector, object-storage, migration, backup, and patch responsibilities. Never expose an unauthenticated instance or provider key; isolate tenants and knowledge, vet plugins and MCP servers, restrict registration and networks, redact observability, and test restores before upgrades.

Official references

Check the current product documentation.

Features, plan limits, availability, and data controls change. These official pages are the starting points used for this collection.