StackStorm/st2 review: event-driven automation for SRE and DevOps teams

What StackStorm/st2 automates that a cron job cannot

The README frames the project as a platform for integration and automation across services and tools, with a particular focus on taking actions in response to events. That framing matters because the hard part of operations automation is rarely the action itself. Restarting a process is a one-line command. Knowing which process, on which host, after which alert, and what to do when the restart fails is the actual problem.

StackStorm is aimed at DevOps engineers and SREs who already have monitoring that produces events: the README names Nagios, Sensu and New Relic as examples. The documented patterns are facilitated troubleshooting, automated remediation and continuous deployment. A representative flow from the README: identify and verify hardware failure on an OpenStack compute node, evacuate instances, email about potential downtime, and if anything goes wrong, freeze the workflow and call PagerDuty to wake a human. That last clause is the design intent. The platform is built for automations that are allowed to stop and escalate, not for fire-and-forget scripts.

If your operational work is a set of shell scripts a person runs after reading an alert, StackStorm adds a service, a database and a message bus to that workflow. The payoff only appears once events outnumber the people watching them.

Sensors, triggers, rules and workflows: the actual data flow

The architecture is described in the README as loosely coupled microservice components that communicate over a message bus. Inbound integration happens through sensors, which the README describes as Python plugins that watch external systems and fire a StackStorm trigger when an event happens. Triggers are the platform's representation of those external events. Some are generic (timers, webhooks); others come from an integration, such as a Sensu alert or a JIRA issue update.

Rules sit in the middle. A rule maps a trigger to an action or a workflow, applies matching criteria, and maps trigger payload data onto action inputs. This is the step where most production mistakes happen. The trigger payload is whatever the sensor emitted, and the rule's mapping is the only thing standing between an alert and the action it starts.

Outbound integration happens through actions, which the README describes as either Python plugins or any scripts, consumed into StackStorm by adding a few lines of metadata. Actions can be invoked directly through the CLI, API or web UI, or called from a rule or workflow. Workflows stitch actions into what the README calls uber-actions, defining order, transition conditions and context passing between steps. The workflow engine is a separate dependency: requirements.txt pins orquesta from its Git repository, so the orchestration layer ships from its own project.

The unit of packaging is the pack, which groups triggers, actions, rules and workflows. The repository description puts the ecosystem at 160 integration packs with more than 6000 actions, distributed through StackStorm Exchange. Every execution, manual or automated, lands in the audit trail with its triggering context and results, and the README notes that trail can be forwarded to LogStash, Splunk, statsd or syslog. A full REST API, a CLI client and a web UI are all listed as ways to operate the service.

Installing StackStorm on a clean Linux host

The README gives one install path: a clean 64-bit Linux box that fits the system requirements, then the installer script. The script takes the admin username and password as arguments. Run it as shown, and expect the installer to report the services it configured and the URL of the web UI when it finishes.

curl -sSL https://stackstorm.com/packages/install.sh | bash -s -- --user=st2admin --password=Ch@ngeMe

That password is the README's own example. Change it before the host is reachable from anywhere else. The README also points to the install documentation at docs.stackstorm.com/install/index.html for procedures beyond the quick path, and to the system requirements page, which is worth reading before you pick a host: the installer assumes a clean machine, not one that already runs conflicting versions of Python or a database.

Once the service is up, the CLI is the fastest way to see what is registered. The README lists a CLI client alongside the API and web UI, and the repository keeps that client in the st2client component. The command below is the conventional entry point for listing actions; if the install succeeded, it returns the generic actions that ship with the platform, such as the SSH and HTTP request actions the README mentions.

st2 action list

From there, the real work is content. A pack downloaded from StackStorm Exchange brings its own triggers and actions, and a rule connects one to the other. The README does not walk through writing a rule in the repository itself; it defers to the documentation site. That is a fair division for a platform this size, but it means the README alone will not get you from installed to automating.

Where StackStorm is the wrong tool

The installer's assumptions are the first limitation. It expects a clean 64-bit Linux host that meets the documented system requirements. There is no supported path in the README for running the full platform on macOS or Windows, and the Makefile's separate virtualenv directories for Darwin exist for development, not for production installation. If your team standardizes on Windows servers, this is not the automation layer for you without a Linux host to run it on.

Python version support is narrow. The README badges Python 3.6 and 3.8, and the Makefile carries a special case that switches to python3.11 on Rocky Linux 9 because the distribution's default Python is too old. That is a snapshot of a moving target, and anyone planning an upgrade should treat the supported interpreter matrix as something to confirm against the current install documentation rather than assume.

The operational weight is the second limitation. StackStorm is a service with a database, a message bus and multiple microservice components. That is what makes horizontal scaling possible, and it is also why a single-host deployment is a commitment: backups, upgrades and the health of the message bus become part of your on-call surface. For a team that needs one script to run when one alert fires, this is a large amount of machinery.

Finally, the audit trail is a record, not a safety net. The README describes it as a historical list with full details of triggering context and results. It does not document a rollback mechanism for an action that already changed production. If your remediation is not idempotent, or cannot be safely re-run, StackStorm will faithfully execute it and faithfully record that it did.

StackStorm compared with a general-purpose workflow engine

The obvious alternative is a general-purpose workflow orchestrator such as Apache Airflow. The difference is in what triggers a run. Airflow is built around scheduled DAGs: a run starts because a schedule says so, and the interesting logic is dependency and retry handling inside the graph. StackStorm is built around events: a sensor fires a trigger, a rule matches it, and a workflow starts because something happened in another system.

That distinction changes the data model. In StackStorm, the trigger payload is a first-class object that rules match against and map onto action inputs, and the README's examples are all reactive: a monitoring alert, a hardware failure, a deployment that should roll back based on application performance data. In a scheduler-first tool, the same flow usually means polling the monitoring API on an interval and branching on the result, which adds latency between the event and the response.

The second difference is the content ecosystem. StackStorm Exchange is 160 packs of prebuilt integrations, each packaging triggers, actions, rules and workflows together. With a general-purpose engine you write the integration yourself against the vendor's API. Neither approach is free: a pack saves you the API work but ties you to its maintenance, and the README's pack model explicitly supports sharing content on GitHub or submitting it to the Exchange organization.

If your automation is mostly scheduled batch work with occasional manual runs, a scheduler-first tool is the better fit. StackStorm earns its place when the trigger is an event you do not control.

Licence, releases and what maintenance costs

StackStorm/st2 is Apache-2.0. The LICENSE file sits at the repository root, and the badge in the README points at it. Apache-2.0 is a permissive licence with an explicit patent grant, and it does not require you to publish modifications. That matters here because packs are separate units of content: the licence on the platform does not automatically tell you the licence on a pack you pull from StackStorm Exchange. Check each pack's own repository before you depend on it in production. This is a description of the licence text, not legal advice; if your organisation has rules about which licences may run in production, run the packs past whoever owns that policy.

The release cadence is uneven, and that is the honest maintenance picture. v3.8.0 was tagged in November 2022, v3.8.1 in December 2023, and v3.9.0 in October 2025, with the repository's last push on 2026-09-02. Long gaps between minor releases mean fixes you need may sit on the master branch for a while before a tagged version carries them, so a team that only tracks releases should plan for that lag.

Upgrade cost is tied to the dependency set. requirements.txt is generated, and its header is explicit: do not edit it, modify fixed-requirements.txt and run make requirements to regenerate it for all components. Component-level dependencies live in per-component in-requirements.txt files and are regenerated the same way. The file pins a large surface, from mongoengine and pymongo to eventlet, gevent and kombu, plus Git-sourced packages such as orquesta and the auth and RBAC backends. Those Git dependencies track master, which means an upgrade can pull unreleased code. If you need reproducible builds, that is a detail to pin on your side.

Editorial conclusion

Adopt StackStorm/st2 if you already run monitoring that emits events and you want those events to start multi-step remediation you can store as code. Do not adopt it if you need a single-host script runner, or if you cannot give it a dedicated 64-bit Linux box and its supporting services. Before rolling it out, verify three things: that the installer's supported OS matches your host, that the pack you need exists on StackStorm Exchange with the actions you expect, and that your rules map trigger payloads to the correct action inputs, because a wrong mapping fires the wrong remediation.

Frequently asked questions

Official sources

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