LobeHub

Settings → Data Storage → Export Data gives an immediate JSON file, and Import Data restores it on any LobeHub v2 instance. Restoring off the provider's systems, though, means deploying the self-hosted stack first (setup script, Docker Compose, generated secrets, account creation), which is not a single owner action.

• Migrate from v1.x Local Database to v2.x (export/import steps)
• Advanced storage settings (export/import UI)
• Docker Compose deployment guide

DATA_EXPORT_CONFIG exports only settings, installed plugins, agents, providers/models, sessions, topics, threads and messages. Files, knowledge bases, embeddings with their chunks, user memory, agent documents, cron jobs/tasks and skills are commented out or absent, and the migration docs say API keys and secrets are not carried over.

• DataExporterRepos table list
• Topic docs: conversation export is not a complete backup
• Migration guide: what does not migrate

The exported data runs on the self-hosted runtime under an Apache-2.0-based licence, with no licence key or provider account. Non-core capabilities degrade without LobeHub services, though: the agent/skill/MCP market defaults to market.lobehub.com (URL overridable, but no public server), and the Agent Gateway image ships from a public repo with no licence file.

• LICENSE (LobeHub Community License)
• Market service base URL
• Self-host docker-compose (gateway image)
• lobehub-gateway repository (no licence)

Owners can configure many providers, including local Ollama, LM Studio and vLLM. Several capabilities depend on particular hosted models, though (image/video generation, TTS/STT, embedding-backed knowledge base), and the docs publish no minimum model contract. The glossary also says Custom API keys are 'Available on paid plans', which conflicts with the pricing table.

• Model providers docs
• Glossary (Custom API on paid plans)
• Pricing

The Terms say 'Upon termination, You will immediately lose the right to access or use the Services' and give no post-termination export window or shutdown plan. Since v2 the product is 'cloud-first' and has no local database, so no current copy stays with the owner by default.

• Terms of Service
• Migration guide (cloud-first architecture)

Exported state is plain JSON whose schema is public in the open-source Drizzle definitions. Memory, files, knowledge bases, documents and trace snapshots can be read only through the provider-operated service, and the credential vault is encrypted with a server-held KEY_VAULTS_SECRET.

• Database schemas
• Basic environment variables (KEY_VAULTS_SECRET)

Production runs store trace snapshots by default, including context-engine output with the system messages and toolset, and the owner can read them through the documented `lh trace` CLI. Cloud also reads provider-controlled Vercel Edge Config feature_flags and assistant allow/deny lists server-side, which the owner cannot see.

• Snapshot store default (S3 tracing in production)
• Agent trace router
• Edge Config types (feature_flags)

The Privacy Policy keeps personal data 'only for as long as is necessary' with no durations, and gives no retention table for backups, trace snapshots or usage data. Behavioural analytics profiles (PostHog person_profiles 'always') are not visible to the owner.

• Privacy Policy
• Analytics provider wrapper

No paid placement was found. Recommended skills are a hard-coded first-party/partner list visible in source and removable. Marketplace 'Featured' badges, the 'Agent Market highlights' plan feature and the non-disableable official provider in Cloud are not explained, and no binding no-steering commitment exists.

• Recommended skills list
• Official provider cannot be disabled
• MCP marketplace
• Pricing (Agent Market highlights)

Tool calls with their arguments are stored as messages, and task runs keep run records. Trace recording is explicitly best-effort (a store failure only logs to the server console), and no owner alert for failed recording is documented. No public evidence shows that provider-side automations (memory extraction, self-iteration, agent-signal runs) or staff actions are recorded to the owner (G12).

• Snapshot store (best-effort tracing)
• Agent Tasks docs (run records)

Messages, operations and trace snapshots are ordinary database rows and S3 objects. No hashing, signing or external anchoring is documented or visible in the schema.

• Message schema

The built-in tools examined have no API to delete the agent's own messages or topics (the message tool's deleteMessage targets external platforms). This protection is by convention only, however: on a desktop execution device the local-system tool's runCommand gives the agent a shell, where an authenticated `lh` CLI offers `message delete`.

• Message tool manifest
• Local-system tool (runCommand)
• CLI message delete command

The open repository ships stub 'business' slot packages (ENABLE_BUSINESS_FEATURES = false; AccountDeletion returns null) that the docs describe as 'Cloud-only business logic'. The Cloud offering therefore runs closed components, including billing, account deletion and the official provider. The licence also requires a commercial licence to distribute derivative works.

• Business const stub
• AccountDeletion stub
• Folder structure (cloud-only business logic)
• LICENSE

Inside LobeHub the agent's identity is a provider account. On messaging channels it acts through bot accounts the owner registers and controls (e.g. a Telegram bot token), which LobeHub cannot revoke. Attribution is per channel only.

• Telegram channel docs

Some state is versioned: persona versions with restore, document history and expertise rule revisions. Agent instructions, tools, permissions, model and settings have no change log, attribution or rollback.

• User memory router (persona versions)
• Expertise router (rule revisions)

The owner can edit each agent's system prompt and import their own skills. Built-in tool system roles and the context-engine injectors (memory, workspace, identity context) are fixed in Cloud and can be changed only by modifying source when self-hosting (G3).

• Context engine providers
• Connectors docs (import your own skills)

Identities, contexts, activities, experiences and preferences are itemised with update and delete procedures, and the docs describe edit/delete. The persona summary, which is injected into context, can only be restored to earlier versions: the persona 'editor' modal has no save handler and the router has no update procedure.

• Memory docs
• User memory router
• Persona editor (no onConfirm)
• UserMemoryInjector

The owner can add custom MCP servers and import skills from GitHub/URL/ZIP without review, and can uninstall or disable built-in tools per agent. Hidden system tools (e.g. verify, acceptance-evidence) are not listed for removal, and the docs note that 'some system capabilities offer different options'.

• Built-in tool registry
• MCP marketplace docs
• Connectors docs

Owners can switch the approval mode (manual, allow-list, auto-run). Tools with the provider-set 'always' intervention policy and the security blacklist cannot be overridden by the owner.

• Intervention types

In Cloud, LobeHub deploys continuously and applies server-side Edge Config feature flags, and owners cannot pin runtime versions or defer changes. Self-hosting allows image pinning, but moving to it means the lossy migration graded in P2.

• Edge Config client
• Changelog

Messenger channels have per-sender allowlists, and tools can be scoped per agent. No per-recipient contact limits or network egress policy is documented. Background task and bot runs use approvalMode 'headless' (all tools auto-execute), and the agent-management tool can update any agent's system prompt and plugins without approval by default, so the agent can change its own controls.

• Agent management tool manifest (updateAgent)
• Intervention types (headless mode)
• Telegram channel docs (allowlists)

Owners can set Allow/Ask/Deny per tool, plus manual or allow-list approval modes. Task runs and messenger-bot runs force approvalMode 'headless', so Ask gates are skipped on those paths.

• Task runner (headless)
• Bot bridge (headless)
• MCP marketplace docs (Allow/Ask/Deny)

The foreground generation can be stopped. The docs say scheduled automation is disabled per task, and in-progress runs must be checked 'separately'. No single global stop is documented.

• Agent Tasks docs (disabling automation)

The 'Send Anonymous Usage Data' toggle defaults on and gates only product-usage events. When the deployment configures PostHog, it identifies users by email and name and captures page views regardless of the toggle, so that flow cannot be switched off. The Privacy Policy allows sharing with 'business partners … to offer You certain products, services or promotions', does not address staff access, and gives no notice commitment for legal disclosure.

• Default settings (telemetry: true)
• identify() call
• Analytics provider wrapper
• Privacy Policy

Provider API keys, connector authorisations and issued API keys are listed in Settings and removable one by one. The docs note that 'disabling does not revoke account authorization', and no policy says where credentials are held, limits provider use, or deletes copies on revocation.

• Connectors docs
• Privacy Policy

The Cloud UI offers account deletion with a 72-hour cooling-off period, after which 'your account data will be permanently deleted', while registration and deletion records are retained. Backups, third-party copies and a completion confirmation are not addressed, and the mobile policy points to a support email.

• Account deletion UI strings
• Privacy Policy