12 Best Open Source Chatbot Frameworks in 2026

There is no single best choice among chatbot frameworks. Start with the product layer you need, then check the exact source repository, license, maintenance path, and deployment model. This guide preserves the original 12 names and their order, but the list is a status inventory, not a ranking or a claim that every entry is a current open-source framework.

Five entries have enough repository, license, and product-fit evidence for a fuller framework/library profile; the other seven are labeled as legacy, hosted, low-activity, or unverified. The source review was checked on November 3, 2026. It is desk research, not a hands-on product test or benchmark.

What Counts as an Open-Source Chatbot Framework?

An open-source chatbot framework is reusable software for building conversational applications under a license that meets the Open Source Definition. The license must allow people to use, study, modify, and redistribute the covered software. A public GitHub page is not enough: check the license file for the exact repository, release, or package you intend to use. The Open Source Definition is the reference for that distinction.

“Framework” also describes a product role, not a license. A framework or library gives developers building blocks for dialogue, message handling, or language processing. A visual builder packages a workflow editor. A chat interface lets people use a model through a UI. An LLM or RAG framework assembles model, retrieval, and tool steps. For the user-facing application, see our guide to what a chatbot is and how it works. Our conversational AI vs. chatbot comparison explains the broader relationship between those terms. These components may support a chatbot, but they do not automatically provide the same conversation management, channels, or user interface.

• License: What exact code is open-source, and under which license?
• Product layer: Is it a framework, library, builder, hosted API, chat UI, or LLM/RAG component?
• Deployment: Can this exact version be self-hosted, or is the product managed by a vendor?
• Maintenance: Who ships fixes, security updates, and supported releases? A recent repository push is a signal, not a support guarantee.

Open-source licensing and self-hosting are separate questions. A license can grant rights to source code without making a vendor’s hosted service available for local deployment. Conversely, self-hosting a public package does not transfer responsibility for upgrades, security, monitoring, backups, and incident response away from your team.

Related reading:

• 11 Best AI Chatbot Platforms to Use for 2026
• AI Chatbot Development: Types, Process, Costs, And Use Cases
• AI Chatbot Integration: A Practical Guide to Connecting Your Systems

How the 12 Entries Were Checked

The five fuller framework/library profiles are Rasa Open Source, BotMan, ChatterBot, DeepPavlov, and Tock. The other seven original names remain in the list with explicit lifecycle or product-boundary labels. We checked official repository, license, documentation, and maintenance material available on November 3, 2026; where an exact repository or license could not be verified, the entry says so instead of treating it as open source.

• Identity and license: match the named project to its official repository and inspect the license shown for that code.
• Product role and deployment: use the project documentation to tell a dialogue framework or library from a hosted service, chat UI, or LLM/RAG component.
• Maintenance and support: check current release or policy information and use repository activity only as a dated signal, not as a support guarantee.

The 12 entries follow the original article’s order and are not ranked. No products were installed or tested, and this review does not score answer quality, security, performance, pricing, or enterprise readiness. Validate those requirements in a sandbox before choosing.

Full 12-Entry List: Frameworks, Hosted Services, and Legacy Tools

The table retains all 12 names. “Status” separates a project’s license from its current product, maintenance, or deployment boundary. A name in the list is not an endorsement for a new build.

The original 12 chatbot-related entries, with license and lifecycle status checked November 3, 2026

# / Name	Product type and license	Status on review date	Potential fit	Check before adoption
1. Rasa Open Source	Conversational AI framework; Apache-2.0	Community patch/support boundary differs from commercial subscriptions; Rasa Open Source 3.6.x maintenance dates have passed.	Existing dialogue systems or teams that can own maintenance.	Exact edition, release policy, patch owner, and migration path.
2. Botpress	Current repository packages: MIT; legacy v12: AGPL-3.0; Cloud is a separate product.	Product and deployment boundary; v12/self-hosted versions are not available for new deployments per the vendor notice.	Teams evaluating a particular repository package or the hosted builder.	Do not infer Cloud licensing or self-hosting rights from the current repository license.
3. Microsoft Bot Framework / Azure AI Bot Service	Bot Framework SDK: MIT; Azure hosted service is a separate product.	SDK repository archived and unmaintained; support-ticket window ended December 31, 2025.	Existing SDK deployments and migration planning.	Check the SDK lifecycle separately from Azure service availability.
4. Botkit	JavaScript conversational toolkit; MIT.	Official repository archived September 20, 2024.	Understanding or maintaining an existing Botkit system.	Assign dependency/security ownership and assess migration before a new deployment.
5. BotMan	PHP chatbot library; MIT.	Repository last pushed April 3, 2026; activity is not a support guarantee.	Adding bot logic to an existing PHP application.	Check driver, PHP, and package compatibility for required channels.
6. Bottender	JavaScript conversational-app framework; MIT.	Repository last pushed April 10, 2024; not by itself proof of abandonment.	A JavaScript team checking a code-first bot integration.	Verify runtime versions, channel APIs, and maintainer activity.
7. Claudia Bot Builder	AWS/serverless bot builder; MIT.	Repository last pushed April 7, 2022; historical/low-activity pending compatibility checks.	Reviewing an existing AWS Lambda bot integration.	Confirm supported runtimes, dependencies, and a maintenance owner.
8. DeepPavlov	NLP framework with conversational components; Apache-2.0.	Repository last pushed August 6, 2025.	Building a custom NLP pipeline.	Plan model serving, application UI, state, dependencies, and maintenance.
9. Tock	Conversational AI toolkit; Apache-2.0.	Repository activity observed November 2, 2026; activity is not a support commitment.	Teams mapping controlled dialogue flows or optional retrieval to a bot.	Verify current channel, model, storage, deployment, and monitoring documentation.
10. OpenDialog	Product/platform identity and exact license not verified in this review.	Unverified; not counted as an eligible open-source framework.	Keep only as a name to investigate, not a recommendation.	Map the official repository, license, hosting model, and maintenance source first.
11. ChatterBot	Python conversational dialogue library; BSD-3-Clause.	Repository activity observed November 1, 2026; activity alone does not establish production suitability.	Learning, experiments, or a small dialogue prototype.	Test answer behavior and add a separate UI, access control, data refresh, and escalation path as needed.
12. Wit.ai	Hosted NLP service; not a self-hosted chatbot framework. Public-repository license metadata was not found in this review.	Hosted-service/open-source boundary unverified; do not count it as a FOSS framework.	Consider only in a separate hosted NLP service comparison.	Check service terms, data handling, portability, and API lifecycle.

License labels apply only to the named repository or version. They do not prove that a hosted product is open source, self-hostable, maintained, or suitable for a regulated workload. Check the exact release and support terms before committing.

What Each of the 12 Names Actually Offers

The profiles follow the original order. The five fuller framework/library profiles have an identifiable repository and license in this review; the other entries explain a product boundary or lifecycle caveat. Choose only after checking the exact version, deployment, support owner, and use case.

1. Rasa Open Source for Existing Dialogue Systems

Rasa Open Source’s repository lists Apache-2.0 and describes a conversational AI framework for NLU, dialogue management, and integrations. Keep the product boundary explicit: Rasa Open Source is not interchangeable with Rasa Pro, CALM, or the broader Rasa Platform.

The maintenance caveat changes the decision. Rasa’s release and maintenance policy says its standard maintenance dates apply to commercial subscriptions and community users should not expect the same commitment to software or security patches. For Rasa Open Source 3.6.x, the policy lists end-of-maintenance on July 3, 2024, and end of technical support on January 3, 2025. A repository can remain public and licensed while the team still needs its own patch and upgrade plan.

For an existing deployment, inventory custom actions, integrations, and data flows before deciding whether to keep, migrate, or maintain a fork. For a new build, treat Rasa Open Source as a maintenance-sensitive option rather than assuming that the Apache license includes vendor support.

2. Botpress: Current MIT Packages, Legacy v12, and Cloud

The current Botpress repository identifies its packages as MIT-licensed. That repository does not establish that the entire Botpress Cloud product is open source or self-hostable. Legacy Botpress v12 is a separate AGPL-3.0 project, and the vendor’s v12 notice says self-hosted versions are no longer available for new deployments.

Before choosing Botpress, write down whether the requirement is to use a current MIT package, maintain an existing v12 installation, or buy the hosted Cloud product. If a new self-hosted chatbot is mandatory, do not treat the MIT package repository as evidence that the full Cloud builder can be deployed locally.

3. Microsoft Bot Framework / Azure AI Bot Service: Legacy SDK Boundary

The Microsoft Bot Framework SDK repository is archived and says the SDK is no longer maintained. Microsoft’s lifecycle notice states that support-ticket submissions ended on December 31, 2025. This makes the SDK a legacy and migration consideration for existing bots, not a current open-source pick for a new build.

Keep the SDK and Azure AI Bot Service separate in any architecture decision: an archived developer SDK does not by itself establish the lifecycle of every hosted Azure service. For an existing implementation, inventory channels, adapters, credentials, and custom code, then assign an owner to validate the supported replacement path.

4. Botkit: Archived JavaScript Toolkit

Botkit’s official repository is MIT-licensed and was archived on September 20, 2024. It remains useful as a reference when a team needs to understand or maintain an existing JavaScript bot, but the archived repository should not be presented as an actively maintained framework for a new production system.

If you inherit a Botkit application, identify its runtime and channel dependencies, check for security fixes in the packages it uses, and document who will maintain a fork or migration. A familiar JavaScript API is not a substitute for a supported upgrade path.

5. BotMan for PHP Applications

BotMan’s source repository describes a framework-agnostic PHP library for building chatbots and lists an MIT license. Its natural fit is a team that already owns a PHP service and wants to add bot behavior in the same stack, rather than adopt a separate hosted platform.

For example, an online shop could use BotMan to receive a “Where is my order?” message and route it to an authenticated backend. The application must verify that the signed-in customer owns the order before returning its status. BotMan does not remove the need to write that authorization check, connect the data service, handle errors, and provide a human fallback.

Review the official BotMan driver documentation against the channels and framework versions in your project. The repository’s last push was April 3, 2026; that recent activity is useful context but does not establish a support commitment for every driver.

6. Bottender: JavaScript Framework with an Activity Caveat

Bottender’s repository describes an MIT-licensed framework for conversational applications in JavaScript. It may be relevant to a team investigating code-first bot integrations in a JavaScript stack, but the repository was last pushed on April 10, 2024 in this review. That date is an activity signal, not proof of abandonment or support.

Before a new deployment, test the exact release against your Node.js version and required channel APIs, review unresolved issues and dependency health, and decide who will own fixes if a platform changes its integration.

7. Claudia Bot Builder: Historical AWS/Serverless Option

Claudia Bot Builder’s repository is MIT-licensed and positions the project around building bots with AWS Lambda. The repository was last pushed on April 7, 2022 in this review, so treat it as a historical or low-activity option until current runtime compatibility and maintenance are confirmed.

For an existing Lambda bot, check the supported Node.js runtime, deployment dependencies, and channel connectors before changing infrastructure. For a new project, name a maintainer who can patch or replace the integration if AWS or a messaging provider changes its APIs.

8. DeepPavlov for Custom NLP Components

DeepPavlov’s repository describes an Apache-2.0 NLP framework built around modular, configuration-driven models. It includes components for dialogue and chatbot work, but it is better understood as an NLP layer for a custom application than as a ready-made chatbot product with a finished channel UI.

A team might use it to prototype a domain-specific intent or dialogue pipeline, then connect that pipeline to its own API and front end. This gives developers control over the application boundary, while also requiring them to own model compatibility, serving, conversation state, and integrations. The repository’s latest push was August 6, 2025, so check the current Python and model-library requirements and decide who will maintain any pinned dependencies.

Choose it when those NLP building blocks match a concrete requirement. If the project only needs a FAQ widget or a managed knowledge assistant, the additional pipeline and serving work may not earn its cost.

9. Tock for Controlled Flows and Optional RAG

Tock’s repository identifies it as an Apache-2.0 conversational AI toolkit. Its official documentation describes two useful patterns: controlled journeys written by a team, and answers generated from retrieved documents with an LLM. A project can use either pattern or combine them.

This can fit a support assistant that needs predictable steps for account changes but also answers questions from a maintained policy library. The flow can keep consequential actions on explicit paths while retrieval handles open-ended questions. Teams building that pattern can follow the practical steps for building a RAG chatbot. Your team still needs to configure the model and document sources, control access to sensitive data, test out-of-scope questions, and operate the required services. A toolkit’s ability to connect channels or models is not evidence that a particular integration meets your production requirements.

The repository had a push on November 2, 2026. Treat that as a fresh activity signal, not a guarantee of security response or long-term support. Before adopting Tock, map every required channel, model provider, document store, and monitoring component to the current documentation and your team’s operational skills.

10. OpenDialog: Repository and License Not Verified

This review could not map “OpenDialog” in the source list to an exact official repository, license, deployment model, and current maintenance source. The name therefore remains in the 12-entry inventory, but it is not counted as a verified open-source chatbot framework and is not recommended here as a current option.

To qualify it for a future comparison, identify the canonical product and repository, inspect the license for the exact code or edition, and confirm whether the relevant deployment is self-hosted or vendor-managed. Until those checks are complete, do not use platform-level claims about governance or regulated workloads as evidence.

11. ChatterBot for Small Python Experiments

ChatterBot’s repository identifies it as a Python conversational dialogue engine and publishes a BSD-3-Clause license. Its documentation describes generating replies from collections of known conversations. That makes it useful for learning how dialogue engines work or building a limited prototype around a prepared conversation set.

Imagine a training demo that answers a small set of course questions. A developer can load sample conversations, test varied wording, and inspect whether the reply logic behaves as expected. That demo is not an authoritative customer-support system: answers can be incomplete or stale, and it needs a separate interface, access controls, data refresh process, and escalation path before it can serve real users.

The repository showed activity on November 1, 2026, but activity alone does not prove that the project fits a modern production workload. Pin the version, install it in a clean environment, and test its dependencies and behavior with the data you actually plan to use.

12. Wit.ai: Hosted NLP Service, Not a Verified FOSS Framework

Wit.ai belongs in a hosted NLP-service category, not the self-hosted chatbot-framework shortlist. The public repository reviewed for this audit did not expose license metadata, and that does not establish that the separate hosted API is open source. Keep the service and any client/example code as distinct things.

A team considering Wit.ai should review the service terms, data handling, API availability, and portability of its intent/entity configuration. This entry is retained to preserve the original 12 names; it is not a claim that Wit.ai is an open-source framework.

What Falls Outside the 12-Name List?

Haystack is useful adjacent technology, but it is an LLM/RAG orchestration layer rather than one of the original 12 chatbot-related names. Keeping it separate prevents the list count from drifting and clarifies the product layer it supplies.

Haystack: An LLM/RAG Layer, Not One of the 12 Entries

Haystack’s documentation describes an open-source AI orchestration framework for RAG applications, agents, and search systems. It can supply retrieval and generation pipelines for a chatbot, but an application still needs to connect that pipeline to conversation state, user identity, a chat interface, and any human handoff or business action.

Think of Haystack as a component in the system design, not automatically as a replacement for a dialogue framework or chatbot platform. If you are choosing between adjacent orchestration tools, compare the deployment model and pipeline needs in our Haystack vs. LangChain comparison. Teams building agent-led workflows can also review AI agent frameworks, which serve a related but different task.

How to Choose and Validate a Framework

Choose by the work your bot must do, not by a generic “best” label. A small customer-support assistant and a multi-channel transactional bot need different control, integration, and maintenance choices.

1. Write the user task. State who asks what, which systems the bot may read or change, and when a human must take over.
2. Pick the product layer. Decide whether you need dialogue logic, an NLP component, a visual builder, a chat interface, or an LLM/RAG pipeline. Do not shortlist unlike products in one rank.
3. Verify the artifact. Record the repository URL, release or commit, license, edition, supported runtime, and whether the intended deployment is actually available.
4. Trace the data and actions. Map every API call, knowledge source, permission check, log, and handoff. Keep high-impact actions behind server-side authorization and a reviewable boundary.
5. Run the same acceptance set. Test normal, ambiguous, unauthorized, stale-data, out-of-scope, and failure cases in a sandbox. Record what worked, what the bot refused, and how much engineering and review each option required.

For example, a retailer wants a bot that answers delivery questions and looks up an order. A static policy question can use a retrieval pipeline over approved shipping documents, with links to the passages used. An order lookup must go through the retailer’s authenticated backend and return data only after it checks that the signed-in person owns the order. If the account cannot be verified or the API is unavailable, the bot should stop and offer human help rather than guess. This is an evaluation scenario, not a test result for any framework in this article.

Set pass conditions before the pilot. The bot should follow access rules, answer only from approved sources when the task requires it, refuse or escalate unsupported requests, and expose enough logs for a developer to diagnose a failure. Compare the same cases across candidates; do not choose based on a fluent demo conversation alone.

What Self-Hosting Adds to the Project

An open-source license may reduce software licensing restrictions, but self-hosting adds work and recurring cost. Count the people and services needed to keep the bot reliable, not only the time needed to write its first conversation.

• Runtime ownership: deploy and upgrade the app, database, search index, and channel adapters; monitor availability and restore backups.
• Model and data costs: budget for model or embedding APIs, vector storage, compute, and usage limits. A model’s license and API terms are separate from the chatbot framework’s license.
• Security and privacy: protect credentials, restrict data access by user and tenant, review retention and telemetry, and avoid sending sensitive conversation data to unapproved providers.
• Quality and support: assign an owner for test cases, content updates, incident response, dependency patches, and human escalation. A repository’s license does not promise a maintained service desk.

Compare those responsibilities with a managed service’s terms and controls. Self-hosting can make sense when the team needs control and has the capacity to operate the stack; a managed service can be more practical when the organization prefers vendor-run infrastructure and its data and support terms fit the use case.

FAQs About Open-Source Chatbot Frameworks

These answers clarify product boundaries and operating decisions raised by the 12-entry comparison.

Are all 12 entries current open-source chatbot frameworks?

No. The 12-name list preserves the original entries, while the status labels identify legacy SDKs, an archived toolkit, hosted products, low-activity repositories, and names whose exact license was not verified. Treat only the specifically checked repository/version as open source, and confirm current maintenance before adopting it.

Is Botpress Open Source and Can I Self-Host It?

Check which Botpress product you mean. The current repository lists MIT for its packages; legacy v12 is a separate AGPL-3.0 project; and Botpress Cloud is a managed product. The vendor notice says v12/self-hosted versions are no longer available for new deployments. The current repository’s MIT license does not establish that Cloud can be self-hosted.

Is Rasa Open Source Still Supported?

Rasa Open Source is Apache-2.0, but that license does not guarantee support or security patches. Rasa’s policy says community users should not expect the same patch commitment as commercial subscriptions, and its listed 3.6.x maintenance dates have passed. Check the version and assign a patch or migration owner before using it.

Can Haystack Replace a Chatbot Framework?

Usually not by itself. Haystack can build the retrieval, generation, or agent pipeline behind a conversational product. Your application still needs the conversation interface, user and session controls, channel integrations, and any required handoff or business logic.

Are Open-Source Chatbot Frameworks Free to Run?

The license may allow use without a software fee, but production still costs money. Include hosting, engineering, model and embedding usage, monitoring, security updates, backups, and support in the budget.

Can an Open-Source Framework Be Used in an Enterprise?

Yes, if the exact project and deployment meet the organization’s requirements. Review supported releases, patch ownership, authentication, audit logs, data retention, observability, incident response, and vendor or community support. “Open source” alone is not an enterprise-readiness check.

Before You Commit to a Framework

When comparing open source chatbot frameworks, choose the smallest component that covers the bot’s real user task and has a maintenance path your team can own. Before approval, record the repository and version, license, deployment target, connected data and action permissions, patch owner, and escalation route. Then run the same authenticated, stale-data, unsupported-request, and outage cases against the candidate in a sandbox.

Teams planning a custom chatbot or AI integration can review Designveloper’s AI development services and contact us to discuss scope and requirements.