cloudparts

StackStorm

Event-driven automation for operations, “IFTTT for ops”: sensors turn alerts and webhooks into triggers, rules match them, and actions or YAML workflows fix the problem, with every run audited.

Linux Foundation project
What it is
Workflow orchestration
Used for
Incident management
Type
Open source
Made by
StackStorm project (LF Projects, started by StackStorm, Inc.)
Foundation
The Linux Foundation, joined October 2019. A series of LF Projects, LLC, handed over by Extreme Networks
License
Apache 2.0
Facts checked
28 October 2026
Website Source code

What it is

StackStorm reacts to events. Sensors, small Python plugins, watch outside systems or receive webhooks and emit triggers, such as a monitoring alert or a Jira issue update. Rules match a trigger against criteria (equals, regex, contains and about two dozen other operators on fields of its payload) and start an action with parameters filled from the payload through Jinja templates. Actions are scripts or Python classes with a metadata file: run a command over SSH, call a REST API, restart a service. Workflows chain actions with branches, joins and data passed between steps, and Orquesta, StackStorm’s own YAML workflow engine, runs them. Every execution, manual or automatic, is recorded with what triggered it and what it returned.

Content ships in packs, which bundle sensors, actions, rules and workflows for one system; the StackStorm Exchange lists about 160 of them with over 6,000 actions. Action aliases expose actions to chat, so a message such as !restart nginx on web-3 in Slack runs the same audited action (ChatOps, through a Hubot adapter). Under the hood a dozen Python services (API, auth, rules engine, scheduler, action runners, workflow engine, sensor container, timers and others) talk over RabbitMQ, keep state in MongoDB and coordinate workflow branches through Redis or ZooKeeper, with a web UI, a CLI and a REST API in front.

StackStorm 3.9.0 (October 2025) runs on Python 3.8 to 3.11 and supports MongoDB 7.0; its packages target Ubuntu 20.04 and 22.04 and RHEL or Rocky Linux 8 and 9. The next release, in development, moves to Python 3.10 to 3.12, MongoDB 8.2 and RabbitMQ 4.2, and adds packages for Ubuntu 24.04 and Rocky Linux 10. The project is maintained by volunteers from companies that run it, with most 2026 commits coming from three maintainers.

Why teams pick it

  • Built for auto-remediation: an alert can trigger a diagnosis and fix without a human, and every run lands in an audit trail
  • A large catalogue of ready integrations in the Exchange, and actions can be any script, so existing runbooks plug in as they are
  • The same actions run from rules, workflows, the CLI, the API and chat, with RBAC and LDAP or SSO login included in the open-source edition
  • Self-hosted and Apache 2.0, with no paid tier holding features back

Watch out for

  • Many moving parts: RabbitMQ, MongoDB, Redis and NGINX plus about a dozen services; the docs suggest four cores and more than 16 GB of RAM for production
  • The Kubernetes Helm chart for high availability is still labelled beta and starts more than 30 pods by default
  • Slow releases from a small volunteer team: 3.8.1 in December 2023, then 3.9.0 in October 2025, and packages for Ubuntu 24.04 are not released yet
  • Workflows are YAML with YAQL or Jinja expressions rather than code, so complex logic ends up in Python actions, and long-running business processes fit a durable-execution engine such as Temporal better

Alternatives

What all workflow orchestration have in common →Compare side by side →
n8nCommercialA visual workflow automation tool you can self-host or rent as n8n Cloud: workflows are chains of nodes started by triggers, and its AI Agent node, built on LangChain’s JavaScript library, lets a model call other nodes and MCP servers as tools.TemporalOpen sourceAn open-source durable execution engine: you write workflows as ordinary code and they survive crashes.AWS Step FunctionsAWSAWS’s serverless workflow engine: state machines in JSON that call AWS services directly.Cloudflare WorkflowsCommercialDurable execution on Cloudflare Workers: a workflow is ordinary TypeScript or Python code split into steps, and each step’s result is saved so a failed run retries that step and carries on instead of starting over.PrefectOpen sourceA Python workflow orchestrator where a pipeline is an ordinary function decorated with @flow, with retries, caching, schedules and a UI added around it.

How it fits with other technologies

A rule: when a monitoring webhook reports nginx down, restart it on that host · yaml

---
name: restart_nginx_on_alert
pack: ops
description: Restart nginx when the monitoring webhook says it is down
enabled: true

trigger:
  type: core.st2.webhook
  parameters:
    url: monitoring            # POST /api/v1/webhooks/monitoring

criteria:
  trigger.body.check:
    type: equals
    pattern: nginx_down

action:
  ref: core.remote             # runs a command over SSH
  parameters:
    hosts: "{{ trigger.body.host }}"
    cmd: sudo systemctl restart nginx

See it in a real stack

No architecture uses StackStorm yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2013–2025

Evan Powell and Dmitri Zimine founded StackStorm in 2013 to automate the operational chores that DevOps teams still did by hand: noticing an event, working out what it meant and running the fix. The company came out of stealth in May 2014 and released its platform as open source, pitched as “IFTTT for ops” for auto-remediation, incident response and deployments.

Brocade bought the eight-person company in March 2016 to bring the same automation to networking, and sold a commercial edition as Brocade Workflow Composer. When Extreme Networks bought Brocade’s data-centre networking business in October 2017, StackStorm went with it and the product became Extreme Workflow Composer.

On 7 October 2019 Extreme handed governance of StackStorm to the Linux Foundation, reporting about 1,200 installations a month and over 400 contributors. Extreme then contributed Workflow Composer’s enterprise code, including RBAC, LDAP and single sign-on, which reached the open-source releases in 2020 and 2021. Since then a technical steering committee of volunteers from user companies has kept it going, with releases growing further apart.

Why it’s built this way

Sensors, triggers, rules and actions as separate pieces
Splitting “what happened” from “what to do” lets one alert start several automations and one action serve many rules, much as IFTTT links triggers to actions.
Any script can be an action
Operations teams already had shell, Python and PowerShell runbooks; wrapping them in a metadata file made them callable, auditable and reusable without a rewrite.
Its own workflow engine, Orquesta
StackStorm first used OpenStack’s Mistral, which needed its own database and authentication. Orquesta, released in beta in 2018, runs natively inside StackStorm, and Mistral was removed in 3.3 in October 2020.
ChatOps on the same actions
Running fixes from Slack puts the command and its output in the channel where the team is talking, while still going through StackStorm’s permissions and audit.

Timeline

  1. 2013

    StackStorm founded by Evan Powell and Dmitri Zimine

  2. 2014

    Leaves stealth in May and releases the platform as open source

  3. 2016

    Acquired by Brocade in March

  4. 2017

    Moves to Extreme Networks with Brocade’s data-centre business

  5. 2018

    Orquesta workflow engine released in beta (2.8)

  6. 2019

    Extreme hands StackStorm to the Linux Foundation on 7 October

  7. 2020

    Mistral removed in 3.3; Orquesta is the only workflow engine

  8. 2025

    3.9.0 in October adds Python 3.10 and 3.11 and MongoDB 7.0

Sources13 · facts checked 28 October 2026

Improve this page on GitHub