Building a RAG Chatbot over Internal Documentation with Self-Hosted Flowise and pgvector on PaaS

Retrieval-augmented generation is the practical form of the enterprise chatbot: instead of hoping a model knows your runbooks, you find the relevant pages first and hand them to the model with the question. Flowise makes the pipeline a diagram rather than a codebase. This post follows a developer building one over an internal knowledge base with Flowise on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, with the vector store on a PostgreSQL node beside it.

The developer works at a managed-services company we will call Greyfriar IT, whose support engineers search 4,000 pages of runbooks, vendor notes and past incident reports. The Flowise AI package installs the Node.js application with persistent storage and login credentials; the developer adds a PostgreSQL node with the pgvector extension from the topology wizard for the embeddings.

The shape of the pipeline

A RAG flow has two halves. Ingestion: load documents, split them into chunks, compute an embedding vector for each chunk, store the vectors with the chunk text and metadata. Query: embed the user's question, find the nearest chunks, build a prompt containing them and the question, send it to a chat model, return the answer with citations. Flowise represents both as nodes on a canvas: loaders, text splitters, an embeddings model, a vector store, a retriever, a prompt, a chat model and a chain or agent that wires them.

Why pgvector on a platform PostgreSQL node

Flowise supports many vector stores. The developer picks pgvector, the PostgreSQL extension, for reasons that are about operations rather than benchmarks. The platform's PostgreSQL node is a managed container with vertical scaling, the Database Backup/Restore add-on and the PostgreSQL SSL/TLS add-on, so the embeddings are backed up and encrypted in transit with tools the team already runs. It lives in the same environment group as Flowise and is reached over the internal network by hostname. And PostgreSQL holds the metadata (source page, last updated, product line) in ordinary columns, so filtered retrieval, "only pages about the backup product", is a SQL WHERE clause the Flowise node exposes.

She enables the extension with CREATE EXTENSION vector; from the platform's Web SSH console, and Flowise's Postgres vector store node creates the table on first use.

Ingestion with the Document Store

Flowise's Document Store separates ingestion from the chat flow, which is what makes the bot maintainable. The developer creates a store, adds loaders for the runbook wiki's export (Markdown files on the Flowise node's persistent storage, uploaded through the dashboard's file manager) and for the incident tracker's API, and a recursive character splitter at about 800 tokens with 100 of overlap. The embeddings node points at the team's chosen embedding model. She runs the upsert: 4,000 pages become about 31,000 chunks and vectors in the PostgreSQL node. Re-running the store later upserts only what changed, so a weekly refresh is a scheduled API call, not a rebuild.

The chat flow, and citations that engineers trust

The query flow is a conversational retrieval chain: a retriever over the pgvector store returning the top six chunks, a prompt that instructs the model to answer only from the provided context and to say so when the context does not contain the answer, and a chat model. The developer turns on Flowise's return source documents option so every answer carries the page titles and URLs of the chunks it used. Support engineers told her in testing that the citations mattered more than the prose: an answer they can click through to verify is an answer they use.

For the chat model, Greyfriar starts with a hosted API and keeps the option of a self-hosted model open: Flowise has nodes for Ollama and OpenAI-compatible endpoints, so pointing the same flow at a model running on one of MassiveGRID's GPU dedicated servers is a node swap, not a rebuild.

Exposing it: API and widget

Every Flowise chat flow is an HTTP endpoint: POST /api/v1/prediction/<chatflow-id> with a JSON body containing the question and an optional session id for memory, protected by a Flowise API key. The developer wires that into the support team's ticketing tool with a small webhook. For the internal portal she uses Flowise's embed snippet, a script tag that renders a chat bubble bound to the flow, with the domain allowlist set so the widget answers only from Greyfriar's own pages.

curl -X POST https://flowise.greyfriar.example/api/v1/prediction/CHATFLOW_ID \
  -H 'Authorization: Bearer FLOWISE_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"question": "How do we rotate the backup encryption key?", "overrideConfig": {"sessionId": "ticket-48213"}}'

What it runs on

Flowise is a Node.js process; at Greyfriar's scale (a few hundred questions a day) it idles at 3 to 4 cloudlets and rises to 8 or so during ingestion (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU). The PostgreSQL node with 31,000 vectors of 1,536 dimensions holds a few hundred megabytes and sits at 4 to 6 cloudlets. The platform's vertical scaling allocates both by the hour. Together they average roughly 10 cloudlets, about $25 a month at MassiveGRID's published $0.003372 per cloudlet-hour before discounts, plus the model API's own charges. The developer's honest observation is that the model API costs more than the hosting, and that the hosting is the part that holds the company's runbooks, which is why it is self-hosted in the Frankfurt region and not on someone else's canvas.

Frequently Asked Questions

Does Flowise include a language model?

No. Flowise orchestrates models you connect: hosted APIs, or self-hosted models through Ollama or any OpenAI-compatible endpoint. Embeddings work the same way. The package self-hosts Flowise, your flows, credentials and data; the model is your choice.

Can I use Flowise's default SQLite database for production?

Flowise stores flows, credentials and chat history in SQLite by default on the persistent volume, which is fine for a small team. For production, set the database environment variables to point at a PostgreSQL node (the same one that holds pgvector, or a separate one) so Flowise's own data is backed up by the database add-on and survives container redeploys cleanly.

How do I keep the bot from answering outside the runbooks?

Prompt instructions to answer only from the provided context, a similarity threshold on the retriever so weak matches are discarded, and returning source documents so users can see what the answer rests on. Test with questions you know are not covered and confirm the bot says so.