StackStorm

Last reviewed Sep 13, 2026 · 881 words

StackStorm needs 2 GB of RAM, MongoDB, RabbitMQ, Redis and half a dozen of its own services before it runs a single rule. For a homelab that wants "when X happens, do Y", that is the wrong price; n8n does the same job in a tenth of the footprint. StackStorm earns its weight in exactly one situation: an operations team that wants event-driven remediation across real infrastructure, with an audit trail, role-based access and a workflow engine that can retry, branch and pause for approval. If that is you, it is the most complete Apache-2.0 option there is. If it is not, stop here and save yourself an afternoon.

Sensors, triggers, rules, actions: the model in one paragraph

A sensor is a long-running process that watches something (a webhook endpoint, a Prometheus alert, a Git push, a file, a cron schedule) and emits triggers. A rule matches trigger payloads against criteria and fires an action. An action is a script, an Ansible playbook, an HTTP call, a shell command on a remote host over SSH, or a workflow that composes other actions. All of these come bundled in packs, and the StackStorm Exchange has roughly 150 of them covering AWS, Kubernetes, GitHub, Slack, Jira, Nagios, Sensu, vSphere and most of what an ops team already touches. Installing a pack is st2 pack install aws. Writing your own is a directory of YAML metadata plus Python or shell scripts, and that is where most of the value comes from: the built-in packs get you connected, your own actions are the remediation.

What the install actually consists of

The components are st2api, st2auth, st2stream, st2rulesengine, st2sensorcontainer, st2actionrunner (usually several), st2workflowengine, st2scheduler, st2notifier, st2garbagecollector, st2timersengine, plus MongoDB for state, RabbitMQ for messaging and Redis for coordination, with nginx fronting the web UI and API. The one-line installer on a fresh Ubuntu or RHEL VM sets all of this up as system packages and is the path the project recommends. The Docker Compose deployment in the st2-docker repository gives you the same thing as around 15 containers and is what I use for evaluation:

git clone https://github.com/StackStorm/st2-docker
cd st2-docker
docker compose up -d
docker compose exec st2client st2 login st2admin -p 'Ch@ngeMe'

Change that password. The Helm chart is the production route on Kubernetes and the only sane way to run multiple action runners with any elasticity. Whatever the route, treat 2 GB as the floor: MongoDB and RabbitMQ are not shy, and a busy rules engine with 10 sensors idles at more.

The first rule that justifies the platform

The canonical example, and the one I would build first, is alert-driven remediation. A Prometheus Alertmanager webhook posts to StackStorm; a rule matches alertname == DiskSpaceLow and fires a workflow that runs a cleanup action over SSH on the affected host, waits 5 minutes, re-checks the metric, and either resolves the alert or pages a human with the output attached. That workflow is written in Orquesta, StackStorm's YAML workflow language, which supports parallel branches, conditions on task results, retries with backoff and inquiries, which pause execution until someone approves via the CLI or ChatOps. Every execution is recorded with inputs, outputs and timing, and can be replayed. This is the feature set that separates it from a webhook-to-script tool. Nothing in the automation category at the lighter end gives you replayable, approvable, audited workflows without you building them.

ChatOps is real and still used

st2chatops packages Hubot with a StackStorm adapter, so telling the bot deploy myapp staging in Slack or Mattermost runs an action alias with parameters parsed from the sentence, and the result comes back in the channel. In 2026 this feels less novel than it did in 2016, but for teams that live in chat it remains the lowest-friction way to expose safe, parameterised runbooks to people who should not have shell access. Aliases are YAML; access to them goes through StackStorm's RBAC.

Where it loses

Learning curve: packs, actions, runners, rules, sensors, triggers, workflows, aliases, inquiries and RBAC are each a concept with its own YAML shape, and the documentation assumes you will read it. Community velocity is moderate; the project moved to the Linux Foundation in 2019, releases are steady but not frequent, and pack maintenance varies. For job scheduling with a nice UI, Rundeck is simpler. For configuration management with a web front end, AWX is the obvious pick. For personal automation, n8n or Node-RED and no contest. StackStorm's 6,532 stars understate how much of that work is done in companies that never post about it.

What I'd do

Run the st2-docker compose on a 4 GB VM, install the core, chatops and one integration pack for the system you most often fix by hand, and write one remediation workflow end to end, including the inquiry step. If after 2 weeks the audit trail and approval flow are saving your team real pages, move to the Helm chart or a proper package install. If you found yourself thinking "n8n would have done this in an hour", it would have, and you should use it.