Deploy Flowise Visual AI Workflows on a VPS (2026): Docker, LangChain, OpenAI/Ollama and HTTPS Deployment Guide

Flowise is not "yet another ChatGPT web shell." It's for AI pipeline orchestration.

Here's how I think about it:

• Dify is more of an AI application platform
• n8n is more of an automation workflow platform
• Flowise is more of an LLM pipeline building tool

If you want to understand "how a RAG Q&A actually chains documents, vector stores, prompts and models together," Flowise's visual nodes make it very intuitive.

Flowise itself isn't heavy. What really consumes resources is the database, vector store, local models and concurrent requests you connect.

If you only run Flowise + cloud model APIs:

If you also want to run Qdrant, PostgreSQL, Redis and Ollama on the same machine, don't buy the minimum spec.

My advice:

• Only connecting OpenAI / Claude / DeepSeek / OpenRouter: 2C4G is enough
• Flowise + Qdrant + PostgreSQL: 4C8G is more stable
• Flowise + Ollama local models: 16GB RAM is a more realistic starting point

Don't run a pile of AI tools on a 1C1G tiny box. Being able to open the panel is one thing; actually running workflows is another.

This article uses an Ubuntu / Debian VPS as an example.

First, log in via SSH:

ssh root@your_server_ip

Update the system:

apt update && apt upgrade -y

Install basic tools:

apt install -y ca-certificates curl gnupg ufw

Check resources:

free -h
df -h

Flowise runs on port 3000 by default. First check whether it's already in use:

ss -tlnp | grep 3000

If this machine already has Perplexica, Grafana or some frontend project occupying 3000, you'll need to change the port or use a reverse proxy to distinguish by domain.

If Docker isn't installed on the machine yet, follow the steps below.

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
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" > /etc/apt/sources.list.d/docker.list
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Confirm the installation:

docker --version
docker compose version

If you just want to get it running for a test first, you can use Docker Run.

docker run -d \
  --name flowise \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v /opt/flowise:/root/.flowise \
  -e PORT=3000 \
  -e FLOWISE_USERNAME=admin \
  -e FLOWISE_PASSWORD='replace-with-a-strong-password' \
  flowiseai/flowise:latest

Two things to note:

1. I bind the port to 127.0.0.1 so it isn't exposed directly to the public internet
2. /opt/flowise is mounted to /root/.flowise to avoid data loss when the container is recreated

Check the container:

docker ps --filter "name=flowise"

Check the logs:

docker logs flowise --tail=100

Test locally:

curl -I http://127.0.0.1:3000

If it's accessible locally, then use Caddy for HTTPS later.

For long-term use I recommend Compose. The directory is clear, and upgrades and backups are easier.

Create the directory:

mkdir -p /opt/flowise
cd /opt/flowise

Create .env:

cat > .env << 'EOF'
PORT=3000
FLOWISE_USERNAME=admin
FLOWISE_PASSWORD=replace-with-a-strong-password
DATABASE_PATH=/root/.flowise
SECRETKEY_PATH=/root/.flowise
LOG_PATH=/root/.flowise/logs
BLOB_STORAGE_PATH=/root/.flowise/storage
DISABLE_FLOWISE_TELEMETRY=true
EOF

Be sure to change the password here; don't use the example value.

Create docker-compose.yml:

services:
  flowise:
    image: flowiseai/flowise:latest
    container_name: flowise
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - PORT=${PORT}
      - FLOWISE_USERNAME=${FLOWISE_USERNAME}
      - FLOWISE_PASSWORD=${FLOWISE_PASSWORD}
      - DATABASE_PATH=${DATABASE_PATH}
      - SECRETKEY_PATH=${SECRETKEY_PATH}
      - LOG_PATH=${LOG_PATH}
      - BLOB_STORAGE_PATH=${BLOB_STORAGE_PATH}
      - DISABLE_FLOWISE_TELEMETRY=${DISABLE_FLOWISE_TELEMETRY}
    volumes:
      - /opt/flowise/data:/root/.flowise
    entrypoint: /bin/sh -c "sleep 3; flowise start"

Start it:

docker compose up -d

Check:

docker compose ps
docker logs flowise --tail=100

This setup is already enough for personal and small-team testing.

Assume your domain is:

flowise.example.com

Add an A record in DNS:

flowise.example.com -> your_server_ip

Install Caddy:

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' > /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy

Edit the configuration:

nano /etc/caddy/Caddyfile

Write:

flowise.example.com {
    reverse_proxy 127.0.0.1:3000
}

Check and reload:

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

Now visit:

https://flowise.example.com

You'll see the Flowise login page.

If you use Caddy as a reverse proxy, only open SSH, 80 and 443.

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status

Don't open 3000:

ufw deny 3000/tcp

The Compose setup above already binds 3000 to 127.0.0.1; this step adds another layer of protection.

If the Flowise panel is exposed naked to the public internet, the risk is high.

Because it may contain:

• OpenAI / DeepSeek API keys
• Vector store connection info
• Database connection info
• Internal tool call interfaces
• The workflow API endpoints you've built

At minimum, set:

FLOWISE_USERNAME=admin
FLOWISE_PASSWORD=replace-with-a-strong-password

If you use it inside a company, you can also add Cloudflare Access, Tailscale or a VPN to allow only specific users to access the panel.

After deployment, don't start with a complex Agent.

Start with the minimal pipeline:

1. Add a Chat Model node
2. Choose OpenAI / OpenRouter / DeepSeek / Ollama
3. Add a Prompt Template
4. Connect it to an LLM Chain
5. Open Chat to test

A minimal test question could be:

用三句话解释 VPS、Docker 和反向代理的关系。

If this doesn't work, don't touch RAG, Tools or Agents yet.

Common problems are usually:

• Wrong API key
• Wrong model name
• VPS can't reach the model API
• Nodes not connected correctly
• Not re-testing after saving

The advantage of Flowise is that it has many model nodes, so you can choose based on your situation.

If you use OpenAI, you usually need to prepare:

OPENAI_API_KEY=sk-xxxx

If you use OpenRouter, you can choose the OpenAI-compatible approach; the key points are the Base URL and model name.

If you use DeepSeek, you can also connect it in an OpenAI-compatible way.

Don't write API keys into public documents here, and don't commit .env to a Git repository.

I recommend filling them in Flowise's Credential management rather than hardcoding them in each node. It's more convenient when you change keys later.

If you want models to run on your own VPS, you can connect Ollama.

Install Ollama:

curl -fsSL https://ollama.com/install.sh | sh

Pull a model:

ollama pull qwen2.5:7b

Test:

curl http://127.0.0.1:11434/api/tags

If Flowise runs in Docker and needs to access the host's Ollama, you can't just write localhost.

Add to Compose:

extra_hosts:
  - "host.docker.internal:host-gateway"

Then in Flowise's Ollama node, fill in:

http://host.docker.internal:11434

If you fill in http://localhost:11434, the Flowise container will look for 11434 inside its own container, which usually fails to connect.

By default Flowise can save data as local files, which is enough for personal testing.

But if you plan long-term multi-user use, or want more standardized backups, consider PostgreSQL.

A simple rule:

Don't max out the architecture from the start. Flowise itself already has many nodes and configurations; getting the core flow stable matters more than stacking up database services.

At minimum, back up this directory:

/opt/flowise/data

It contains your Flows, Credentials, logs, storage files and other critical data.

Package locally:

mkdir -p /opt/backups
tar -czf /opt/backups/flowise-data-$(date +%F).tar.gz /opt/flowise

Sync to object storage:

rclone copy /opt/backups/flowise-data-$(date +%F).tar.gz r2:backup-bucket/flowise/

If you use PostgreSQL, also back up the database separately:

pg_dump "$DATABASE_URL" | gzip > /opt/backups/flowise-db-$(date +%F).sql.gz

Don't just back up the Compose file. What's really valuable is the Flows and Credentials you've built.

Upgrading a Compose deployment is simple:

cd /opt/flowise
docker compose pull
docker compose up -d

Back up before upgrading:

tar -czf /opt/backups/flowise-before-upgrade-$(date +%F).tar.gz /opt/flowise

Check after upgrading:

docker compose ps
docker logs flowise --tail=100
curl -I http://127.0.0.1:3000

Then actually run a Flow in the web UI to confirm nodes, Credentials and API endpoints all work.

These three are often compared together.

My advice:

• Want to learn and debug LLM pipelines: Flowise
• Want to build a complete AI application for others to use: Dify
• Want to connect AI into business processes: n8n

For example, if you want "user submits a form -> query CRM -> call model to summarize -> send to Slack," n8n is more suitable.

If you want "document retrieval -> Prompt -> model answer -> observe each node's output," Flowise is more intuitive.

If you want "an AI product with login, knowledge base, API and application publishing," Dify is more complete.

If I were running Flowise on a VPS myself, I'd configure it like this:

• VPS: 2 cores 4GB as a starting point
• Deployment: Docker Compose
• Port: bind only to 127.0.0.1:3000
• HTTPS: Caddy reverse proxy
• Login: must set FLOWISE_USERNAME / FLOWISE_PASSWORD
• Models: connect OpenRouter / DeepSeek / OpenAI first
• Local models: connect Ollama after the flow is stable
• Backup: back up /opt/flowise daily
• Long-term team use: then consider PostgreSQL

The value of Flowise isn't "installing an AI tool"; it's that it breaks the LLM pipeline into nodes you can see and adjust. For people learning RAG, building AI prototypes, and troubleshooting prompt and tool-call issues, it's faster than writing code directly and clearer than a pure chat interface.

But it's not a universal backend. Permissions, productization, user management and complex application publishing may be better suited to Dify. Before choosing a tool, think clearly: do you want to "build pipelines" or "build a product"?