# Flowise is archived, and its own Docker build drops the agentflow and observe packages > A read of FlowiseAI/Flowise: why the repository is marked archived above its own title, what exit code 134 during the build means, why the container excludes two workspace packages that the npm install includes, and where the database migrations and worker process live in the root scripts. **FlowiseAI/Flowise** — Flowise lets you build AI agents and LLM workflows visually, dragging and dropping components for chatbots, RAG, and multi-agent systems instead of writing code. - Repository: https://github.com/FlowiseAI/Flowise - Website: https://flowiseai.com - Stars: 55,492 · Forks: 25,052 - Language: TypeScript - License: not declared - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/flowiseai-flowise ## The archive notice sits above the product name, not in a changelog The readme's own second heading is the announcement, placed before the product tagline rather than at the end of a release history. It states that Flowise has been archived and points to a discussion titled Future of Flowise on the project's Discussions page. The repository is flagged as archived, and the last push landed on 2026-08-13. The release history explains what a frozen state means in practice. The three most recent releases are flowise@3.1.4 on 2026-07-29, flowise@3.1.3 on 2026-06-25 and flowise@3.1.2 on 2026-04-14, so the cadence before the freeze was roughly one release a month with a longer gap in spring. Every install route in the readme still resolves, since npm keeps serving the last published version and the files in the repository are all present, so nothing in the tooling announces the archive to a user who just follows the quick start. That is the practical risk. Someone installing today gets working software and no error, and discovers the state only if they read past the install steps. Two specific things change for a new project: no dependency or model provider breakage will be patched here, and the self-hosting and deployment documentation at docs.flowiseai.com describes a product whose community has moved on. ## Three commands, port 3000, and a development port that is not the same The quick start is short enough to read once. Node.js 20.0.0 or newer is required, the package is installed globally with npm, started through npx, and the interface appears on port 3000. ```bash npm install -g flowise ``` ```bash npx flowise start ``` Two details are worth noticing. The install is global and the start goes through npx, so the running process is resolved by npx rather than by a local binary path, which matters on a machine where a different Flowise version is already installed globally. And the port appears in three separate places in this document: the quick start, the published port mapping in the Docker run command, and the port the container exposes. The development setup does not use the same port, and that is a genuine difference rather than a typo. For a development build you create a `.env` file in `packages/ui` and set `VITE_PORT`, and another `.env` in `packages/server` and set `PORT`, each referring to the `.env.example` in its package, then run the dev command and the app comes up on port 8080 with automatic reload. Two environment files in two packages control one port, and nothing in the readme explains which of the two wins if they disagree. ## The documented build failure is exit code 134, and the fix is a heap flag The developer setup names one failure explicitly, and it is the kind that wastes an afternoon. Building the monorepo can die with exit code 134, described as a JavaScript heap out of memory, and the fix is to raise the Node heap and run the build again. The flag is given per shell, which tells you the project expects all four environments to be in use. ```bash export NODE_OPTIONS="--max-old-space-size=4096" ``` ```bash pnpm build ``` Two observations. First, a fresh clone on a machine with less memory than the build assumes fails at step four with a numeric exit code and no explanation unless you have already read this section, which is a poor first experience for a contributor. Second, the number here and the number in the container are different. The Dockerfile sets `NODE_OPTIONS=--max-old-space-size=8192`, twice the documented local value, which tells you the maintainers knew the build was hungry and left the local instructions at the lower figure. The rest of the developer path is unremarkable and worth listing so the cost is known: install pnpm globally, clone, `pnpm install` to install dependencies for all modules, `pnpm build`, then `pnpm start`. ## The Docker build excludes agentflow and observe, the npm install does not This is the most consequential difference in the document and it is a single script. The root package manifest has two build commands. The plain one runs the build across the workspace, and the Docker one filters two packages out of it. ```bash pnpm build:docker ``` The filters are on `@flowiseai/agentflow` and `@flowiseai/observe`, and the comment above the command in the Dockerfile says the sdk packages excluded are not needed for Docker. So the container is deliberately a smaller product than the npm installation, and the readme's Docker sections never say so. Anyone who installs with npm, builds a flow using one of those two packages, and then deploys the same flow into the container will find the feature missing, and the symptom will be a node that cannot be resolved rather than a message about the build. The workspace shape explains what is being filtered. The manifest lists `packages/*` alongside the named directories `flowise`, `ui`, `components` and `api-documentation`, and the developer section describes the modules as a Node backend serving API logic, a React frontend, third party node integrations, and swagger-ui API documentation generated from express. Note the arithmetic there too: the text says three modules and then names four. ## TypeORM migrations and a separate worker process live in the root scripts The root manifest is where the runtime shape of the product shows, and it is not a frontend project with a server bolted on. Migrations are created through TypeORM, which means the instance owns a relational database and that upgrading across versions is a schema question rather than a file copy. ```bash pnpm typeorm migration:create ``` There is a worker alongside the server, started through the same platform-dispatching pattern as the main start command, and a user command for account management, each with a Windows variant and a default variant that changes directory into `packages/server/bin` and runs a wrapper. Tests run through turbo across the workspace, with a coverage variant, and there are two levels of cleaning, a recursive clean and a nuke that also removes `node_modules` and the turbo cache. What is absent is any statement about the data directory. The env variables are configured in a `.env` file inside `packages/server`, with more documented in the contributing guide, and the compose route starts from a copy of `.env.example`, but the readme says nothing about backing up the database before an upgrade or about what a migration does to existing flows. For a self-hosted instance, that is the gap to close before upgrading anything. ## The release tag matches a private root package, not the CLI you install The root manifest is named flowise and carries version 3.1.4, which is also the tag on the newest release, flowise@3.1.4. The same file sets the package private. A workspace root marked private is not published to a registry, so the version attached to the release belongs to the repository's own root while the artefact you install with `npm install -g flowise` is one of the workspace packages. The two can drift, and nothing in the readme states which package's version the global install reports. The rest of the toolchain is conventional and worth knowing before a first contribution. Formatting is prettier over TypeScript, TypeScript React and Markdown, linting is eslint over JavaScript, JSX, TypeScript, JSON and Markdown, a staged hook runs on commit, and a postinstall hook installs husky, which means a plain install in a fresh clone writes to your git hooks. Releases are driven by changesets, with commands to create one and to apply a version bump, and a load test configuration sits at the top level as artillery-load-test.yml. Contributors also get the community plumbing: a contributing guide, a code of conduct, a security policy, and a Discord linked from the readme for questions about contributing itself. ## Compose is the documented self-host route, and the image is built locally For self-hosting, the readme points at a documentation site with deployment guides for AWS, Azure, Digital Ocean, GCP and Alibaba Cloud, then a longer list under Others covering Railway, Northflank, Render, HuggingFace Spaces, Elestio, Sealos and RepoCloud. Flowise Cloud is offered separately as a hosted option. The compose route is local and specific: clone the project, go to the `docker` folder at the root, copy `.env.example` into place and rename it to `.env`, then bring the stack up and open port 3000. ```bash docker compose up -d ``` The image route, by contrast, builds on your machine rather than pulling a tag the readme names. ```bash docker build --no-cache -t flowise . ``` That matters for reproducibility, because a compose file or a build from a checkout is pinned to the commit you have, while a published image tag is not part of this document at all. Two details in the Dockerfile are also worth reading before you debug a headless browser problem. The image installs the chromium package, sets `PUPPETEER_SKIP_DOWNLOAD` so Puppeteer does not fetch its own browser, and then hardcodes `PUPPETEER_EXECUTABLE_PATH` to a chromium browser path rather than discovering it, so the path is an assumption baked into the image. A comment in the file refers to a node 20 Alpine base while the build stage is node 24, which is a leftover rather than a second base image. ## Conclusion Flowise still works for building an agent flow and self-hosting it, and the Apache 2.0 source and the compose files remain readable, but treat it as frozen: the last push was 2026-08-13 and the final release is flowise@3.1.4 from 2026-07-29. If you are starting something new, read the Future of Flowise discussion the readme points to before you commit. If you already run it, keep the version you have, and check whether your deployment came from the npm install or from the Docker build before you rely on an agentflow or observe feature. ## FAQ ### What is Flowise used for? It is a visual builder for AI agents, described as building agents visually, with a Node backend serving API logic, a React frontend, a components layer of third party node integrations, and swagger-ui API documentation generated from express. ### How do I install Flowise? With Node.js 20.0.0 or newer, run `npm install -g flowise` and then `npx flowise start`, and open http://localhost:3000. For self-hosting there is also a compose route in the repository's docker folder and a local image build. ### How do I install Flowise using Docker? Clone the project, change into the `docker` folder at the root, copy `.env.example` to `.env`, run `docker compose up -d` and open http://localhost:3000, stopping the stack later with `docker compose stop`. To build the image instead, use `docker build --no-cache -t flowise .` and run it on port 3000. ### How do I use the Flowise API? The monorepo includes an api-documentation module that auto-generates swagger-ui API docs from express, and the server module is the Node backend serving API logic, so the endpoints are documented from the same code that serves them. The readme links the documentation site rather than listing endpoints itself. ### Is Flowise AI free? The source code in the repository is made available under the Apache License version 2.0, and the quick start, compose and image routes are all self-hosted. Flowise Cloud is offered as a separate hosted product, and the readme does not state its pricing. ## Sources - [Official documentation](https://flowiseai.com) - [Official README](https://github.com/FlowiseAI/Flowise#readme) - [Project repository](https://github.com/FlowiseAI/Flowise) - [Release notes](https://github.com/FlowiseAI/Flowise/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flowiseai-flowise