Flowise: self-hosting the archived visual agent builder

What Flowise solves, and who it is actually for

Wiring an LLM application by hand means writing the same plumbing repeatedly: a prompt template, a retriever over a vector store, a tool-calling loop, a memory buffer, and an HTTP endpoint to expose the result. Flowise puts those pieces on a canvas. The README describes it as a way to "Build AI Agents, Visually", and the repository layout backs that up: packages/server holds the Node backend that serves the API, packages/ui holds the React frontend, and packages/components holds third-party node integrations. A node is a unit of work, and a chain is a graph of nodes.

The audience is narrower than the tagline suggests. Someone who already writes Python or TypeScript comfortably will find the canvas slower than a framework call. The people who get value are those assembling retrieval pipelines or tool-using agents from existing integrations, and teams that want a non-engineer to be able to inspect or adjust a flow without reading source. The api-documentation package generates a swagger-ui from Express, so the flows you build are reachable over HTTP rather than trapped in the UI.

One caveat belongs here rather than at the end. The repository is archived, and the README's own banner points readers to a discussion titled "Future of Flowise". That banner is the first thing on the page for a reason: the project is not being developed further in this repository.

The monorepo behind the canvas

The root package.json declares a private workspace with four entries: packages/*, flowise, ui, components, and api-documentation. Build orchestration runs through Turbo, visible in turbo.json and in the build script, which is turbo run build. That is the mechanism that matters if you intend to modify anything: a change to a node in packages/components is compiled and picked up by the server, and the UI is a separate build target.

The Dockerfile narrows that build deliberately. It runs pnpm build:docker, and the root package.json defines build:docker as turbo run build with two filters excluded: --filter=!@flowiseai/agentflow and --filter=!@flowiseai/observe. Those two packages are not needed for a container image, so the image build skips them. If you build the full workspace instead, you compile more than the container does, and the README documents an exit code 134 (JavaScript heap out of memory) failure on pnpm build with a NODE_OPTIONS workaround.

The data flow is conventional for this class of tool. The browser talks to the Express server, the server executes the graph you drew, and each node calls out to whichever provider it wraps. There is no separate orchestration service to run. That simplicity is the reason self-hosting is a single process, and it is also why scaling behaviour is whatever your Node process does under load. The repository does contain artillery-load-test.yml, so load testing was at least considered, but the README does not document expected throughput.

Installing Flowise with npm and opening the canvas

The fastest path is the global npm install the README gives. It requires NodeJS >= 20.0.0, which the quick start states explicitly. Install the package, then start the server:

npm install -g flowise
npx flowise start

The server listens on port 3000. Open http://localhost:3000 in a browser and you land on the canvas, where you can drag nodes and connect them. If the install fails, check your Node version first, since the >= 20.0.0 floor is the one prerequisite the README calls out.

For a container instead of a global install, the README documents both a Compose path and a plain image path. The image path builds locally and then runs the container:

docker build --no-cache -t flowise .
docker run -d --name flowise -p 3000:3000 flowise

The published Dockerfile builds on node:24-alpine, installs [email protected] globally, sets NODE_OPTIONS to --max-old-space-size=8192, and runs as the non-root node user. It also installs chromium and sets PUPPETEER_EXECUTABLE_PATH to /usr/bin/chromium-browser with PUPPETEER_SKIP_DOWNLOAD=true, which matters if any node in your flow needs a headless browser.

The Compose path is slightly more involved because it needs configuration first. Clone the repository, go to the docker folder at the root, copy .env.example and rename the copy to .env in the same location, then bring it up:

docker compose up -d
docker compose stop

The README lists step 5 as opening http://localhost:3000 and step 6 as stopping the containers with docker compose stop. Note that the .env.example copy step is not optional in practice: the Compose file expects that file to exist before the containers start.

Building from source and the two env files developers must create

The developer path is documented and worth following only if you intend to change the code. It requires PNPM, installed with npm i -g pnpm, then a clone, an install across all workspace modules, and a build:

git clone https://github.com/FlowiseAI/Flowise.git
cd Flowise
pnpm install
pnpm build
pnpm start

If pnpm build exits with code 134, the README attributes it to a JavaScript heap out of memory condition and gives the fix. On macOS, Linux or Git Bash:

export NODE_OPTIONS="--max-old-space-size=4096"
pnpm build

Windows users get separate forms for PowerShell and CMD, both setting the same NODE_OPTIONS value. This is a real constraint rather than a footnote: a default Node heap is not enough to compile this workspace.

For a development build with hot reload, the README asks for two separate .env files, not one. In packages/ui you create a .env and specify VITE_PORT, and in packages/server you create a .env and specify PORT. Then pnpm dev runs the app, and the README says changes reload automatically on http://localhost:8080. That is a different port from the production 3000, which trips people up when they switch between the two modes. The README also points at packages/server for the broader set of environment variables and links to CONTRIBUTING.md for the full list.

Where Flowise stops being the right tool

The archived status is the limitation that overrides the others. The README's banner states that Flowise has been archived and links to a discussion about its future. The last push was on 2026-07-29, and the most recent release listed is [email protected] on the same date. Nothing in the repository describes a successor repository or a migration path, so anyone adopting this should assume the dependency set is frozen unless they maintain a fork.

That has a concrete consequence. packages/components wraps third-party providers, and those providers change their APIs. A pinned integration that stops matching a provider's current endpoint is a breakage you fix yourself. The same applies to security: SECURITY.md exists in the repository root, but an archived repository is not a place to expect coordinated disclosure and patched releases.

There is a second, less obvious boundary. Flowise is a builder for LLM graphs, not a general automation platform. If your problem is moving data between SaaS systems on a schedule, the canvas is the wrong abstraction and you will spend more time working around it than using it. And if you need deterministic, version-controlled pipeline definitions that live in git next to the application code, a visual graph stored in the app's own database is a worse fit than a code-first framework. The README does not document an export format for flows, so treat the canvas as the source of truth.

Flowise compared with n8n and Langflow

The comparison people actually search for is Flowise against n8n. The difference is in what the graph is for. n8n is a general workflow automation tool: triggers, schedules, hundreds of SaaS connectors, and LLM steps as one category among many. Flowise inverts that. Its node set is built around LLM primitives, and the api-documentation package exists to expose the flows you draw as an HTTP API rather than to run them on a cron. If your centre of gravity is model calls, retrieval and agents, Flowise's canvas is closer to the problem. If it is business process automation with a model call somewhere inside, n8n covers more of the surface.

Against Langflow the distinction is mostly language and packaging. Langflow is a Python project; Flowise is a TypeScript monorepo with a Node server and React UI, distributed on npm and as a Docker image. That matters operationally. A team already running Node services can install Flowise with npm install -g flowise and keep one runtime, one package manager, and one deployment story. A team whose data stack is Python will find Langflow's custom components easier to write, because they are written in the same language as the rest of their code.

The honest summary is that the choice between these three is usually made by your existing stack rather than by feature lists, and for Flowise specifically it is now also made by the archived status. A maintained alternative wins on maintenance grounds regardless of how the canvases compare.

Licence, upgrade cost and what archiving changes

The README states that source code in the repository is made available under the Apache License Version 2.0, and LICENSE.md is present at the root. Apache 2.0 is permissive: you can use, modify and redistribute the code, including commercially, provided you keep the licence and notices and state significant changes. It also includes a patent grant, which is the part that matters if you are embedding this in a product. This is a description of the licence text, not legal advice; if you are redistributing a modified Flowise, have counsel review your notices.

Upgrade cost is where archiving bites. The repository uses Changesets, visible in .changeset/ and in the changeset and changeset:version scripts, so releases were versioned and changelogged while development was active. Version 3.1.4 is the last one listed. That means upgrading beyond it is not a matter of pulling a newer tag. It is a matter of forking, applying your own patches, and tracking upstream provider API changes yourself. There is also a migration:create script wired to TypeORM, which tells you the server persists to a database with migrations. If you fork, those migrations are yours to maintain.

The practical question is not whether Apache 2.0 permits a fork. It does. The question is whether you have the appetite to own a TypeScript monorepo with a Turbo build, a React UI and a set of third-party node integrations, because that is what adopting an archived project means after the first provider API changes.

Editorial conclusion

Adopt Flowise if you need a self-hosted canvas for LLM chains, you are comfortable reading a TypeScript monorepo, and you accept that the last push was on 2026-07-29 with the repository archived. Do not adopt it if you need vendor support, a security response process, or a roadmap you can influence. Before committing, verify three things: that npm install -g flowise still resolves for your Node version, that your node integrations are covered by the third-party nodes package, and that Apache 2.0 obligations are met for whatever you redistribute.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes