Rasa Open Source

Last reviewed Aug 26, 2026 · 838 words

Rasa is the right tool for exactly one kind of assistant in 2026: the one that must do the same thing every time. If "cancel my order" has to call the cancel-order action and nothing else, on a box with no GPU and no API key, Rasa still beats a prompted LLM. If you want an assistant that chats freely about anything, Rasa is the wrong shape; wire Ollama to Open WebUI and be done in an afternoon. The 21,300 stars and the Hard difficulty rating come from the same fact: Rasa is a machine-learning framework, not an app, and you train it yourself.

What you are actually building

A Rasa assistant is two trained models plus a folder of YAML. The NLU model turns a sentence into an intent (cancel_order) and entities (order_id: 4471). The dialogue model decides what happens next from the conversation so far, learned from stories (example conversations) and constrained by rules. Custom actions are Python functions in a separate action server, and that server is where the bot touches your database or API.

rasa init scaffolds the whole thing in about 2 minutes: domain.yml for intents, entities, slots and responses; data/nlu.yml, data/stories.yml and data/rules.yml for training data; config.yml for the pipeline; endpoints.yml and credentials.yml for plumbing. rasa train writes a .tar.gz model into models/, rasa shell lets you talk to it, rasa run --enable-api serves it on port 5005, and rasa run actions serves custom actions on 5055.

The cost is training data, not compute

The 2 GB minimum is honest for serving and for training small bots on CPU; the default DIET pipeline trains a 20-intent assistant in a few minutes on a 4-core VM. Nobody fails at Rasa for lack of hardware. They fail because each intent needs 20 to 50 varied example sentences before the classifier stops confusing it with its neighbours, and stories have to cover the paths real users take, including the awkward ones where they change their mind halfway. Budget a week of writing examples for a modest bot, then keep topping them up from conversation logs. Skip that and the bot feels dumber than a raw LLM and you will blame the framework for a data problem.

Docker layout that survives a restart

Two containers minimum, with the model trained elsewhere and copied in:

services:
  rasa:
    image: rasa/rasa:latest-full
    command: run --enable-api --cors "*"
    volumes:
      - ./:/app
    ports:
      - "5005:5005"
  action-server:
    build: ./actions
    ports:
      - "5055:5055"

Point action_endpoint in endpoints.yml at http://action-server:5055/webhook. The default tracker store is in-memory, so conversations vanish on every restart; for anything real, configure a tracker_store in endpoints.yml backed by PostgreSQL or Redis. Train on your workstation rather than inside the serving container: training pulls in TensorFlow and the heavy Python dependency tree the catalogue warns about, and a 3 GB image restarting on a small server is nobody's idea of fun.

Where Rasa and LLMs meet now

Rasa the company moved its attention to Rasa Pro and its LLM-driven dialogue approach; the open-source repository still trains and still serves, but treat it as stable rather than fast-moving. For a self-hoster the useful hybrid is this: Rasa owns intent routing, slot filling and every action that must be deterministic, and one custom action calls a local model through Ollama for open-ended replies. Money-moving paths stay auditable, small talk stays cheap. The tool-calling patterns post covers the reverse arrangement, where the LLM does the routing and calls your functions; for most new personal projects that is now the simpler build, and Rasa earns its place when you need repeatability, offline operation, or the ability to show exactly why the bot did what it did.

Channels, logs and the bits people forget

credentials.yml connects Slack, Telegram, Mattermost and a plain REST channel; REST plus a small web widget is the least painful route for a homelab. Every conversation lands in the tracker store and becomes your future training data, so export it. And put the YAML in git from day one, because the model is only as reproducible as the data that trained it.

What I'd do

Spend one day with rasa init and rasa shell on a laptop before touching Docker. If the assistant has fewer than 10 intents and no compliance requirement, stop there and build it as an LLM with tool calls instead. If it has a fixed set of transactions, must run air-gapped, or has to behave identically on Monday and Friday, commit: PostgreSQL tracker store, action server as its own container, models trained outside and shipped in, and a quarterly hour reading real logs to top up the NLU examples. Run that way it is boring in the best sense, which is what you want from a bot that cancels orders.