Build a no-code AI workflow with Flowise on a VPS

You have a VPS, an OpenAI API key, and a vague idea for a chatbot. The last thing you want is to spend a weekend wiring up LangChain in Python just to test the concept. Flowise solves exactly that: a drag-and-drop interface where you build LLM chains, connect tools, and ship a chat API, all without writing backend code. On a Linux VPS with Docker, the whole thing runs in about ten minutes. This guide walks through installing Flowise on Ubuntu 24.04, connecting it to an LLM, building a real workflow, and exposing it safely.

• Key takeaways
• Flowise runs as a single Docker container; the official image is flowiseai/flowise.
• The default port is 3000; put Nginx with HTTPS in front of it for anything beyond local testing.
• A chatflow gets its own API endpoint at /api/v1/prediction/{id}, ready for your frontend to call.
• Store API keys in the container environment, never in the flow JSON itself.

Prerequisites

• A VPS running Ubuntu 24.04 LTS (Debian 12 works too; commands differ slightly for apt vs dnf on AlmaLinux).
• Root access or a user with sudo privileges.
• Docker and Docker Compose v2 installed.
• An API key from an LLM provider: OpenAI, Anthropic, or a local model via Ollama.
• A domain name pointing to your VPS if you want HTTPS, which you should for production.

Why Flowise, not a hand-rolled LangChain script

LangChain is powerful, but it is a library, not a product. You write code for every chain, every prompt template, every tool call. Flowise wraps that same ecosystem in a visual editor. You drag a language model onto a canvas, connect it to a prompt, add a vector store for retrieval, and the graph is the program. The generated JSON behind the canvas is portable, so you can version it or import it into another instance.

For a solo developer or a small team, this changes the economics of prototyping. A workflow that would take a day of Python takes an hour in Flowise. And when the prototype needs to become a product, Flowise exposes the flow as a REST API, so your existing frontend talks to it like any other service. You are not locked into a SaaS dashboard either, self-hosting on a VPS with full root access keeps the data and the orchestration under your control.

Step 1 - Install Docker and Docker Compose

Ubuntu 24.04 ships with Docker in its repositories, but the version can lag. Install from the official Docker apt repository to get the current release, including Compose v2.

# Add Docker's official GPG key and repository
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Enable the service so containers restart on reboot, and confirm the Compose plugin is present.

sudo systemctl enable --now docker
docker compose version

Docker Compose version v2.29.1

If you are on AlmaLinux or Rocky, swap apt for dnf and install docker-ce from the CentOS repository. The docker compose syntax is identical everywhere.

Step 2 - Deploy Flowise with Docker Compose

A compose file keeps the configuration reproducible. Create a directory for Flowise and write the file there.

mkdir -p ~/flowise && cd ~/flowise
nano docker-compose.yml

services:
  flowise:
    image: flowiseai/flowise:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - PORT=3000
      - FLOWISE_USERNAME=${FLOWISE_USERNAME}
      - FLOWISE_PASSWORD=${FLOWISE_PASSWORD}
      - DATABASE_PATH=/root/.flowise
      - APIKEY_PATH=/root/.flowise
      - SECRETKEY_PATH=/root/.flowise
      - LOG_PATH=/root/.flowise/logs
      - OPENAI_API_KEY=${OPENAI_API_KEY}
    volumes:
      - ~/.flowise:/root/.flowise
    command: /bin/sh -c "pnpm start"

The bind to 127.0.0.1 is deliberate. Flowise has no built-in TLS, so exposing port 3000 directly to the internet means anyone who finds it gets a login prompt over plain HTTP. Nginx in front of it handles both encryption and access control. Set the credentials in an environment file so they are not part of the compose file.

nano .env

FLOWISE_USERNAME=admin
FLOWISE_PASSWORD=change-this-strong-password
OPENAI_API_KEY=sk-your-key-here

docker compose up -d
docker compose logs -f flowise

Wait for the log line that says the server is running, then verify the container is healthy.

docker compose ps
curl -s http://127.0.0.1:3000/api/v1/ping

{"status":"ok"}

Step 3 - Put Nginx with HTTPS in front of Flowise

Running Flowise behind a reverse proxy is the difference between a toy and a service. Install Nginx, request a certificate with Certbot, and proxy the traffic to port 3000.

sudo apt install -y nginx certbot python3-certbot-nginx

Create a server block for your domain. The key parts are the proxy headers, which preserve the original client information, and the WebSocket upgrade, which Flowise uses for streaming responses.

sudo nano /etc/nginx/sites-available/flowise

server {
    listen 80;
    server_name flow.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

sudo ln -s /etc/nginx/sites-available/flowise /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Now request the certificate. Certbot reads the server block, obtains the cert, and rewrites the config to redirect HTTP to HTTPS.

sudo certbot --nginx -d flow.example.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/flow.example.com/fullchain.pem

Verify the whole chain from the outside. If you see the Flowise login page over HTTPS, the proxy is working. For a brand new domain, SSL certificates from a provider like GoGetSSL can be installed manually if you prefer not to use Let's Encrypt, but Certbot has the advantage of automatic renewal.

curl -I https://flow.example.com

HTTP/2 200

Step 4 - Build your first chatflow in Flowise

Log in to Flowise at your domain. The interface shows a canvas on the left and a palette of nodes on the right. The first workflow worth building is a simple Q&A bot that answers from a document you upload, which demonstrates retrieval without any code.

Add three nodes to the canvas:

1. Chat Model under Language Models, pick OpenAI Chat, and select gpt-4o-mini as the model.
2. Document Store under Vector Stores, choose In-Memory Vector Store. Connect a Text File node to it and upload a PDF or text file you want the bot to answer from.
3. Conversation Retrieval QA Chain under Chains. Connect the chat model to it, and the vector store to the chain's retriever input.

Connect the chain's output to the chat widget node. The canvas should now show a complete path from your document to the model. Click the chat bubble in the corner and ask a question that only your document can answer. If the response cites the uploaded content, the retrieval chain is working.

This is the part that surprises most people new to Flowise: the graph is the logic. There is no hidden glue code. If you want the bot to check a database before answering, you add a Postgres node and connect it. If you want it to call a webhook, you add a Custom Function node with a few lines of JavaScript. Each connection is a data flow, and the visual graph makes it obvious where a chain fails, which is something a wall of Python stack traces never gives you.

Step 5 - Expose the flow as an API and call it

A chatflow in the canvas is only a diagram until you deploy it. In the top-right corner of Flowise, click the wand icon to generate an API endpoint. Flowise returns a URL in the form https://flow.example.com/api/v1/prediction/<chatflow-id> and an authorization token.

Your frontend calls it with a simple POST request. The payload is just the message and, optionally, a session ID to keep conversation history.

curl -X POST https://flow.example.com/api/v1/prediction/<chatflow-id> \
  -H "Authorization: Bearer <your-token>" \
  -H "Content-Type: application/json" \
  -d '{"question": "What does the pricing page say about annual plans?", "sessionId": "user-123"}'

Flowise returns a JSON object where the answer lives in the text field. If you want streaming, which matters for a better UX with long answers, the API also supports Server-Sent Events via the streaming flag. The endpoint is a standard REST call, so it works from any frontend, a React app, a Vue SPA, or a simple HTML page, with no Flowise-specific SDK required.

Step 6 - Harden the deployment

Flowise running on a public VPS needs the same care as any other web service. Three things matter most.

Rate limiting at the proxy. Your chat API is a target for abuse. An attacker can burn through your OpenAI quota in minutes by hammering the endpoint. Add a simple limit in Nginx to throttle requests per IP.

sudo nano /etc/nginx/sites-available/flowise

limit_req_zone $binary_remote_addr zone=flowise:10m rate=10r/m;

server {
    listen 443 ssl http2;
    # ... existing SSL config ...

    location /api/v1/prediction/ {
        limit_req zone=flowise burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
        # ... existing proxy headers ...
    }
}

sudo nginx -t && sudo systemctl reload nginx

Scoped API keys. The OPENAI_API_KEY in the compose environment is the master key. If the flow needs a different model or a different account, create a second Flowise instance on another port with its own key rather than sharing one. Keep the key out of the flow JSON; anyone who exports the flow to share it would see the key.

Backups. The entire Flowise state, flows, credentials, and API keys, lives in the ~/.flowise directory. Back that up, not the container. A nightly tar to another disk or object storage means a broken upgrade is a five-minute restore, not a rebuild.

tar -czf flowise-backup-$(date +%F).tar.gz ~/.flowise

If you run this on a monthly billing VPS with snapshots enabled, you get a second safety net at the hypervisor level. Snapshots complement, but do not replace, the file-level backup, since a snapshot does not follow you if the VPS itself is lost.

Troubleshooting

The container restarts in a loop. Check the logs first. The most common cause is a wrong FLOWISE_USERNAME or FLOWISE_PASSWORD combination, or a permission issue on the ~/.flowise volume. The fix is usually docker compose down && docker compose up -d after fixing the .env file.

docker compose logs flowise | tail -50

Chat requests time out. The model call can take longer than the default Nginx proxy timeout. The proxy_read_timeout 300s in the server block handles this, but if you set it lower, you will see 504 errors on long answers. Raise it, or enable streaming so the client sees tokens arriving instead of waiting for a complete response.

CORS errors from your frontend. If your web app is on a different domain than the Flowise instance, the browser blocks the API call. Add the allowed origin to the Nginx config or, if you use the Flowise widget, embed it as an iframe (Flowise handles the CORS for the widget automatically).

FAQ

Related articles

• Self-hosting n8n for workflow automation on a VPS
• Self-hosting local LLMs on a VPS with Ollama
• Build a self-hosted RAG system with vector DB and LLM
• The best AI automation tool in 2026 for real workflows