Dify vs Flowise: which to choose when Flowise is archived
Flowise's GitHub repository was archived to read-only status on August 13, 2026, and the FlowiseAI core team ended its presence on August 31, 2026, so no further releases, security fixes or issue triage come from the core team. For most new self-hosted deployments, that fact decides the shortlist before features are compared. The last release, flowise@3.1.4, dates from July 29, 2026. Dify remains an actively released project: 1.17.1 was published on September 10, 2026, and minor releases have arrived roughly monthly. Dify fits a team that wants a maintained, self-hosted platform with visual workflows, RAG, agents and app publishing, and that can accept Dify's modified Apache 2.0 terms.
Flowise still has a place, but only in two situations. The first is a team willing to fork the repository and own patching, dependency upgrades and security response indefinitely, which the Future of Flowise announcement explicitly anticipates. The second is an organization already running Flowise that has a written plan for a migration window, a freeze on exposing it to new users, and a date by which flows move. Flowise's source remains under Apache 2.0 outside the enterprise paths, but code under packages/server/src/enterprise and files with explicit copyright notices are commercially licensed, so confirm which components your install touches before you assume a fork is clean.
The decision turns on four things: maintenance (who will ship fixes after the next vulnerability), license terms (Dify's multi-tenant and console branding limits versus Flowise's split licensing), identity needs (Dify's SSO and RBAC sit in its Enterprise edition, so confirm what your authentication model requires before you commit), and the cost of rebuilding flows. Flows built in Flowise do not translate one-to-one into Dify, so inventory existing chatflows, their tools and vector stores, and their external integrations. Ask your implementation partner for a written estimate covering that rebuild, testing and cutover, and confirm the Dify edition and components you need in the Dify docs on deploying with Docker Compose.
Which platform fits which team scenario
This table maps common team situations to the platform that fits better, with the supplied fact behind each call. Read it by finding your scenario, then checking the condition noted in the last column, since Flowise remains the better choice in a few narrow cases.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| New internal AI assistant project | Dify | Dify is an active project with monthly minor releases (1.17.1 on September 10, 2026), while Flowise received its last release on July 29, 2026. Choose Flowise only if your team already has Flowise skills and accepts unsupported code. |
| Existing Flowise install in production | Migrate to Dify (plan now) | The repository is archived and read-only, so no further security fixes come from the core team. Keep Flowise running only behind network controls while you plan the move and confirm your own patch path. |
| Team needs SSO from day one | Dify Enterprise | Dify Enterprise SSO supports OpenID Connect, SAML and OAuth2, with providers such as Microsoft Entra ID and Okta. Community Edition does not include SSO, so confirm the Enterprise license cost in a written quote. |
| Team wants to fork and maintain its own build | Flowise, with caution | Flowise source stays Apache 2.0 and the maintainers encourage forks. The enterprise directory and files with explicit copyright notices remain under a commercial license, so a fork cannot include them freely. Choose this only with staff who will own every patch. |
| Several workspaces or tenants | Dify Enterprise or a separate review | Dify Community is limited to a single workspace, and the license bars operating a multi-tenant environment from source without written authorization. Multi-workspace management is an Enterprise feature, so confirm the license terms with LangGenius before you build. |
| Air-gapped or offline deployment with a fixed, small scope | Either, after testing | Both can run in your own infrastructure, but Flowise's npm or Docker setup is lighter with SQLite as default. Pick Flowise only if its current feature set covers your flows and you accept no upstream fixes. |
| Team with many production flows to keep unchanged | Dify, with a flow migration plan | Flows do not transfer automatically between the two platforms. Budget a rebuild and test pass, and ask a vendor or partner to scope it in writing before committing. |
How Dify and Flowise are built and what that means for operations
Dify and Flowise both run as self-hosted visual LLM builders, but they ask for different stacks, different databases and different amounts of upkeep. The cards below set out the moving parts of each, then the storage and patching decisions that follow from them, so you can size the operating load before you commit.
Dify's Docker Compose stack
The Docker Compose deployment starts the api, worker, web and plugin daemon services alongside PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. The documented minimum is 2 CPU cores and 4 GB of RAM, with Docker Compose 2.24.0 or later. Plan for more than one application container and check that your hosts can run the sandbox and proxy containers without weakening your network policy. Count every container as something you patch and monitor.
Flowise's Node.js server and UI
Flowise is a monorepo with a Node.js server, a React UI and a components package of third-party node integrations. You can install it with npm on Node.js 20 or later or run it with Docker Compose. The footprint is smaller than Dify's, but every node integration ships in one codebase, so a component issue can affect the whole server. Confirm which Node.js runtime your image and security baseline support before you build.
Database choices in each
Dify's metadata database defaults to PostgreSQL, with MySQL or OceanBase as alternatives. Flowise defaults to SQLite when no database variables are set, and supports MySQL, PostgreSQL and MariaDB. A production Flowise install should move off SQLite before it holds shared flows and credentials. Check that your database team can back up and restore whichever engine you choose, because that choice shapes recovery work more than the app does.
Vector store and file storage in Dify
Dify's vector store defaults to Weaviate, with Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch as options. File storage can use OpenDAL, S3-compatible storage, Azure Blob or Google Cloud Storage. Choosing a non-default vector store or object store means a second system to back up, size and secure. Flowise leaves vector and file storage to the flows you build, so you will need to design that layer yourself in either case.
Patching Dify versus an archived Flowise
Dify publishes minor releases roughly monthly, with 1.16.0 on July 17, 2026 and 1.17.1 on September 10, 2026, and its 1.16.1 notes describe security changes such as agent sandbox network isolation. Flowise's repository is archived and read-only, so no core-team fixes will arrive. Teams running Flowise must either fork and maintain the code or migrate. An archived install carries its known issues forward unless you own the patches.
Day-two checks to run before choosing
Before you commit, confirm who will apply upgrades, how long a restart takes and whether secret keys can be rotated safely. Dify warns that changing SECRET_KEY after deployment logs out all users, so plan that change as a maintenance event. For Flowise, check whether a fork will be maintained inside your team and who owns its database migrations. Ask any implementation partner to put these responsibilities in the written scope.
Dify and Flowise side by side on the features that decide the choice
This table compares the capabilities that usually settle a Dify or Flowise shortlist, using only the facts available for each project. Read the maintenance row first, because it changes the answer for any team that would otherwise run Flowise in production. Where a row says to confirm, check the repository or ask the vendor before you commit.
| Capability | Dify | Flowise |
|---|---|---|
| Release and maintenance status | Active. Dify 1.17.1 released September 10, 2026, with minor releases about monthly | Archived read-only on August 13, 2026. Last release flowise@3.1.4 on July 29, 2026, no core-team fixes |
| License | Modified Apache License 2.0 (Dify Open Source License) | Apache 2.0, with commercial license for enterprise code |
| Enterprise code location | Enterprise features sold as Dify Enterprise, separate from the community edition | Under packages/server/src/enterprise and files with explicit copyright notices such as IdentityManager.ts |
| Database options | PostgreSQL (default), MySQL or OceanBase | SQLite, MySQL, PostgreSQL or MariaDB |
| Default database | PostgreSQL | SQLite when no database variables are set |
| Vector store options | Weaviate (default), Qdrant, Milvus, pgvector, OpenSearch, Elasticsearch | Confirm the supported vector stores in the Flowise repository before planning |
| File storage options | OpenDAL, S3-compatible, Azure Blob, Google Cloud Storage and others | Confirm storage options in the repository or with the vendor |
| SSO and identity protocols | Dify Enterprise only: OpenID Connect, SAML, OAuth2 with Entra ID, Okta, GitHub | Confirm SSO support and any enterprise-only identity features in the repository |
| Workspace model | Community edition limited to one workspace; Enterprise adds multiple workspaces | Confirm tenancy and user role depth in the repository or with the vendor |
| Kubernetes deployment | Dify Enterprise only, for high availability | Confirm deployment options in the Flowise docs, since no Kubernetes fact was supplied |
| Hosted offering | Dify Cloud with paid Professional and Team plans | Flowise Cloud alongside self-hosted deployments |
What each license allows and what is paid for
Dify's source is released under the Dify Open Source License, a modified Apache License 2.0. Most Apache terms still apply, but two conditions are added. The self-hosted Community edition is free and limited to a single workspace. The self-hosted Enterprise edition is custom priced and is the paid route for teams that need more than one workspace or the enterprise features listed below.
- Multi-tenant operation: Running a multi-tenant environment from the Dify source, where one tenant is one workspace, requires written authorization from LangGenius.
- Console branding: Removing or modifying the logo or copyright information in the Dify console is prohibited.
- Community edition: Free to self-host and limited to one workspace, with no SSO, multiple workspaces or commercial license included.
- Enterprise edition: Custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Ask for a quote based on your written scope.
The Dify pricing page lists Dify Cloud plans at 590 US dollars per year (Professional) and 1,590 US dollars per year (Team), but those are cloud plans and do not price the self-hosted Enterprise edition. Check the LICENSE file in the Dify repository and confirm with LangGenius whether your planned use counts as multi-tenant before you deploy.
Most Flowise code is under Apache 2.0, which permits self-hosting and modification. Some code is not. Content under the enterprise directory and files with an explicit copyright notice are under a commercial license, so a self-hosted install can contain code you may not use without a commercial agreement. The repository is archived, so these terms remain, but no core team releases or security fixes come from FlowiseAI after August 2026.
- Apache 2.0 core: The rest of the code, including the server, UI and components package, is Apache 2.0 according to LICENSE.md.
- Enterprise directory: Content under packages/server/src/enterprise is commercial, so features there need a commercial agreement.
- Notice-marked files: Files with an explicit copyright notice, such as IdentityManager.ts, are commercial even when they sit outside that directory.
- Forking: The Future of Flowise announcement encourages teams to fork the repository for internal updates or to join community-led forks, which makes ongoing maintenance your responsibility.
Map every file you deploy against LICENSE.md before you rely on any enterprise feature, and record which files fall under commercial terms.
The Flowise README points to a separate Flowise Cloud hosted offering alongside self-hosted deployments in your own infrastructure. A hosted service is a different arrangement from the open-source repository, so the self-hosting license terms do not describe what you receive from it. The sources for this page do not state Flowise Cloud pricing, data terms or update commitments, so those need to come from the vendor.
- Separate offering: Flowise Cloud is a hosted option distinct from the self-hosted repository described in the README.
- Data location and processing: Hosting is with the vendor, so data residency, retention and processing terms sit in that agreement and the repository license does not cover them.
- Updates and support: Confirm whether the hosted service receives updates and fixes now that the open-source repository is archived.
- Pricing and terms: Request pricing and service terms in writing before comparing hosted costs with the effort of running Flowise yourself.
Before you treat Flowise Cloud as a route around the archive, get its service terms, data processing terms and update commitments in writing and review them against your compliance obligations.
A summary of license terms is not a legal opinion. Both projects combine a permissive base license with added conditions, and the terms that matter for your deployment sit in specific files. Ask counsel to read each file named here and to confirm how your planned use fits within them.
- Dify files: Read the LICENSE file in the langgenius/dify repository for the multi-tenant and console branding conditions.
- Flowise files: Read LICENSE.md in the FlowiseAI/Flowise repository for the enterprise directory rule and the notice-marked file rule.
- Usage facts: Give counsel your planned number of workspaces, whether the platform serves external customers, and whether you intend to change branding.
- Forks and modifications: Note whether you plan to fork or modify either project, since changes carry the same license conditions with them.
Obtain counsel's written reading of both license files before procurement, and keep it with the written scope agreement for the project.
What drives the running cost of each platform
Running cost for Dify and Flowise is set less by the license than by the services each one starts, the skills your team needs to operate it, and how often you must absorb upgrades. The cards below cover each driver and what to request in a written quote.
Infrastructure footprint for Dify
The Dify Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM, and the stack also starts PostgreSQL, Redis, Weaviate, Nginx and a code sandbox alongside the API, worker and web services. Those supporting containers are the main reason Dify needs more capacity than a single Node process. Ask for sizing based on your expected user count, knowledge base size and whether you change the default Weaviate vector store.
Lighter Node footprint for Flowise
Flowise runs as a Node.js server with a React UI and can start on SQLite, which is the default when no database variables are set. Moving to MySQL, PostgreSQL or MariaDB adds a database service you must back up and patch. Your footprint therefore depends mostly on the database you choose and the load your flows place on the server, so confirm both before you size hosts.
Docker and Compose skills for Dify
Operating Dify means maintaining a multi-container Compose stack, including the database, cache, vector store, reverse proxy and sandbox, plus the environment variables that control them. Your platform team needs to handle image pulls, volume backups and the SECRET_KEY setting, since changing that key after deployment logs out all users. Budget for this operational work even when the software itself is free.
Node.js and npm skills for Flowise
Flowise is installed with npm on Node.js 20 or later or run with Docker Compose, so the people who support it need Node runtime management and dependency upkeep. If your team already runs Node services, this lowers the learning curve. If no one on the team has that skill, the cost lands on the engineers who must maintain the Flowise code themselves once the core team has stopped.
Fork maintenance for Flowise
The Flowise repository is archived and read-only, so no security fixes or issue triage come from the core team after August 2026. Any patch you need must come from your own fork or a community-led fork, which means someone must track upstream changes and test them against your flows. Ask a partner to quote this ongoing patch work as a separate line item from the initial setup.
Upgrade cadence for Dify
Dify shipped minor releases roughly monthly, including 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Each upgrade needs regression testing of your workflows and knowledge bases, so frequent releases create recurring effort even though they bring security and feature fixes. Plan a standing upgrade window and ask for it to be included in any retainer scope.
License fees and paid tiers
The self-hosted Dify Community edition is free and limited to a single workspace, while Dify Enterprise is custom priced and adds SSO, multiple workspaces and professional support. The Dify pricing page lists Dify Cloud Professional at 590 US dollars per year and Team at 1,590 US dollars per year, but those are cloud plans, not self-hosting costs. Confirm which tier your use case needs before you compare totals.
What to ask for in a quote
Ask for a written scope that separates one-time work from recurring work: the initial deployment, the integration with your identity provider and model endpoints, the upgrade and patch cadence, backup and restore testing, and support hours. For Flowise, also ask who owns the fork and how upstream security changes are tracked. DeployOpen does not publish a price list, so the quote follows from that written scope.
What the Flowise archive means for existing installs
The Flowise archive changes who patches your installation. Maintainers announced a code freeze on July 29, 2026, archived the GitHub repository to read-only on August 13, 2026, and ended core team presence on August 31, 2026. An existing Flowise install keeps running, but no further releases, security fixes or issue triage will come from the FlowiseAI core team. The last release, flowise@3.1.4, dates from July 29, 2026, so any vulnerability found after that date will stay open unless your own team or a fork closes it. Read the Future of Flowise discussion before you decide, because it is the primary statement of this status.
Flowise is a builder that often sits in front of models, data connectors and API keys, so an unpatched internet-facing instance carries more risk than a static internal tool. Start by inventory: list every Flowise host, whether it is reachable from outside your network, which credentials and database (SQLite, MySQL, PostgreSQL or MariaDB) it holds, and which flows call external tools. Then record a written risk decision signed by the system owner and security. If you continue temporarily, name the compensating controls (network restriction, authentication in front of the UI, credential rotation) and a review date. Set a retirement date that is tied to the Dify migration plan, not an open-ended continuation.
The source remains on GitHub under Apache 2.0, and the maintainers encourage teams to fork it. A fork is viable only if someone owns it: who applies upstream changes, who updates Node.js and npm dependencies, who triages vulnerability reports and who ships internal builds. Also check the license boundary. Flowise's LICENSE.md places code under packages/server/src/enterprise and files with explicit copyright notices, such as IdentityManager.ts, under a commercial license, so a fork cannot simply reuse those parts. Any enterprise features you rely on need a confirmed license position with the copyright holder before you copy them. Confirm these points with your legal team, then decide between a maintained fork and migration.
Moving flows from Flowise to Dify in a safe order
This sequence moves existing Flowise flows to Dify without cutting over production first, so each flow, credential and dataset is inventoried, rebuilt and tested before users move and the old install is retired.
Inventory flows, nodes, credentials and data stores
Your platform or security engineer lists every chatflow and agentflow in the running Flowise install, along with the node types each one uses, the model and tool credentials it holds, the database Flowise writes to (SQLite, MySQL, PostgreSQL or MariaDB), and every vector store, file source and external API it calls. Record the owner and the business use of each flow. The step is done when the list is reviewed by the flow owners and nothing in production is unaccounted for. Confirm the export options for your Flowise version in your own environment before assuming any flow definition can be pulled out as a file.
Decide which flows to rebuild or retire
The product owner and the flow owners sort the inventory into three groups: flows still in active use that justify rebuilding, flows that duplicate something already served elsewhere, and flows nobody has called in a long time. Retire the last two groups with a written decision and a named approver. Keep the rebuild list short enough that the team can test each item. The step is done when every flow has a recorded decision. Because Flowise is archived and gets no further security fixes, treat any flow that depends on a Flowise component with a known problem as a priority to rebuild or retire first.
Stand up Dify in a non-production environment
The platform team deploys Dify with the Docker Compose stack in a separate non-production environment, using the minimum host sizing in the Dify documentation as a starting point (at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later). The stack starts PostgreSQL, Redis, Weaviate, Nginx and the code sandbox alongside the API, worker and web services. Set
SECRET_KEYbefore first use, because changing it later logs out all users. The step is done when the console loads, a test account can sign in and the containers report healthy. Size the host against your own workload, since the documentation sets only minimums.Rebuild and test flows as Dify apps
Builders recreate each approved flow as a Dify workflow or chat app, and re-enter model and tool credentials in Dify rather than copying them from Flowise. For retrieval, decide the vector store first: Dify defaults to Weaviate, and Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch are listed as options in the environment variable reference. Re-index the source documents in Dify's knowledge base, then compare answers from the old and new flows against a fixed set of test questions reviewed by the flow owner. Custom node logic is rewritten by hand, using Dify's tools or code steps where they fit. The step is done when each rebuilt flow passes the agreed test set and the owner signs off.
Migrate data and users in a planned cutover
Move the business data that your source allows, such as exported source documents, reference files and any chat history you have a retention reason to keep, then re-ingest it into Dify's knowledge bases. Rebuild identity wiring from scratch: Flowise access controls do not carry over, so map users to Dify workspace roles and, if you use single sign-on, confirm the protocol and identity provider against the Dify Enterprise SSO documentation before you rely on it. Schedule the cutover with the flow owners, freeze changes to the Flowise flows during the window, and keep the Flowise install read-only as a fallback. The step is done when users sign in to Dify, the rebuilt flows answer the test set and no users remain on the old endpoints.
Retire the Flowise install with a documented decommission
After the agreed fallback period, the platform team removes the Flowise containers or processes, revokes and rotates every credential that was stored in the old install, and deletes or archives the Flowise database under your data retention policy. Record what was retired, where the exported data went, and which credentials were rotated. Keep a copy of the decommission record with the change management tickets. The step is done when the record is signed off and no Flowise endpoint, secret or database remains in use. Check any compliance evidence you need for the decommission with your assessor or certification body, because DeployOpen prepares records but does not issue assessments.
Where Dify and Flowise implementation projects usually run long
Dify projects tend to run long in three places: sizing the Compose stack, wiring secrets and outbound traffic, and deciding the production stores before anyone builds flows. The Docker Compose deployment starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, so the minimum of 2 CPU cores and 4 GB of RAM is a starting point, not a production sizing. Set SECRET_KEY before the first user logs in, because changing it after deployment logs out all users and affects OAuth credentials. Decide early whether workspace encryption keys stay local or move to Azure Key Vault, and confirm who owns that key lifecycle. Check the SSRF_PROXY rules against the internal endpoints your flows must call, since the proxy blocks internal and private IP ranges by design. Choose the metadata database (PostgreSQL is the default), file storage and vector store (Weaviate is the default, with Qdrant, Milvus, pgvector and others as options) before loading knowledge bases, because migrating vectors later means re-indexing. If you need SSO through OpenID Connect, SAML or OAuth2, that identity wiring sits in Dify Enterprise, so price it into the scope.
Flowise projects run long for different reasons. The database choice comes first: SQLite is the default when no database variables are set, which is fine for a proof of concept but needs a deliberate move to MySQL, PostgreSQL or MariaDB before shared production use. Custom node work is the second risk, because the components package holds third-party integrations and any in-house node has to be built, tested and kept compatible with a Node.js server and React UI that no core team will change. Enterprise code paths under packages/server/src/enterprise are commercially licensed, so confirm which features your team relies on before assuming the Apache 2.0 code covers them. The largest ongoing cost is the fork: with the repository archived, every security patch, dependency update and Node.js upgrade becomes your team's job, and someone must own that calendar.
Across both platforms, projects overrun at the same three points: rebuilding flows on a new platform, wiring identity and access, and testing data migration. Flow rebuilds take longer than the node-by-node mapping suggests, because prompts, retrieval settings and tool connections need re-validation against real questions. Identity wiring takes longer when roles must map to workspaces or web app access. Migration tests fail when nobody has realistic test documents and expected answers. The client team must name a product owner for each flow, supply representative test data and sample questions with expected answers, and grant the access needed to staging systems and identity providers. Ask any implementation partner to write these into the fixed scope before work starts.
Questions buyers ask before choosing Dify or Flowise
Is an existing Flowise install safe to keep running?
It can keep running, but it no longer gets core-team releases, security fixes or issue triage, so you carry that risk yourself. The Flowise repository was archived to read-only on August 13, 2026, and the core team ended its presence on August 31, 2026. The last release, flowise@3.1.4, was published on July 29, 2026. The code remains Apache 2.0, so you can fork it, but the enterprise paths under packages/server/src/enterprise and files with explicit copyright notices, such as IdentityManager.ts, fall under a commercial license. Start by recording which Flowise version runs, limiting network exposure, reviewing the credentials stored in its database, and setting a dated plan to migrate or fork. Have your security team confirm your exposure before deciding.
How much effort does moving Flowise flows to Dify take?
The effort scales with how much of your Flowise setup is custom, so inventory those items before asking for a quote. The main drivers are:
- Flow count and complexity: each chatflow or agent flow must be rebuilt on Dify's canvas and tested against the same inputs and expected outputs.
- Custom nodes and integrations: any Flowise component from its components package that has no Dify equivalent needs a replacement tool or custom build.
- Vector stores and data volume: Dify defaults to Weaviate and also supports Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch, so changing stores or re-indexing large document sets adds work.
- Databases and secrets: Flowise may run on SQLite, MySQL, PostgreSQL or MariaDB, while Dify's metadata database is PostgreSQL by default. Model keys and credentials must be re-entered and stored properly in the new system.
Can Dify Community serve several teams from one install?
No, the free Community edition is limited to a single workspace, so a shared install for several teams needs a different plan. Your options are Dify Enterprise, which adds multiple workspaces, SSO and multi-workspace management, or separate Community installs, one per team. Enterprise is custom priced and quoted separately. Separate installs multiply the hosting, database, vector store, upgrade and secrets work, so count that recurring effort. The Dify license also forbids operating a multi-tenant environment from its source without written authorization, where one tenant is one workspace, so do not assume a shared multi-workspace setup on Community is permitted. Confirm the position with LangGenius in writing.
Can our team run Dify ourselves, and what skills does it need?
A team with container operations experience can run the Community edition, but the work continues after launch. The Docker Compose deployment asks for at least 2 CPU cores and 4 GB of RAM, plus Docker Compose 2.24.0 or later. It starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. The skills you need include:
- Docker and Compose operations, including upgrades and rollbacks
- PostgreSQL backup and restore, plus storage for uploaded files
- TLS, reverse proxy and network controls for the sandbox and outbound requests
- Secret handling, since changing SECRET_KEY after deployment logs out all users
- Monitoring, model provider configuration and someone who reads release notes
Dify's minor releases arrive roughly monthly, with 1.16.0 on July 17, 1.17.0 on August 25 and 1.17.1 on September 10, 2026, so assign an owner for patching.
What should a quote for a Dify or Flowise migration include?
A quote should follow from a written scope that names every flow, integration, environment and data source in the migration. DeployOpen plans most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts, and does not publish a price list. Ask the quote to cover a flow inventory with a rebuild and test plan for each flow, replacements for custom nodes, the vector store and data migration, the hosting design inside your own infrastructure, SSO and access setup, secrets and backups, hardening and documentation, and the upgrade plan. Also ask it to separate one-time work from recurring costs such as Enterprise licensing, infrastructure and any retainer, and to list assumptions, exclusions, your responsibilities and acceptance criteria.
What should we ask a partner about supporting a Flowise fork?
Ask who owns the fork, which upstream release it starts from and who ships security fixes after that. Put these questions in writing:
- Baseline: which commit or release the fork starts from and whether it includes everything in flowise@3.1.4.
- Fix ownership: who triages vulnerabilities, how patches are tested and deployed and who handles upstream dependency changes.
- Licensing: how the fork treats the commercial enterprise paths and files with explicit copyright notices, which Flowise's LICENSE.md separates from the Apache 2.0 code.
- Upgrade path: how future upstream changes are merged and how divergence is documented.
- Exit: whether you receive the full repository, build scripts and documentation if you leave.
DeployOpen offers ongoing support and upgrades as retainers, but confirm in writing whether any partner, including DeployOpen, covers fork maintenance and what that scope includes.
How DeployOpen helps choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Dify vs Flowise, we start with your current Flowise estate, licensing questions and target architecture, then agree the path in writing before any work begins.
How we scope
- We inventory existing Flowise installs, flows, custom nodes and database backends before recommending a path.
- We confirm which enterprise-licensed code paths your deployment touches, so license questions are settled early.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We rebuild priority flows in Dify and document each mapping from Flowise nodes to Dify workflow components.
- We configure Dify's self-hosted services, including PostgreSQL, Redis, Weaviate and the code sandbox, inside your environment.
- We run security testing on the built applications and APIs, including the agent sandbox and outbound request controls.
How we hand over
- You receive architecture, deployment and configuration documentation covering the Dify stack and its secret and key handling.
- We document the Flowise decommissioning steps, data retention decisions and any fork or internal maintenance plan you choose.
- Handover includes runbooks for backups, upgrades and the Docker Compose or Kubernetes deployment you select.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can track Dify minor releases and review each upgrade against your flows and security configuration.
- Quotes follow from the written scope, so you can compare the one-time migration work with any recurring support.
