Optimize basename handling and ensure dynamic runtime definition (custom basepath) #3317
+58
−6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As part of this contribution, I’ve implemented a series of modifications in Flowise to allow it to support a custom BasePath (which corresponds to the basename property in React). This is an essential feature for enabling deployments where the application needs to run under a specific path, such as behind a reverse proxy like NGINX, without requiring changes to the underlying Flowise backend.
The main challenge was that Flowise’s frontend did not natively support running under a BasePath. Without this capability, any attempt to deploy Flowise under a custom path (e.g., https://flowise.domain.com/custom/chatflows) would break the application, as all assets and routes would assume the root URL. In environments where Flowise needs to coexist with other services on the same domain, this becomes a significant limitation.
To solve this, I introduced logic to dynamically set the basename in React’s router based on a configurable BasePath. The change was isolated to the frontend, where the BasePath can now be managed without impacting the backend. Specifically, I introduced a mechanism to substitute the %BASE_HREF% variable in index.html at runtime, allowing the application to correctly resolve assets and routes when deployed under any given path.
On the backend side, I ensured that this works seamlessly with NGINX, where NGINX strips the BasePath from the request and forwards it to Flowise as usual. This solution ensures that Flowise can now be deployed with a custom BasePath, enabling greater flexibility for deployments in various environments, such as microservices architectures or multi-tenant setups.
This feature is crucial for improving Flowise’s adaptability in enterprise-level deployments, where the application may need to share a single domain with other services. It also helps avoid potential conflicts and ensures that Flowise remains robust and scalable in a broader range of scenarios.
I’m confident that this enhancement will significantly benefit teams looking to integrate Flowise into more complex infrastructures, and I encourage its adoption to make Flowise even more versatile in production environments.