Rasa Open Source says maintenance mode on its own front page, and its Dockerfile refuses a plain build

The first thing the README tells you is that Rasa is in maintenance mode

A banner at the top of the file states that Rasa Open Source is currently in maintenance mode, and that the future of building AI agents with Rasa is Hello Rasa and CALM. A later section is labelled legacy, covering the channel list and the installation instructions, which the README scopes to the classic framework. The dates back this up in a way the banner does not. The last push to the repository is dated 2026-07-24 and the default branch is 3.6.x, so work is still landing, but the newest tagged release is 3.6.21 from 2025-01-14, with 3.6.20 from 2024-04-18 behind it. A project can push fixes while shipping no new features, and that is the shape to plan around. The versioning policy is spelled out and simple: major for incompatible API changes, minor for backward-compatible functionality, patch for backward-compatible bug fixes, with the full cadence and maintenance policy living on an external site rather than in the repository.

Hello Rasa drops intent training and asks you to write flows instead

The forward path is not a new version of the same authoring model. Hello Rasa is described as an interactive playground for prototyping agents that combines LLM fluency with the reliability of business logic through the CALM engine, expanded as Conversational AI with Language Models. Three claims are worth reading as constraints. No setup required means the work happens in a browser against templates for Banking, Telecom and Support, not in a checkout on your own hardware. No NLU training says the project has moved beyond intents and that the LLM handles dialogue understanding while you define the business flows. Production ready means export to the Rasa Platform when you need to scale. The core concepts make the same shift: flows describe logical steps such as collecting money or transferring funds instead of rigid dialogue trees, and an inspector exposes real-time decision-making with no black boxes. If you are coming from the classic framework, the authoring unit changed, not just the interface.

A plain docker build fails because three arguments have no defaults

The Dockerfile does not resolve on its own. It opens by declaring three arguments and then uses all three in its FROM lines:

ARG IMAGE_BASE_NAME
ARG BASE_IMAGE_HASH
ARG BASE_BUILDER_IMAGE_HASH

FROM ${IMAGE_BASE_NAME}:base-builder-${BASE_BUILDER_IMAGE_HASH} as builder

With no default values and no base image name to fall back on, a bare docker build has nothing to pull, and the Makefile is where the build-docker targets live, which tells you the image is produced through the project's own tooling rather than by pointing a builder at the file. Two more details matter for an operator. The install step inside the builder runs poetry install --no-dev --no-root --no-interaction and then pip install --no-deps dist/*.whl, so the runtime dependencies come from the poetry-managed virtualenv rather than from the wheel's own metadata. And the runner ends with:

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

so the container starts a CLI that prints help, exposes a single port, runs as USER 1001 with HOME=/app, and declares /tmp as a volume. An orchestrator that expects a server on 5005 will get a CLI.

make install is the whole documented install, and macOS gets a compiler workaround

For developers the install path is Poetry plus one make target:

make install

Poetry itself is expected to be installed separately by following the official guide. The macOS note is the interesting part: if you run into compiler issues, try `export SYSTEM_VERSION_COMPAT=1` before installation. That is an admission that a native build step can fail on macOS, and it tells you to relax a system compatibility check rather than fix the toolchain. The same kind of friction is visible in the packaging file, which declares a supplemental package source for internal repository mirroring psycopg binary for macos, pointing at a Python index on europe-west3-python.pkg.dev. The Makefile help also names an install-full target that installs Rasa with all extras: transformers, tensorflow_text, spacy, and jieba. That is four additional machine learning stacks on top of the base install, so the difference between the two targets is not a flag but a large dependency graph. Note that no minimum Python version appears in the README.

Tests require system packages and model downloads before pytest will mean anything

The test workflow is a sequence of make targets rather than a single command, and the sequence matters:

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

A Windows variant, prepare-tests-windows, is listed in the Makefile alongside three model-fetching targets: prepare-spacy to download the models spacy tests need, prepare-mitie to download the standard English mitie model, and prepare-transformers to download everything LanguageModelFeaturizer tests want. So a green test run assumes network access to model sources, and a CI box without that access fails before it reaches your change. make test runs pytest on tests/ and reads a JOBS variable whose default is 1, meaning the suite is single-process unless you opt into workers, which is a large difference in wall clock on a slow run. The static side is separated out: formatter applies black, lint runs ruff and checks whether black should be applied, types runs mypy, and static-checks runs all python static checks. The repository root carries stubs/, .coveragerc, test_environments/ and tests_deployment/, so deployment paths have their own suite.

The wheel ships a config file, an importer set, a schema set and a keys directory

The packaging metadata has an explicit include list, and it is worth reading before you build a derived image:

include = [ "LICENSE.txt", "README.md", "rasa/shared/core/training_data/visualization.html", "rasa/cli/default_config.yml", "rasa/shared/importers/*", "rasa/utils/schemas/*", "rasa/keys",]

Four things follow. First, runtime defaults travel inside the wheel as rasa/cli/default_config.yml, so the behaviour of an installed Rasa comes partly from the package you installed rather than from the directory you cloned. Second, rasa/shared/importers/ and rasa/utils/schemas/ are shipped too, which means the extension surface is importable data and code, not just a plugin hook you configure from outside. Third, rasa/keys is packaged, and any directory like that inside a distributed artifact deserves a look before you push that image anywhere public. Fourth, the training data visualization HTML is baked in. The build backend is poetry-core with poetry-core>=1.0.4 required, and the project version is pinned to 3.6.21 in the same file.

CHANGELOG.mdx is generated from fragments in ./changelog by towncrier

The changelog is not hand written. The towncrier configuration sets package and package_dir to rasa, the output filename to CHANGELOG.mdx, the fragment directory to ./changelog, the template to ./changelog/_template.md.jinja2, the underline style to three spaces, the title format to ## [{version}] - {project_date}, and the start string to <!-- TOWNCRIER -->. Both changelog/ and CHANGELOG.mdx exist at the repository root, alongside the fragment template. For a reader deciding whether to upgrade, that matters: the per-version history you would look for is a generated artifact, and the raw fragments are the working state before a release assembles them. The release numbering lives in the same file as the package metadata, with version = 3.6.21, and the authors are listed as Rasa Technologies GmbH with a maintainer entry for Tom Bocklisch. Licensing is Apache-2.0 with LICENSE.txt at the root, matching the copyright line in the README.

A .env file and an encrypted secrets archive sit at the repository root

The root of the repository carries more than code. There is a .env file, a secrets.tar.enc archive, a security.txt, a trivy-secret.yaml, a CODEOWNERS file, a CODE_OF_CONDUCT.md, a PRINCIPLES.md, and analysis configuration for .codeclimate.yml and .deepsource.toml, plus a .pre-commit-config.yaml and a .typo-ci.yml. Some of that is reassuring: security.txt and trivy-secret.yaml together suggest that disclosure contacts and secret scanning are wired into the workflow rather than being an afterthought, and CODEOWNERS means changes to particular paths expect a particular reviewer. The part to be careful with is .env. Any file you copy from a template into your own deployment can carry values that were never meant to leave an internal checkout, and secrets.tar.enc is only as safe as the key you decrypt it with. There is also a .devcontainer/ directory and a cloudbuild.yaml, which together suggest the maintainers build inside a container and ship through Google Cloud Build. None of that appears in the README.

Editorial conclusion

Rasa fits a team with an existing Rasa deployment that needs to keep an assistant running and patched, or a team that wants a self-hosted NLU and dialogue stack under a permissive license. It is a poor choice for a new agent project, because the README states the project is in maintenance mode, the newest tagged release is 3.6.21 from 2025-01-14, and the pushed-forward path is the hosted Hello Rasa playground with export to the Rasa Platform. Before you start, decide which of those two worlds you are in, confirm your Python version is one the project still supports, and read the build arguments in the Dockerfile before you plan a container pipeline.

Frequently asked questions

Official sources

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