LobeChat — Multi-user, Server Database Mode

The multi-user variant of LobeChat / LobeHub with real accounts and server-side persistence: conversations, agents, files, and per-user API-key vaults live in Postgres instead of browser localStorage. Deploy once, invite your team, each person signs in with email and password — no external auth service to sign up for.

This template fixes the boot problems that plague the official database-mode deployment: the right Postgres image (ParadeDB with pgvector + pg_search, both required by LobeChat's migrations), bundled S3 storage with automatic bucket creation (the chat pipeline requires S3), and an env-sanitized launcher that stops LobeChat's strict validation from 500-ing on empty optional variables.

What's provisioned

lobehub — the LobeChat web app, built from lNamelessl/lobechat-railway-template (pinned lobehub/lobehub:2.2.16 + boot fixes), public domain included, healthchecked on /api/version. Runs database migrations automatically on boot.
postgres — paradedb/paradedb:pg17 with an attached volume. Plain Postgres or pgvector-only images fail LobeChat's migrations (CREATE EXTENSION pg_search).
minio — S3-compatible storage for file uploads and knowledge bases, with an attached volume. The lobe bucket is created automatically on first boot.

All credentials (POSTGRES_PASSWORD, MINIO_ROOT_PASSWORD, KEY_VAULTS_SECRET, AUTH_SECRET) are generated per deployment — the deploy form asks for nothing.

After you deploy

Open the generated lobehub domain — you'll land on the sign-in page. Click Sign up now and register with any email and password. That's the whole auth setup.
The chat UI works immediately, but model calls need a key: Settings → Language Model → enable your provider (OpenAI, Anthropic, Z.ai, Ollama, …) and paste the API key. No redeploy needed.
Optional hardening: set AUTH_ALLOWED_EMAILS on the lobehub service to restrict who can register, or configure SSO (AUTH_SSO_PROVIDERS + provider credentials).
Optional: to attach images inside chat conversations, give minio a public Railway domain and point S3_ENDPOINT/S3_PUBLIC_DOMAIN at it. Avatars, file uploads, and the knowledge base work with the bundled private endpoint as-is.

Verified behavior

Fresh deploys reach a working sign-in screen with zero user configuration.
Accounts, conversations, and uploaded files survive restarts and redeploys (Postgres + MinIO volumes).
Rotating AUTH_SECRET signs sessions out but keeps data; never rotate KEY_VAULTS_SECRET once users have saved API keys — the vault is encrypted with it.

Cost expectations

Roughly $5–10/month on Railway usage-based pricing (three always-on containers plus volumes). Most of the spend is Postgres's memory floor and the app container; traffic on a small team is negligible.

Troubleshooting

502 right after deploy — first boot runs migrations; the healthcheck allows up to 5 minutes. Deploy logs should show ✅ database migration pass.
extension "pg_search" is not available — the postgres service isn't ParadeDB. Restoring the paradedb/paradedb:pg17 image fixes it.
S3 environment variables are not set completely — the minio service is stopped or the S3_* variables on lobehub were removed.
Provider errors when chatting — no LLM key configured yet; add one in Settings.
Sign-in loops after you rotated secrets — expected if AUTH_SECRET changed; sign in again.

Deploy and Host

About Hosting

Hosting LobeChat through this template gives you the server database deployment on Railway: the Next.js app container, a ParadeDB Postgres 17 with vector and full-text extensions, and MinIO object storage, each with persistent volumes on a private network. Railway generates the public domain, TLS, and per-deployment secrets; the app wires itself together through referenced variables (DATABASE_URL, S3_ENDPOINT, APP_URL) so there is nothing to copy-paste. The app image is pinned to a specific LobeHub release — upgrades are a one-line tag change in the repo's Dockerfile, and migrations run automatically on boot.

Why Deploy

Deploys land on a working sign-in screen with zero configuration — accounts work out of the box.
Multi-user from day one: each member gets their own conversations, agents, and encrypted API-key vault.
Data actually persists: Postgres volumes keep users and chats across restarts, redeploys, and upgrades — unlike the client-side (browser storage) variant of LobeChat.
Self-hosted privacy: your conversations and keys stay in your own Railway project.
Known-good component choices — ParadeDB for pgvector+pg_search, bundled S3 with auto-created bucket — instead of debugging each requirement after a failed first boot.

Common Use Cases

A shared ChatGPT-style workspace for a team or family, with individual logins and per-person API keys.
A private, persistent AI chat you can reach from any device without exporting/importing browser data.
Knowledge-base / file-upload workflows (RAG over your documents) without external S3 accounts.
A base to customize: fork the repo, change the pinned version or add SSO, and redeploy.

Dependencies for

Deployment Dependencies

No deploy-form inputs — all credentials are generated at deploy time. Behind the scenes the template depends on:

The public GitHub repo lNamelessl/lobechat-railway-template (app Dockerfile: lobehub/lobehub:2.2.16, start-time bucket creation, env sanitizer).
Docker Hub images paradedb/paradedb:pg17 (postgres + pgvector + pg_search) and minio/minio (S3).
Per-deployment generated secrets: POSTGRES_PASSWORD, MINIO_ROOT_PASSWORD, KEY_VAULTS_SECRET, AUTH_SECRET.
Referenced variables resolved at deploy: DATABASE_URL (from postgres), S3_ENDPOINT and S3_SECRET_ACCESS_KEY (from minio), APP_URL (from the generated public domain).
Post-deploy, users bring their own LLM API key (OpenAI, Anthropic, Z.ai, Ollama, …) via in-app Settings.