Skip to main content

Flowise on a VDS: a visual builder for AI agents

AI Agents on VPS · 19.04.2026 · 4 min read
Illustration for “Flowise on a VDS: a visual builder for AI agents”

What is Flowise?

Flowise is an open-source platform for visually building LLM applications. It uses a concept of nodes and connections (like LangFlow), but is simpler to configure and has a larger library of ready-made components.

Installing via npm

npm install -g flowise
flowise start --PORT=3000 --HOST=0.0.0.0

Installing via Docker

docker run -d \
  --name flowise \
  -p 3000:3000 \
  -v flowise:/root/.flowise \
  --restart always \
  flowiseai/flowise

Connecting Ollama in Flowise

  1. Open Flowise: http://IP:3000
  2. Create a new Chatflow
  3. Drag in the ChatOllama node
  4. Set the Base URL: http://host.docker.internal:11434
  5. Select a model from the list (llama3.2, mistral, etc.)

Ready-made templates

  • Conversational Chain — a basic chatbot with memory
  • QA Retrieval Chain — question and answer over documents
  • ReAct Agent — an agent with tools
  • SQL Database Chain — working with databases
Flowise vs n8n: Flowise is better for AI-specific tasks (RAG, agents), while n8n is better for general automation with AI components. Use both together for maximum flexibility.

Setting up authentication

flowise start \
  --USERNAME=admin \
  --PASSWORD=securepassword \
  --PORT=3000

Common setup errors

ChatOllama does not see the model

Calling the node produces an error like this:

Error: model "llama3.2" not found, try pulling it first

Flowise does not download models itself — it only talks to an already running Ollama at the given Base URL. Pull the model in advance with ollama pull llama3.2 on the machine the Base URL points to.

Flowise in a container cannot reach Ollama on the host

connect ECONNREFUSED 127.0.0.1:11434

The cause is the same as in other containerized scenarios: localhost inside a container is the container itself. Replace the address with http://host.docker.internal:11434, or run Flowise with --network=host so the container uses the host's network stack directly.

All Chatflows disappeared after a container restart

Configured flows disappear when the container is recreated if the volume was not mounted explicitly. Check that the run command includes -v flowise:/root/.flowise — without it, state lives only inside the container and is lost when it is removed.

A CORS error when calling the API from outside the browser

Access to fetch at 'http://IP:3000/api/v1/prediction/...' has been blocked by CORS policy

By default Flowise restricts the origins allowed to call its API. If a frontend on another domain needs to call the flow directly, set the CORS_ORIGINS environment variable to a list of allowed domains when starting the container. Without it, the browser silently blocks the request before it ever reaches the server, and the developer console only shows a network error with no detail from Flowise itself.

Flowise, n8n, and LangFlow: which to choose

All three tools build LLM pipelines visually, but they differ in what scale and team they suit best.

CriterionFlowisen8nLangFlow
FocusLLM pipelines and RAGGeneral automationLLM pipelines
Library of ready componentsLargeMedium (for AI)Medium
Learning curveLowLowMedium
Ready integrations beyond AI tasksMinimalHundreds of servicesMinimal

When Flowise is not a good fit

A visual editor simplifies building RAG pipelines and agents, but it does not replace a full automation platform or a programming language where the task genuinely needs one. Draw the line by logic complexity, not by tool preference.

  • You need integrations with dozens of external services (CRM, task trackers, email) — n8n has far more ready-made nodes for that
  • Agent logic needs to be versioned and tested like regular code — a visual graph does not fit well into CI
  • The team writes Python and wants full control over prompts and chains — it is simpler to use LangChain directly
  • The project must run without a single point of failure in a UI server — a plain FastAPI service is cheaper for a simple API
  • You need a versioned change history of the flow with rollback — git over a flow's JSON export reads poorly

Verifying the result

After assembling the flow, test it the same way you would test a regular API endpoint.

  1. Open the Chatflow and send a test message through the built-in chat widget
  2. Check the ChatOllama node's log tab — it shows which prompt went to the model and what it returned
  3. Confirm that the Chatflow and API keys survived a container restart
  4. Test the flow's API endpoint directly
  5. Send a request from the frontend's domain and confirm CORS does not block the call
curl -X POST http://IP:3000/api/v1/prediction/<flow-id> \
  -H "Content-Type: application/json" \
  -d '{"question": "Hello"}'

Related: no-code automation with AI — n8n on a VDS, custom Python code — LangChain on a VDS, a local backend for models — Ollama on a VDS.

Was this article helpful?
← Back to Knowledge Base Ask Support