Self-hosting
Requirements and sizing
What to run it on.
Minimum
| CPU | 4 cores |
| RAM | 8 GB |
| Disk | 20 GB, plus room for your content |
| Software | Docker with Compose v2, or Kubernetes |
That is enough for a small team and a few connectors.
Sizing up
The two things that grow are the database and the indexing work.
| Content | RAM | Disk | Notes |
|---|---|---|---|
| Small — a few repositories, a wiki | 8 GB | 20 GB | Defaults are fine |
| Medium — most of a company | 16 GB | 100 GB | Give PostgreSQL more memory |
| Large — hundreds of thousands of documents | 32 GB+ | 250 GB+ | Consider a GPU for indexing |
The first sync is the heaviest moment. Afterwards, only changes are processed and load drops sharply.
GPU
Optional. Indexing runs on CPU everywhere and works fine. On a large corpus a single mid-range GPU makes the initial sync substantially faster. Routine syncing rarely needs one.
Putting it on a network
The quickstart binds to 127.0.0.1, which is correct for one machine and
wrong for anything else. Before colleagues or agents connect:
- Put it behind a reverse proxy with TLS. Agents send API keys on every request; those must not cross a network in plain text.
- Set
BASE_URLto the public address. Agent sign-in breaks otherwise — the URLs LensHub advertises must be the ones clients actually reach. - Set
COOKIE_SECURE=true, so browser sessions are HTTPS-only. - Set
CORS_ORIGINto your web address. - Set
TRUST_PROXY_HEADERS=trueonly if your proxy overwritesX-Forwarded-For. If it appends instead, leave this off — otherwise clients can spoof their address and evade rate limiting.
Air-gapped
LensHub can run with no internet access:
- Mirror the container images to a registry you can reach
- Indexing is already local and needs no external calls
- Point chat at a self-hosted model
Connectors still need to reach whatever they sync from.