Published

Flowise

Visual builder for LLM chatflows, agents and RAG pipelines: nodes are wired on a canvas and each flow is served as an API or an embeddable chat widget. Suits a team that wants to prototype and host assistants on its own server while calling external or self-hosted models.

Resources by load level

What the app itself needs at each level, next to what we recommend for a server that runs only this app.

Level	What it means	App requirements	Recommended
LightEstimate	Up to 10,000 predictions per month (~330/day, the Cloud Starter limit), up to 2 at once; up to 10 chatflows; up to 1 GB of uploaded files; main mode.	1 vCPU · 1 GiB RAM · 8.75 GiB disk	1.32 vCPU · 2.7 GiB RAM · 19.493 GiB disk
MediumEstimate	Up to 50,000 predictions per month (~1,700/day, the Cloud Pro limit), up to 10 at once; up to 50 chatflows; up to 10 GB of uploaded files; main mode.	2 vCPU · 4 GiB RAM · 18.25 GiB disk	2.52 vCPU · 6.3 GiB RAM · 30.418 GiB disk
HeavyEstimate	Up to 150,000 predictions per month (~5,000/day), up to 25 at once; up to 200 chatflows; up to 20 GB of uploaded files; still one main process (beyond this, queue mode).	4 vCPU · 8 GiB RAM · 29.25 GiB disk	4.92 vCPU · 11.1 GiB RAM · 43.068 GiB disk

Recommended = app requirements + system baseline + safety headroom, under sizing policy 2026.10.0. Options stay at their defaults. “Estimate” means the sources give no number for that case, so it is worked out from them by the method stated under Components. How the numbers are built

Size it in the Stack Sizer

Ready-to-run files

Support level Supported

Compose template from the official sources; not yet verified by a run.

Create docker-compose

Components

What each component needs at each load level, before baseline and headroom.

vCPU / GiB RAM / GiB disk
Component	Light	Medium	Heavy	Sources
Flowise (app)	1 / 1 / 8.75	2 / 4 / 18.25	4 / 8 / 29.25	[15][22][23][24][29][32][34]
PostgreSQL (database)	—	—	—

How the estimates are worked out

Flowise · Light: vCPU and RAM: the request in the docs' GCP Kubernetes manifest for one Flowise replica (cpu 1, memory 1Gi). Disk: image 7.25 GiB (compressed 1.442 + unpacked 5.805 = 7.247, both kept by the containerd image store, rounded up) + 1 GiB uploads (the Starter plan's 1 GB storage) + 0.5 GiB for database.sqlite and logs = 8.75 GiB.
Flowise · Medium: vCPU and RAM: half of the 4 vCPU / 8 GB server the production guide names as the starting size of one Flowise instance, 8 GB taken as GiB: 2 vCPU, 4 GiB. Disk: image 7.25 GiB + 10 GiB uploads (the Pro plan's 10 GB storage) + 1 GiB for database.sqlite and logs = 18.25 GiB.
Flowise · Heavy: vCPU and RAM: one full server of the size the production guide gives as the starting point per Flowise instance (4 vCPU, 8 GB taken as 8 GiB). Disk: image 7.25 GiB + 20 GiB uploads (2 × the Pro plan's 10 GB) + 2 GiB for database.sqlite and logs = 29.25 GiB.
database · PostgreSQL: Embedded metadata DB with the image's default config: equals the PostgreSQL profile's light preset (≤ 5 GB data, ≤ 20 concurrent connections) at every load level. Light preset method: shared_buffers 25% of RAM, worst-case work_mem/maintenance_work_mem budget, 0.5 GiB image + 5 GiB data + 1 GiB WAL.

Options that change resources

database

Database engine. SQLite (the default) is a file in the Flowise volume with no extra service; PostgreSQL (DATABASE_TYPE=postgres) adds a separate container, which the docs recommend when running at scale. Uploads, logs and key files stay in the Flowise volume either way.

Default: sqlite

When postgres: PostgreSQL +1 vCPU · +1 GiB RAM · +6.5 GiB disk [5][23][37][38][39][40][41][42][43]

Ports

Public ports are meant to be reached from outside the stack, usually through a reverse proxy; internal ones stay on the stack's own network.

Component	Port	Exposure	Purpose	Sources
Flowise	3000/tcp	Public, through a proxy	Web UI, REST and prediction API, embed widget (HTTP; behind a TLS reverse proxy)	[2][6]
PostgreSQL	5432/tcp	Internal only	PostgreSQL connections from Flowise (database option postgres)	[5][42]

Every port in the catalog, with conflicts between apps

User and permissions (UID/GID)

The user each container's process runs as, and the paths it writes to. A bind mount for one of these paths must be writable by that UID:GID.

Component	UID:GID	User	Starts as root	Writes to	Sources
Flowise	1000:1000	`node`	No	`/home/node`	[3][15][18]
PostgreSQL	999:999	`postgres`	Yes, prepares its directories, then drops to this user	`/var/lib/postgresql/var/run/postgresql`	[35][36][42]

Flowise: Since 3.1.4 the image ends with USER node and starts flowise start directly, with no root step. The node:alpine base creates node with uid and gid 1000. Flowise writes database.sqlite, encryption.key, the auth secret key files, storage/ and (with LOG_PATH) logs/ under $HOME/.flowise = /home/node/.flowise. The image has no .flowise directory, so the template's volume is mounted at the node-owned /home/node and Flowise creates .flowise inside it.

Storage growth

How much each component's data grows per month at each load level, on top of the disk in the profile. A value marked Assumption is ANAROQ's stated assumption, not a figure from the sources; the notes say what it rests on.

GiB per month
Component	Light	Medium	Heavy	Sources
FlowiseAssumption	0.163	1.108	2.405	[29][30][32]
PostgreSQLAssumption	0.038	0.191	0.572	[29][30]

What the growth figures rest on

Flowise: Upstream gives no growth rate. Assumes the preset's 1.5 GiB of uploads, database and logs fills over 12 months (1.5 / 12), plus chat history in database.sqlite: 10,000 predictions × 4 KiB (question and answer rows) = 0.038 GiB a month. Logs are never pruned by default. With PostgreSQL the chat-history part moves to the postgres volume.
Flowise: Upstream gives no growth rate. Assumes the preset's 11 GiB of uploads, database and logs fills over 12 months (11 / 12), plus chat history in database.sqlite: 50,000 predictions × 4 KiB (question and answer rows) = 0.191 GiB a month. Logs are never pruned by default. With PostgreSQL the chat-history part moves to the postgres volume.
Flowise: Upstream gives no growth rate. Assumes the preset's 22 GiB of uploads, database and logs fills over 12 months (22 / 12), plus chat history in database.sqlite: 150,000 predictions × 4 KiB (question and answer rows) = 0.572 GiB a month. Logs are never pruned by default. With PostgreSQL the chat-history part moves to the postgres volume.
PostgreSQL: Only with the postgres option. Chat history: 10,000 predictions a month × 4 KiB (question and answer rows) = 0.038 GiB; Flowise does not prune messages by default. ANAROQ assumption, upstream gives no size per message.
PostgreSQL: Only with the postgres option. Chat history: 50,000 predictions a month × 4 KiB (question and answer rows) = 0.191 GiB; Flowise does not prune messages by default. ANAROQ assumption, upstream gives no size per message.
PostgreSQL: Only with the postgres option. Chat history: 150,000 predictions a month × 4 KiB (question and answer rows) = 0.572 GiB; Flowise does not prune messages by default. ANAROQ assumption, upstream gives no size per message.

Upgrade and rollback

How to move to a new version safely, and how to go back if it fails.

Back up first

Stop Flowise and back up the whole /home/node/.flowise volume (database.sqlite, encryption.key, auth secret key files, storage/), or with PostgreSQL take a pg_dump as the databases guide shows. [5][31]

Upgrade steps

Check the changes of every version between yours and the target (tags on GitHub and the npm package), then set the new pinned tag flowiseai/flowise:X.Y.Z in the Compose file. [13][14]
Run docker compose pull and docker compose up -d. Flowise runs pending database migrations at startup; wait until /api/v1/ping answers before using it. [3][8][10]
Keep FLOWISE_SECRETKEY_OVERWRITE unchanged; a different key makes every stored credential undecryptable. [6]
Coming from 3.1.3 or older with the official file: data moves from /root/.flowise to /home/node/.flowise and must be owned by 1000:1000 (chown -R 1000:1000 on the host directory). [2][3][17]

Roll back

Pin the previous tag and run docker compose up -d. If the new version ran migrations, restore the volume or database backup taken before the update first. [5][8]DerivedFlowise documents no downgrade path; it only runs migrations forward at startup, so ANAROQ treats the pre-update backup as the way back.

Known breaking changes

In 3.1.4: The image runs as the non-root node user (uid 1000) instead of root: the data path is /home/node/.flowise instead of /root/.flowise, and a bind-mounted directory must be owned by 1000:1000. [2][15][16][17]
In 3.1.4: Custom MCP stdio servers can run only commands listed in CUSTOM_MCP_ALLOWED_COMMANDS, which is empty by default (none allowed); before, node, npx, python, python3 and docker were allowed. [4][6]
In 3.0.1: New email and password login replaces FLOWISE_USERNAME / FLOWISE_PASSWORD; existing instances must set up a new admin account, first signing in with the old credentials. [7]

Limits

Main mode runs every prediction in one Node.js process, which the docs say does not scale to large numbers of predictions. Queue mode (Redis plus workers, with shared storage and PostgreSQL) is not part of this template; upstream's production setup starts at 2 main servers and 4 workers of 4 vCPU / 8 GB each. [23][24][25]
The open-source edition has no workspaces, user invitations, role-based access, SSO or evaluations: those are Cloud and Enterprise features under a commercial license (packages/server/src/enterprise). Plan for one admin account building flows. [20][26]
Model inference is not included: chat and embedding nodes call a hosted API or a separate runtime such as Ollama or LocalAI, which needs its own resources on top of these figures. [28]
Logs are never pruned: the server log rotates every 20 MB but keeps every file, and the request log is a single file without rotation. Clean /home/node/.flowise/logs periodically. [3][32]

Security

A new installation asks for an admin account on first visit. Create it right after the first start, before the URL is reachable by others. [26]
Custom MCP stdio servers and custom tools run code on the server. Keep CUSTOM_MCP_SECURITY_CHECK on and CUSTOM_MCP_ALLOWED_COMMANDS empty unless every user who can edit flows is trusted. [4][6]
Port 3000 is plain HTTP: serve it through an HTTPS reverse proxy with APP_URL set to the https address (secure cookies). By default Flowise trusts X-Forwarded-For from any hop, which per-IP rate limits rely on, so set TRUST_PROXY to the real number of proxies. [8][9][27]

Backup

Back up the whole /home/node/.flowise volume with Flowise stopped: database.sqlite (flows, credentials, chat history), encryption.key and the auth secret key files, and storage/ (uploaded files). Keep FLOWISE_SECRETKEY_OVERWRITE with the backup. [5][31][32]
With the postgres option, dump the database with pg_dump and test the dump by restoring it into a test database, as the databases guide describes; the Flowise volume still needs its own backup. [5]