st2 is a free, open source cloud infrastructure management project written in Python and released under Apache-2.0. It has 6,536 GitHub stars, 787 forks and 603 open issues, and was last pushed 16 days ago. On this registry it ranks #33 of 70 tracked projects in Cloud Infrastructure Management, with 5 head-to-head comparisons available.

What is st2?

StackStorm — packaged and installed as st2 — is an open-source, event-driven automation platform, often described as "IFTTT for Ops", that ties existing infrastructure, monitoring and application tools together so DevOps engineers and SREs can automate remediation, incident response, troubleshooting and deployment as rules and workflows stored as code.

What it is

StackStorm is a platform for integration and automation across services and tools. It sits alongside the infrastructure and application environment an organisation already runs and gives it a rules engine, a workflow engine and an action library, with a particular focus on taking actions in response to events. The rules and workflows — the content within the platform — are stored as code, so they support the same collaboration model used for code development and can be shared with the wider open-source community through StackStorm Exchange. The project is written in Python and licensed under Apache-2.0.

The concrete problem it solves is the glue work between monitoring, infrastructure and communication systems. Instead of a human reading a Nagios, Sensu or New Relic alert, SSHing into machines to run diagnostic checks, and then copying the results into Slack or JIRA by hand, StackStorm triggers on the event and runs that sequence itself. It replaces the ad-hoc scripts, cron jobs and manual runbooks that normally connect those tools, and it does so as a first-class installable platform rather than a collection of shell scripts.

Key capabilities

  • Rules engine and workflow engine for composing operational patterns as rules, actions and workflows, stored as code.
  • 160 integration packs providing 6000+ actions, published through StackStorm Exchange.
  • ChatOps support, including posting diagnostic and remediation results into a shared communication context such as Slack or JIRA.
  • Event-driven triggering from monitoring systems named in the README: Nagios, Sensu and New Relic.
  • Automated remediation workflows that verify hardware failure, evacuate instances, email about downtime, and freeze the workflow and call PagerDuty when something goes wrong.
  • Continuous deployment orchestration: build and test with Jenkins, provision an AWS cluster, turn on traffic with the load balancer, then roll forward or roll back based on NewRelic application performance data.
  • Distribution as deb and rpm packages via Packagecloud, plus a shell installer script and a CI pipeline with Codecov reporting.

Who uses it and how

  • Site reliability and operations teams that want monitoring alerts to trigger diagnostic checks on physical nodes, OpenStack or Amazon instances, and application components automatically.
  • Teams running OpenStack clouds, where the documented example is identifying and verifying hardware failure on a compute node, evacuating instances and notifying the affected VM about potential downtime.
  • CI/CD-focused teams that chain Jenkins, AWS provisioning, load balancer traffic shifts and performance-based roll-forward or roll-back into a single workflow.
  • Organisations that need human escalation built into automation, with PagerDuty woken only when an automated remediation path fails.
  • Community contributors and pack authors who publish and consume reusable content through StackStorm Exchange; known users are listed in ADOPTERS.md and on the project's Thought Leaders page.

Getting started

The documented path is a clean 64-bit Linux box meeting the published system requirements (Python 3.6 and 3.8 are the supported versions), followed by the installer script: curl -sSL https://stackstorm.com/packages/install.sh | bash -s -- --user=st2admin --password=Ch@ngeMe. Deb and rpm packages are also available from Packagecloud, and full instructions live at docs.stackstorm.com.

How it compares

No list of paid products that this project replaces is provided in the available facts, and no directly comparable event-driven automation platform is named there either; on the evidence given, StackStorm stands alone in this registry. The tools named in the README — Nagios, Sensu, New Relic, Jenkins, PagerDuty, Slack, JIRA and OpenStack — are integration targets rather than alternatives to it.

When to use it — and when not to

Choose StackStorm when a team already runs monitoring and infrastructure tooling and wants a Python-based, Apache-2.0 platform to turn alerts into automated rules and workflows without building that plumbing itself. A self-hoster must run and maintain the whole stack on their own Linux host, including the documented system requirements and whichever integration packs, credentials and external services the workflows touch, so teams without operations capacity should look elsewhere. The project also carries 603 open issues, a truncated README excerpt that does not fully document the architecture on the repository page, and no managed hosting option is described — the installer targets a box the operator controls.

project readme (upstream, from github) — read inline

StackStorm

StackStorm is a platform for integration and automation across services and tools, taking actions in response to events. Learn more at www.stackstorm.com.

Build Status Packages Build Status Codecov CII Best Practices Python 3.6,3.8 Apache Licensed Join our community Slack deb/rpm packages Code Search GitHub Discussions Twitter Follow


TL;DR

StackStorm Overview

StackStorm 5 min Intro Video

About

StackStorm is a platform for integration and automation across services and tools. It ties together your existing infrastructure and application environment so you can more easily automate that environment -- with a particular focus on taking actions in response to events.

StackStorm helps automate common operational patterns. Some examples are:

  • Facilitated Troubleshooting - triggering on system failures captured by Nagios, Sensu, New Relic and other monitoring, running a series of diagnostic checks on physical nodes, OpenStack or Amazon instances, and application components, and posting results to a shared communication context, like Slack or JIRA.
  • Automated remediation - identifying and verifying hardware failure on OpenStack compute node, properly evacuating instances and emailing VM about potential downtime, but if anything goes wrong - freezing the workflow and calling PagerDuty to wake up a human.
  • Continuous deployment - build and test with Jenkins, provision a new AWS cluster, turn on some traffic with the load balancer, and roll-forth or roll-back based on NewRelic app performance data.

StackStorm helps you compose these and other operational patterns as rules and workflows or actions; and these rules and workflows - the content within the StackStorm platform - are stored as code which means they support the same approach to collaboration that you use today for code development and can be shared with the broader open source community via StackStorm Exchange.

Who is using StackStorm?

See the list of known StackStorm ADOPTERS.md and Thought Leaders.

How it works

StackStorm architecture

StackStorm architecture diagram

StackStorm plugs into the environment via an extensible set of adapters: sensors and actions.

  • Sensors are Python plugins for inbound integration that watch for events from external systems and fire a StackStorm trigger when an event happens.

  • Triggers are StackStorm representations of external events. There are generic triggers (e.g., timers, webhooks) and integration triggers (e.g., Sensu alert, JIRA issue updated). A new trigger type can be defined by writing a sensor plugin.

  • Actions are StackStorm outbound integrations. There are generic actions (SSH, HTTP request), integrations (OpenStack, Docker, Puppet), or custom actions. Actions are either Python plugins, or any scripts, consumed into StackStorm by adding a few lines of metadata. Actions can be invoked directly by user via CLI, API, or the web UI, or used and called as part of automations - rules and workflows.

  • Rules map triggers to actions (or to workflows), applying matching criterias and map trigger payload data to action inputs.

  • Workflows stitch actions together into "uber-actions", defining the order, transition conditions, and passing context data from one action to the next. Most automations are multi-step (eg: more than one action). Workflows, just like "atomic" actions, are available in the action library, and can be invoked manually or triggered by rules.

  • Packs are the units of content deployment. They simplify the management and sharing of StackStorm pluggable content by grouping integrations (triggers and actions) and automations (rules and workflows). A growing number of packs is available on the StackStorm Exchange. Users can create their own packs, share them on GitHub, or submit them to the StackStorm Exchange organization.

  • Audit trail is the historical list of action executions, manual or automated, and is recorded and stored with full details of triggering context and execution results. It is also captured in audit logs for integrating with external logging and analytical tools: LogStash, Splunk, statsd, or syslog.

StackStorm is a service with modular architecture. It is comprised of loosely coupled microservice components that communicate over a message bus, and scales horizontally to deliver automation at scale. StackStorm has a full REST API, CLI client, and web UI for admins and users to operate it locally or remotely, as well as Python client bindings for developer convenience.

StackStorm is an established project and remains actively developed by a broad community.

Documentation

Additional documentation, including installation procedures, action/rule/workflow authoring, and how to setup and use triggers/sensors can be found at https://docs.stackstorm.com.

Hacking / Contributing

To set up a development environment and run StackStorm from sources, follow these instructions.

For information on how to contribute, our style guide, coding conventions and more, please visit the Development section in our documentation.

Security

If you believe you found a security issue or a vulnerability, please send a description of it to our private mailing list at info [at] stackstorm [dot] com.

Once you've submitted an issue, you should receive an acknowledgment from one our of team members in 48 hours or less. If further action is necessary, you may receive additional follow-up emails.

For more information, please refer to https://docs.stackstorm.com/latest/security.html

Copyright, License, and Contributor Agreement

Copyright 2020 The StackStorm Authors. Copyright 2019 Extreme Networks, Inc. Copyright 2014-2018 StackStorm, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this work except in compliance with the License. You may obtain a copy of the License in the LICENSE file, or at:

http://www.apache.org/licenses/LICENSE-2.0

By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project.

Frequently asked questions

Is st2 free to use?

st2 is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does st2 do?

StackStorm (aka "IFTTT for Ops") is event-driven automation for auto-remediation, incident responses, troubleshooting, deployments, and more for DevOps and SREs

What is st2 written in?

st2 is primarily written in Python. Its source is publicly available at https://github.com/StackStorm/st2, and it has 6,536 GitHub stars.