Why self-host Quivr on a VPS
Quivr organizes your knowledge into knowledge bricks (the brains) and uses a modern RAG pipeline built on Supabase (PostgreSQL + pgvector) for vector storage, a Python backend (FastAPI) and a Next.js frontend. The cloud version imposes its quotas and stores your data at the vendor; by hosting it on a VPS, you keep control of the Supabase database, the uploaded files and the LLM keys. This is especially relevant for an agency that wants an AI knowledge base shared between consultants, with authentication, without entrusting client documents to a third-party service and without an artificial usage cap.
Concrete benefits of self-hosting
- Storage of all your knowledge in your own Supabase instance
- Organization into several thematic brains with fine-grained access management
- Varied ingestion: PDF, DOCX, transcribed audio, web pages, text files
- REST API you can leverage to integrate Quivr into your in-house applications
- Free choice of LLM (OpenAI, Anthropic, local Ollama) with no imposed billing
- No question or storage quota dictated by a SaaS provider
Hardware and software prerequisites
Quivr is a multi-service stack (frontend, backend, worker, full Supabase, Redis). It is the most resource-hungry tool in this series component-wise. Plan for 4 vCPUs and 8 GB of RAM at minimum, 16 GB being comfortable if you add a local LLM, plus 20 to 30 GB of disk for the Postgres database, the embeddings and the files. On the software side: Docker and Docker Compose are mandatory (the stack depends on them), a domain with subdomains for the frontend and the API, and at least one LLM API key as well as an embeddings key. Good bandwidth makes ingesting large files easier.
Deploying Quivr with Docker Compose
Clone and configure the environment
On the VPS, run git clone https://github.com/QuivrHQ/quivr && cd quivr. Copy the example files: cp .env.example .env and fill in the keys (OPENAI_API_KEY, Supabase keys, JWT_SECRET_KEY).
Initialize Supabase
Quivr ships its own Supabase stack. Run the provided database migration to create the tables, the pgvector extensions and the RLS policies required to store the brains and the embeddings.
Start the full stack
Launch all the services with docker compose pull && docker compose up -d. The stack includes the FastAPI backend, the ingestion worker, Redis and the Next.js frontend. Check the status with docker compose ps.
Check the ingestion worker
File processing goes through an asynchronous worker. Monitor its logs (docker compose logs -f worker) during a first upload to confirm that chunking and vectorization complete without error.
Configure the reverse proxy and SSL
Map app.yourdomain.com to the frontend and api.yourdomain.com to the backend via Caddy or Nginx, each with its Let's Encrypt certificate. Make sure the frontend points to the public URL of the API in its .env.
Create the first account and test
Open the frontend, create an account via Supabase authentication, create a brain, upload a document and ask a question to validate the RAG chain end to end.
Watch the memory of the ingestion worker: large PDFs and audio files to transcribe can saturate the RAM and get the container killed by the OOM killer. Limit the upload size at the reverse proxy level (client_max_body_size under Nginx) and, if you ingest a lot, offload the embeddings to a dedicated service rather than processing everything on the default worker.
