Rasa Open Source in Maintenance Mode: What the Classic NLU and Dialogue Stack Still Does

The problem Rasa Open Source was built to solve

Most chatbot tooling starts from a hosted service: you sign in, define intents in a web console, and the vendor owns the model. Rasa Open Source takes the opposite route. It is a Python framework you install yourself, train yourself, and serve yourself, and the README describes it as a machine learning framework for automating text- and voice-based conversations. The audience is teams that need an assistant to handle layered, back-and-forth dialogue rather than a single question and answer, and that need that assistant to run on infrastructure they control.

The repository's own description names the two halves plainly: NLU and dialogue management. NLU is the part that turns a sentence into a structured label (an intent plus entities). Dialogue management is the part that decides what the assistant should do next, given the conversation so far. Both live in the same installable package, and both are configured through files in your project rather than through a hosted dashboard.

The README also lists the channels the framework can speak to: Facebook Messenger, Slack, Google Hangouts, Webex Teams, Microsoft Bot Framework, Rocket.Chat, Mattermost, Telegram, Twilio, and custom conversational channels. That list is the practical boundary of the project. If your users live somewhere else, you are writing a connector.

Intents, stories and rules: how the dialogue loop actually runs

Rasa's architecture separates training data from runtime. Training data is text: example utterances tagged with intents and entities for the NLU model, and dialogue examples (stories and rules) that describe which actions should follow which conversation states. Training produces a model archive. At runtime the server loads that archive and, for each incoming message, runs the message through the NLU pipeline to get an intent and entities, then runs the dialogue policy over the tracked conversation state to pick the next action. Responses come from domain definitions, and the repository ships an example NLG server under examples/nlg_server for teams that want to generate responses outside the framework.

The repository layout reflects this split. The rasa/ directory holds the framework code, examples/ holds complete sample assistants (concertbot, formbot, knowledgebasebot, moodbot, reminderbot, responseselectorbot, e2ebot), and tests/ holds the test suite. The Makefile exposes the developer workflow directly: make install, make test, make lint, make types, and separate targets for downloading spaCy, MITIE and transformer models used in tests. The presence of prepare-mitie and prepare-spacy targets is the clearest signal that the NLU side is pluggable and that some pipelines pull heavy model downloads.

The trade-off is visible in the same files. Because the dialogue policy is learned from stories and rules rather than from a language model's in-context reasoning, the assistant's behaviour is bounded by the examples you wrote. That is the property that makes it auditable, and it is also the reason it cannot improvise its way through a conversation path nobody wrote down.

Installing Rasa Open Source and training a first assistant

The README points installation at the docs site (rasa.com/docs/rasa/installation/environment-set-up) for the released package, and gives source installation for contributors. Rasa uses Poetry for packaging and dependency management, so the contributor path is to install Poetry first and then run the Makefile target.

make install

On macOS the README notes that compiler issues can be worked around by exporting SYSTEM_VERSION_COMPAT=1 before installation. That is the only platform-specific caveat the README gives.

If you want to run the test suite against a source checkout, the README splits preparation by operating system and then runs pytest through the Makefile. The JOBS variable controls the number of workers and defaults to 1.

make prepare-tests-ubuntu # Ubuntu/Debian
make prepare-tests-macos  # macOS
make test

For running the framework itself, the repository ships a Dockerfile. It builds in two stages, installs the wheel into a virtualenv at /opt/venv, drops root by switching to USER 1001, exposes port 5005, and sets the entrypoint to rasa with --help as the default command. That port and entrypoint are the concrete facts to carry into a container deployment.

EXPOSE 5005
ENTRYPOINT ["rasa"]
CMD ["--help"]

A first real use starts from one of the bundled examples rather than an empty directory. examples/formbot, examples/moodbot and examples/concertbot each contain a complete project with training data, so the shortest path to a working assistant is to copy one, run the training command, and watch the server respond. The README does not walk through that command sequence; it defers to the docs site for the full installation and tutorial flow.

Where Rasa Open Source is the wrong tool

The README is unusually direct about its own status. It carries a maintenance mode notice and states that the future of building AI agents with Rasa is Hello Rasa and CALM. It labels the classic framework section as legacy. Whatever the code still does, the project's own front page is telling new readers to start somewhere else.

That has a concrete consequence for anyone planning a long-lived assistant. The most recent release listed in the repository metadata is 3.6.21 from 2025-01-14, with 3.6.20 in 2024-04-18 and 3.6.19 in 2024-03-04 before it. The last push to the repository is dated 2026-07-24, so the tree is not abandoned, but the release cadence shown in the metadata is slow and the README frames the classic stack as the previous generation. A team that needs new NLU capabilities, new channel connectors or a roadmap commitment should read that as a signal, not as background noise.

The other mismatch is architectural. Rasa Open Source expects you to define intents and write dialogue examples. If your users phrase requests in ways you cannot enumerate, or if your product requirement is an agent that reasons over tools and documents at runtime, the intent-and-story model is the wrong shape. The README's own answer to that case is CALM, which it describes as combining LLM flexibility with strict business logic, and Hello Rasa, which it describes as requiring no NLU training because the LLM handles dialogue understanding. Those are the project's words about its own successor, not an independent comparison.

Rasa Open Source against a general-purpose bot framework

The obvious alternative category is a general-purpose bot framework where you write handler functions and the routing is explicit code. In that model there is no training step: a message arrives, your code matches it against whatever logic you wrote, and you return a reply. Nothing is learned, and nothing is inferred.

Rasa Open Source differs in that the matching is a trained model. You supply example utterances per intent, the NLU pipeline generalises from them, and the dialogue policy generalises from stories and rules. That buys you tolerance for phrasing you did not literally write, and it costs you a training pipeline, a model artifact to version and deploy, and a debugging loop that runs through data rather than through a breakpoint. It also means the failure mode is different: a code-based bot fails by falling through a branch you can read, while a trained assistant can classify a message into the wrong intent with high confidence and route the conversation somewhere you did not intend.

Rasa is also not a hosted platform. The README separates the open source framework from the enterprise product and links to the Rasa Platform for teams that want the managed route. If what you actually want is a hosted console with no infrastructure to run, the open source package is not that, and the README's own pointer to the platform is the honest place to look.

Licence, dependency weight and the cost of staying on 3.6.x

Rasa Open Source is licensed under Apache-2.0, and the README states the copyright line as Rasa Technologies GmbH. Apache-2.0 is a permissive licence that allows commercial use and modification, and it includes an explicit patent grant. It also requires that you preserve the licence and notice files when you redistribute. The repository carries both LICENSE.txt and a NOTICE file at the top level, which is what the notice requirement refers to. This is a description of the licence text, not legal advice; if you are redistributing Rasa inside a product, have your own counsel read the terms.

The upgrade cost is the part that is easy to underestimate. The pyproject.toml pins the package version to 3.6.21 and declares a Poetry build backend, so the dependency graph is resolved through poetry.lock. The Dockerfile installs with poetry install --no-dev --no-root and builds a wheel before installing it with --no-deps, which means the image is assembled from the lock file rather than from floating version ranges. The Makefile offers install-full for the heavier extras (the help text names transformers, tensorflow_text, spaCy and jieba), and separate prepare-transformers and prepare-spacy targets exist because those models are downloaded rather than bundled. Running the full test suite needs the OS-specific preparation targets first.

Put together, that means an upgrade is not a single pip command. You move the lock file, rebuild the image, re-download any model assets your pipeline needs, and re-run the suite. On a maintenance-mode project, that work buys you bug fixes rather than new capability, which is the calculation to make before you start.

Editorial conclusion

Adopt Rasa Open Source if you need a self-hosted, Apache-2.0 licensed intent classifier and dialogue policy you can train on your own data, and if you accept that the README places the project in maintenance mode. Do not adopt it for a new greenfield agent that depends on LLM-driven understanding; the README directs that work to Hello Rasa and CALM. Before committing, verify that the Python version on your machines is one the pinned Poetry environment resolves against, and check that the channel you need (Slack, Facebook Messenger, Telegram, Twilio or a custom connector) is still listed in the README's channel list, because that list is the only integration inventory the repository gives you.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. RasaHQ/rasa on GitHub
4. README
5. Releases