Flow-Wiser Picks Up the Discontinued Flowise and Flags Possible Mismatches Between Official Docker Tags and Actual Package Versions

After Flowise ended active development and archived its upstream repository, the community fork Flow-Wiser released version 3.1.4-fw10 in an effort to provide a redistributable, self-hostable continuation. The fork removes commercially licensed enterprise modules from the original project and independently implements local username-and-password authentication, SSO, TOTP MFA, a deny-by-default system covering 82 permissions, organization and workspace isolation, auditing, and data encryption managed with AES-256-GCM and HKDF. The build process also adds license-file scanning, package-version assertions, and CI gates. The maintainers say the release commit passed 974 tests, linting, compilation, and Cypress checks, although these figures currently come primarily from the project itself and have not yet been independently audited.

Of greater concern to self-hosting teams is a container supply-chain issue. Following an inspection, the Flow-Wiser maintainers claim that the official Docker images tagged 3.1.3 and 3.1.4 still contain the Flowise 3.1.2 server. One possible explanation is that the Dockerfile runs `npm install -g flowise` without specifying a version and that this layer was cached rather than refreshed when the tags changed. Docker Hub confirms that the tags and images exist, but public metadata alone cannot verify the package version inside each container, so users should reproduce the finding themselves. Engineering teams can call `/api/v1/version`, compare image digests, and inspect the container’s `package.json` in CI instead of treating a tag as proof that patches have been applied.

Migrating to Flow-Wiser is not a risk-free drop-in replacement. It is maintained by a new community, has no affiliation with either the original vendor or Workday, which acquired Flowise, and still relies on the deprecated `vm2` package for code execution. Although its configuration blocks known escape paths, it is not a strong security boundary. The next points to watch are whether third parties reproduce the version mismatch in the older images, whether the new authentication and tenant-isolation implementations undergo security reviews, and whether the fork can establish sustainable release and vulnerability-response processes.