StackStorm: Event-Driven Automation

By Kokil Thapa | Last reviewed: September 2026

Your on-call engineer gets the same Slack alert for the third time this week. Someone SSHes in, runs three scripts by hand, and posts a screenshot to prove it worked. StackStorm: Event-Driven Automation exists to replace that loop with code that listens, decides, and acts in seconds. If you already run Linux system administration workflows or maintain Laravel apps with queues and webhooks, the mental model will feel familiar — except StackStorm treats infrastructure events as first-class citizens. This guide walks through architecture, installation, rule design, workflows, and when the platform earns a place beside Ansible, Rundeck, or cloud-native event buses.

What is StackStorm and how does event-driven automation work?

StackStorm is an event-driven automation platform originally built for DevOps and SRE teams. It sits between your monitoring stack and your operational scripts. Instead of a human reading an alert and opening a terminal, a sensor detects the event, a rule evaluates it, and an action executes the response.

The platform has five core concepts you should memorise before touching YAML:

• Sensors — long-running Python plugins that poll APIs, watch message queues, or listen for webhooks.
• Rules — YAML files that match sensor events with criteria and trigger one or more actions.
• Actions — Python scripts, shell commands, or HTTP calls packaged for reuse.
• Workflows — multi-step automations defined in Orquesta, StackStorm's native workflow engine.
• Packs — bundles of sensors, actions, and rules you install from StackStorm Exchange or your own Git repo.

On production servers I maintain with GitLab CI and Deployer, I still reach for purpose-built automation when incidents need cross-system orchestration. StackStorm fills that gap when a single cron job or Laravel queued job is not enough. It is closer to Rundeck runbook automation than to application-level Laravel events and listeners, but the event-driven pattern is the same.

StackStorm also ships ChatOps integration. Actions can post results to Slack or Microsoft Teams, and operators can trigger approved runbooks from chat with role-based access control. That audit trail matters when you need to prove who restarted a service and why.

How do you install StackStorm on Ubuntu for a production-ready setup?

StackStorm runs best on Linux. Ubuntu 22.04 or 24.04 LTS matches the servers I deploy for client projects. The official installer pulls MongoDB for data storage and RabbitMQ for the message bus — both are required components, not optional extras.

One-line install on Ubuntu

The fastest path for a lab or staging environment is the official script from the StackStorm documentation:

curl -sSL https://docs.stackstorm.com/install/scripts/st2-apply-install.sh \
  | sudo bash -s -- --user=st2admin --password='ChangeMeNow123!'

After installation, verify the services and CLI:

st2 --version
st2ctl status
st2 pack list

You should see st2api, st2actionrunner, st2stream, st2rulesengine, and st2notifier in a running state. If st2auth fails, check that MongoDB started before the StackStorm services.

Production hardening checklist

A default install is not production-ready. Treat these items as mandatory before pointing real alerts at the system:

1. Replace default credentials and enable RBAC with st2auth and LDAP or PAM integration.
2. Put StackStorm behind Nginx or Apache with TLS — same pattern you would use for a Laravel app on PHP-FPM.
3. Run MongoDB and RabbitMQ on dedicated nodes or managed services when traffic grows.
4. Configure log rotation and backup for /opt/stackstorm and MongoDB data directories.
5. Pin pack versions in Git rather than installing latest from Exchange on every deploy.

For teams that already use Ansible roles for server provisioning, an Ansible play can install StackStorm identically across staging and production. Pair that with your existing build automation pipeline so pack updates flow through review before they hit production sensors.

How do StackStorm sensors, rules, and actions connect in practice?

The power of StackStorm event-driven automation is in the glue between components. A sensor emits a trigger. A rule listens for that trigger type. An action or workflow runs when criteria pass.

Installing a pack

Packs ship pre-built integrations. The GitHub pack is a common starting point:

st2 pack install st2_github
st2 pack list | grep github
st2 action list --pack=github

Configure pack credentials through the Web UI at https://your-host/#/settings or via CLI config files under /opt/stackstorm/configs/.

Writing a rule

Rules live in /opt/stackstorm/packs/<pack>/rules/ or your custom pack directory. This example reacts to a GitHub webhook push event and runs a shell action:

---
name: deploy_on_push_to_main
pack: my_deploy
enabled: true

trigger:
  type: github.repository_push

criteria:
  trigger.body.ref:
    pattern: "refs/heads/main"
    type: equals

action:
  ref: my_deploy.notify_and_deploy
  parameters:
    repo: "{{ trigger.body.repository.full_name }}"
    commit: "{{ trigger.body.head_commit.id }}"

Reload rules after changes:

st2ctl reload --register-rules
st2 rule list
st2 rule enable my_deploy.deploy_on_push_to_main

Creating a custom action

Actions are Python metadata files plus scripts. A minimal shell action lives at actions/notify_and_deploy.yaml:

---
name: notify_and_deploy
pack: my_deploy
runner_type: "action-chain"
description: Notify Slack and trigger deploy hook
enabled: true
entry_point: notify_and_deploy.sh
parameters:
  repo:
    type: string
    required: true
  commit:
    type: string
    required: true

The companion script validates input server-side — the same principle I apply on Laravel Form Requests. Never trust webhook payloads without checking signatures and scoping credentials per environment.

Debug a misfiring rule with st2 rule-enforcement list and st2 execution get <id>. The JSON output shows exactly which criteria failed. I keep a JSON formatter handy when pasting execution payloads into tickets.

When should you choose StackStorm over Rundeck, Ansible, or cloud event buses?

StackStorm is not a replacement for every automation tool. It excels at reactive, event-driven workflows across heterogeneous systems. Batch configuration management and scheduled jobs belong elsewhere.

Many teams combine tools. Ansible provisions the server. StackStorm listens for Nagios or Prometheus alerts and runs remediation actions. Rundeck remains the escape hatch when automation needs human approval. That layered approach mirrors how I structure support and maintenance contracts — automate the repetitive 80%, keep a manual path for edge cases.

If your entire stack already lives on AWS and you prefer zero self-hosted services, EventBridge plus Lambda may cost less operational overhead. StackStorm wins when you need one control plane across on-prem Linux boxes, GitHub, Slack, Jira, and custom internal APIs without rewriting every integration as Lambda functions.

How do you build multi-step workflows with Orquesta in StackStorm?

Simple action chains handle two-step tasks. Complex incident playbooks need Orquesta — StackStorm's YAML workflow engine with branching, delays, retries, and error handling. Official Orquesta documentation at docs.stackstorm.com/orquesta covers the full spec.

Example remediation workflow

This workflow checks disk usage, notifies Slack, and optionally cleans temp files when usage exceeds 90%:

version: 1.0
description: Disk usage remediation workflow

input:
  - hostname
  - mount_point

vars:
  - threshold: 90

tasks:
  check_disk:
    action: core.local_sudo cmd="df -h {{ mount_point }} | tail -1"
    next:
      - when: "{{ result.stdout.split()[4].replace('%','') | int > threshold }}"
        do: notify_and_clean
      - when: "{{ result.stdout.split()[4].replace('%','') | int <= threshold }}"
        do: notify_ok

  notify_and_clean:
    join: all
    actions:
      - chatops.post_message channel="#ops" message="Disk high on {{ hostname }}"
      - core.local_sudo cmd="find /tmp -type f -mtime +7 -delete"
    next:
      - do: verify_disk

  verify_disk:
    action: core.local_sudo cmd="df -h {{ mount_point }} | tail -1"
    next:
      - do: done

  notify_ok:
    action: chatops.post_message channel="#ops" message="Disk OK on {{ hostname }}"
    next:
      - do: done

  done:
    action: core.noop

Register and test the workflow:

st2ctl reload --register-actions
st2 run my_remediation.disk_cleanup hostname=web01 mount_point=/var
st2 execution list --limit=5

Orquesta workflows benefit from the same testing discipline as automated test pyramids. Unit-test individual action scripts with Python test runners. Integration-test the full workflow against a staging host before wiring production sensors.

For booking platforms and legal-tech portals I have shipped, background jobs handle application logic. StackStorm handles the infrastructure layer beneath them — clearing stuck queue workers, rotating logs when disk alerts fire, or scaling worker counts when queue depth sensors trip thresholds. That separation keeps Laravel queue code focused on business rules while ops automation lives in a dedicated platform.

What are common StackStorm production mistakes and how do you avoid them?

StackStorm event-driven automation fails in predictable ways. Most are operational, not framework bugs.

• Runaway rule loops — an action emits an event that retriggers the same rule. Add criteria guards or use rule filters to break the cycle.
• Missing pack pinning — auto-updating packs break actions silently. Store packs in Git and deploy via CI, same as application code.
• Overloaded action runners — long-running actions block the runner pool. Offload heavy work to external queues or increase st2actionrunner workers.
• Credential sprawl — pack configs with root SSH keys are a liability. Scope service accounts per action and rotate through your secrets manager.
• No alerting on StackStorm itself — if RabbitMQ dies, every rule stops. Monitor st2ctl status from the same SLO-driven alerting stack you use for application uptime.

On shared EC2 infrastructure where I run Deployer 7 and GitLab CI for sister legal-tech sites, I treat StackStorm packs like deployable artefacts. A merge request updates the pack repo, CI validates YAML syntax, and a controlled reload registers new rules without touching running executions.

Extreme Networks acquired StackStorm and continues development under the Apache 2.0 licence. The GitHub repository at github.com/StackStorm/st2 remains the source of truth for releases and community packs. Check release notes before upgrading MongoDB or RabbitMQ major versions.

Teams exploring broader event-driven patterns should also read about event-driven microservices with Kafka and KEDA event-driven autoscaling. Those tools address application-level streaming and Kubernetes scaling. StackStorm addresses ops runbooks triggered by infrastructure events. They complement each other rather than compete.

If you need custom integrations between StackStorm and a Laravel API — for example, pausing booking imports when disk alerts fire — treat the boundary as a REST contract. Document endpoints in OpenAPI, authenticate with tokens, and build idempotent handlers. That is standard work in API development and enterprise application projects.

Key Takeaways

• StackStorm event-driven automation connects sensors, rules, actions, and Orquesta workflows into one auditable platform for reactive ops work.
• Install on Ubuntu LTS, harden auth and TLS, and pin packs in Git before connecting production alert sources.
• Use rules for simple trigger-to-action paths; use Orquesta when you need branching, retries, or multi-system coordination.
• Pair StackStorm with Ansible for provisioning and Rundeck for human-approved runbooks rather than forcing one tool to do everything.
• Monitor StackStorm's own dependencies — MongoDB, RabbitMQ, and action runners — or your automation layer becomes a silent single point of failure.
• Test actions and workflows in staging with st2 run before enabling sensors that touch production infrastructure.

People Also Ask

Is StackStorm still maintained in 2026?

Yes. StackStorm remains open source under Apache 2.0. Extreme Networks maintains the project, and the community publishes packs through StackStorm Exchange. Check the GitHub releases page before planning major upgrades.

What is the difference between StackStorm and Ansible?

Ansible pushes desired state to servers through playbooks, usually on a schedule or manual trigger. StackStorm reacts to real-time events through sensors and rules. Ansible configures machines; StackStorm orchestrates responses to alerts, webhooks, and ChatOps commands.

Can StackStorm integrate with Slack and PagerDuty?

Both have official packs on StackStorm Exchange. The Slack pack supports posting messages and receiving slash commands. The PagerDuty pack can listen for incident triggers and run remediation workflows automatically.

Does StackStorm require Python?

Actions and sensors are Python-based, though runners also support shell scripts and HTTP actions. Your team needs basic Python literacy to write custom actions, or you can rely on pre-built packs for common integrations.

Deploy event-driven automation with confidence

Manual runbooks do not scale past a small ops team. StackStorm: Event-Driven Automation gives you a proven pattern — sense, decide, act — with full execution history and ChatOps built in. Start with one high-churn alert, automate the fix in staging, and expand pack by pack. If you want help wiring StackStorm into a Laravel app, a booking platform, or a mixed Linux fleet, see the automation and integration services page or contact us to discuss your stack. For related reading, browse automation articles or learn how Git hooks automate pre-commit checks in your development workflow.