Which open-source option replaces Octopus Deploy runbooks?
A team that runs operational work such as service restarts, certificate rotations, scaling changes or emergency fixes through Octopus runbooks needs that work to keep running once it leaves the commercial tool. No single open-source product copies Octopus runbooks exactly. StackStorm, Jenkins jobs and Kubernetes jobs triggered from Argo CD each fit a different mix of targets, triggers and audit needs, so the choice starts with the list of runbooks you actually run, not with the tool.
StackStorm is the closest match for event-driven operations. Its sensors watch external systems and fire triggers, and its rules map those triggers to actions or workflows, which suits automated remediation and emergency responses that should start without a person clicking a button. Its RBAC, which is available in the open-source release since version 3.4, can assign roles from LDAP group membership, and every manual or automated execution is recorded in an audit trail that can ship to Splunk, LogStash, statsd or syslog. Confirm that the packs you need exist on the StackStorm Exchange or can be written, and check how your SSH or API targets authenticate, because runbooks that reach servers depend on those credentials being managed outside the tool.
Jenkins jobs suit scheduled or manually approved operational tasks that already run in your build estate, since Jenkins is MIT-licensed and offers parameterized jobs and per-job permissions. Kubernetes jobs triggered from Argo CD fit runbooks that act on cluster resources, because Argo CD syncs the job manifest from Git, which gives you a reviewable history of every change. Argo CD's SSO and RBAC apply to the application, so confirm which roles may sync operational jobs and whether log access is granted explicitly. DeployOpen implements these options inside the client's own infrastructure under a written scope, agreed before work starts.
How Octopus runbook capabilities map to open-source options
This table maps each Octopus runbook capability to StackStorm, Jenkins and Kubernetes jobs triggered from Argo CD, and flags where an added component or a vendor documentation check is needed. Use it to shortlist options, then confirm the gap rows against your own approval and secrets requirements. Argo CD works best for Kubernetes work, while StackStorm covers the widest range of operational tasks.
| Runbook capability | StackStorm | Jenkins | Kubernetes jobs triggered from Argo CD |
|---|---|---|---|
| Multi-target execution | Actions run over SSH, HTTP and other integrations across many hosts and services. Gap: confirm your host inventory and connection setup. | Work distributes across agents on multiple machines. Server targets need SSH or agent steps written in the pipeline. | Jobs run inside clusters that Argo CD manages. Servers outside Kubernetes fall outside this pattern. |
| Manual and scheduled triggers | Runs start from the CLI, REST API or web UI. Schedules use timer triggers, so confirm cron behavior in your version. | Manual builds accept parameters. Scheduled runs use cron triggers defined in the Jenkinsfile. | Scheduled work runs as Kubernetes CronJobs. Manual runs depend on triggering a sync, so confirm the workflow. |
| Event triggers | Sensors watch external systems and fire triggers that rules map to actions. Broadest coverage of the three. | Webhooks start builds on source changes. Events from other systems need additional plugins. | Reacts to Git changes and cluster state. Alerts from other systems need an external event source. |
| Variables and secrets | Configuration and values are managed as code. Gap: confirm how secrets are encrypted and paired with a secrets manager. | Credentials live on the controller in JENKINS_HOME, so back them up and restrict access carefully. | Repository definitions are Kubernetes Secrets. Runbook secrets need Kubernetes Secrets or an external store. |
| Approvals | No approval gate is described in the supplied documentation. Gap: add a workflow step or external approval tool. | Pipeline input steps can pause for a person. Confirm who may approve and how it is recorded. | Sync permissions control who can deploy. Runbook-style approvals need Git pull request review or an external tool. |
| Role-based access | Open-source RBAC since version 3.4, with roles assigned from LDAP group membership. | Authorization is set through plugins. Confirm the strategy and roles you need before rollout. | Application-level RBAC with SSO through Dex or OIDC. Logs need an explicit permission to view. |
| Run history and audit logs | Records every manual and automated execution. Ships to LogStash, Splunk, statsd or syslog. | Build history is kept per job. Confirm retention settings and how logs reach your SIEM. | Sync history is kept per application. Confirm how Kubernetes and controller logs are exported to your SIEM. |
| Self-hosted operation | Apache-2.0 licensed. Microservices depend on MongoDB and RabbitMQ, with a beta Helm chart for HA. | MIT licensed with LTS releases. The controller and agents are both yours to run and back up. | Apache-2.0 licensed. HA needs at least three nodes, with Redis as a disposable cache. |
When StackStorm, Jenkins or Argo CD-triggered jobs fit
Three self-hosted options can run runbook work, and each suits a different trigger model. StackStorm fits alert-driven remediation across hosts and services. Jenkins fits teams that already operate CI and want parameterized operator jobs in one place. Argo CD with Kubernetes Jobs fits cluster-side tasks that should live in Git. Before you migrate any runbook, check who can start each task, which credentials it uses and where its audit trail is kept.
StackStorm event-driven actions
StackStorm is built for event-driven runbooks. Sensors watch external systems and fire triggers, rules map those triggers to actions or multi-step workflows, and actions reach hosts over SSH or services over HTTP. It fits remediation that must react to an alert, such as restarting a service on a named host after a health check fails. The project is Apache-2.0 licensed, and RBAC, once part of the enterprise edition, is available in open source since version 3.4, including role assignment from LDAP group membership. The trade-off is that you operate a platform with its own services, MongoDB and RabbitMQ, and each pack of integrations needs review before it runs against production. Check that every action uses narrowly scoped credentials and that the audit trail is shipped to your log platform.
Jenkins parameterized jobs
Jenkins jobs suit teams that already run Jenkins for CI and want operator tasks in the same system. A parameterized job lets an operator choose a target and enter a change reference, while a Jenkinsfile in source control defines the stages and steps that run. Jenkins is distributed under the MIT License, and its plugin catalog includes Kubernetes and Configuration as Code support. The trade-off is that Jenkins is organized around pipeline runs, so an alert-driven runbook needs an external trigger to start the job. Plan the operational burden carefully: plugin upgrades can change behavior, and LTS 2.580.1 stopped bundling several plugins, so administrators must install them through the plugin manager. Back up $JENKINS_HOME, which holds configuration, plugins and secrets, and confirm who can run each job.
Argo CD-triggered Kubernetes Jobs
Kubernetes Job manifests stored in Git let a cluster-side task, such as a database migration check or a certificate rotation, run with a reviewable version history. Argo CD syncs the manifest from Git, and its sync history records what was applied and when. Argo CD RBAC applies to applications, and since the 2.14 to 3.0 upgrade, update and delete permissions apply only to the application itself, while viewing logs requires an explicit logs, get permission. The trade-off is that Argo CD reconciles desired state, so one-off jobs need careful naming and hook handling, and the approach covers Kubernetes targets only, not servers. Confirm how your Argo CD version treats completed Jobs on resync. Disable the built-in admin user with admin.enabled set to false once SSO is configured, and plan at least three nodes if you run the HA manifests.
Choosing the engine by target and team
When every target is a Kubernetes cluster, most routine and emergency tasks can run as Kubernetes Jobs whose manifests live in Git. Argo CD can trigger these Jobs through a Git-managed Application, so a rollback, a cache flush or a database migration step is a reviewed commit rather than a button click in a separate tool. Argo CD is licensed under Apache-2.0 and reached Graduated status in the CNCF, so the team can run it without a paid edition. The trade-off is that Argo CD syncs desired state, so one-off operational actions need a deliberate pattern, such as a Job with a unique name or a PreSync hook.
- Engine fit: Argo CD for triggering Jobs from Git, with Kubernetes RBAC controlling who can sync and who can read logs.
- Operating burden: a highly available Argo CD install, which the HA documentation says needs at least three nodes because of pod anti-affinity rules.
- Access control: Argo CD 3.0 changed update and delete RBAC so it applies to the application itself, and reading logs needs an explicit logs, get permission.
- Audit trail: Git history records who changed a Job definition, while the Kubernetes API audit log records who created a run. Confirm your cluster has API audit logging enabled and where it is shipped.
- Emergency runs: decide whether a break-glass path bypasses Git. If it does, record the run in the audit log and reconcile the Git state afterward.
Before choosing, ask who approves emergency runs, how long audit logs must be kept, and whether the same people can both merge a change and run it.
Where targets are virtual machines, bare metal or network devices, Kubernetes Jobs do not reach them. StackStorm fits better here: it runs actions such as SSH commands and HTTP calls against those targets, triggers them from events or from a person, and records an audit trail of each execution. StackStorm is licensed under Apache-2.0 and its content is stored as code in packs. Jenkins is the other common choice when operators already use it for deployments, since its jobs can connect to hosts with agents, although it has no event-driven rules engine of its own.
- Engine fit: StackStorm for event-driven remediation and operator-triggered actions, Jenkins jobs when runbooks are already scripted and run on a schedule or on demand.
- Operating burden: StackStorm is a set of microservices that depend on MongoDB and RabbitMQ, so budget for those services alongside the platform itself.
- Access control: StackStorm open source includes role-based access control since version 3.4, with roles assignable from LDAP group membership.
- Audit trail: StackStorm can ship its execution audit trail to LogStash, Splunk, statsd or syslog. Confirm the retention period in your log platform, since StackStorm does not set it for you.
- Credentials: SSH keys and service accounts must be stored in a secrets store and never pasted into runbook definitions.
Before choosing, confirm which hosts must be reachable, who can approve a production action on a live server, and whether the audit trail must be kept outside the platform.
Many organizations run both Kubernetes workloads and traditional servers. Splitting the runbook estate by engine avoids forcing one tool to do everything badly, but it also doubles the operating surface and the access model. The usual pattern is to keep Kubernetes-native work in Argo CD-triggered Jobs and server work in StackStorm or Jenkins, then route both through one approval and logging standard so auditors see a single record.
- Engine fit: Argo CD plus StackStorm or Jenkins, with a shared rule that decides which engine owns each task type.
- Operating burden: two control planes, two sets of credentials and two RBAC models that must be mapped to the same roles.
- Access control: map each role once, such as operator, approver and auditor, and check that Argo CD RBAC and StackStorm RBAC grant the same intent.
- Audit trail: forward logs from both engines to one store with a common retention policy, and keep a index of which runbook ran where.
- Consistency: use the same secrets store for both engines so a rotated credential does not break one path silently.
Before choosing, ask whether one team owns both engines, who approves a task that touches both a cluster and a server, and whether a single log store is required by your audit program.
Running open-source runbooks beside the rest of Octopus
Most teams do not replace Octopus in one step. Runbooks can move to StackStorm, Jenkins jobs or Kubernetes jobs while releases stay where they are, provided identity, secrets and audit records are wired to the same controls. The cards below cover the decisions that connect the new engine to the tools still in use.
Keep Octopus for releases
Releases, lifecycles and environment promotion can stay in Octopus while only operational runbooks move. The split is easier to manage when each runbook has a single owner and a clear rule for which tool runs it. Check which Octopus projects call runbooks directly, because those calls must be re-pointed to the new trigger or job before the old runbooks are retired. Mapping these dependencies is usually the first step of a fixed-scope review.
Share identity through SSO
Put StackStorm, Jenkins and Octopus behind the same identity provider so one group model controls who can see and run each runbook. Map existing Octopus team roles to groups before granting access in the new engine, so that offboarding removes access everywhere at once. StackStorm can assign roles from LDAP group membership, so confirm which group source your directory exposes and whether your Octopus and new engine groups use the same names.
Keep secrets in one store
Runbooks usually need credentials for servers, cloud accounts or database consoles, and those values should not be copied into a second vault. Place them in one secrets store that both Octopus and the new engine read, with each consumer granted only the paths it needs. Octopus sensitive variables are not exported as plain values by default, so plan to re-enter or re-issue them into the store and rotate them during the cutover.
Send audit records to the log platform
Every runbook execution in the new engine should appear in the same log platform that already receives Octopus and infrastructure events. StackStorm records an audit trail of manual and automated executions and can ship it to LogStash, Splunk, statsd or syslog. Confirm the field names, retention period and who can read the records, since an on-call action is only useful in an incident review if it can be traced to a named user and a run ID.
Change the on-call button workflow
On-call staff who used Octopus runbook buttons will now start work from a chat command, a web UI, an API call or an alert-triggered rule, depending on the engine chosen. Agree on the new entry point, a short run book for each common action and where to check the result before the cutover. Run a drill with the people who respond at night, because a button that moved is a common source of delay during an incident.
What the open-source runbook stack costs to own
The largest recurring costs in this stack are people and hosting, not licenses, because StackStorm, Jenkins and Argo CD are all Apache-2.0 or MIT licensed with no paid edition from the project itself. Hosting breaks into three parts: the StackStorm services, which depend on MongoDB for storage and RabbitMQ for messaging, the Jenkins controller and its build agents, and the Kubernetes capacity Argo CD and any Kubernetes jobs need. Argo CD's high availability documentation says its HA manifests need at least three nodes because of pod anti-affinity rules, so a quote should state whether that baseline is included. Ask who runs the database and message bus, whether they are managed by your platform team or the implementer, and how their backups are scheduled.
Engineering time is usually the largest one-time item. Writing, testing and reviewing runbooks as code means StackStorm packs, Jenkins pipelines and any Kubernetes job manifests, each with its own review path. Migration work is one-time: inventorying existing Octopus runbooks, rebuilding them, and rebuilding RBAC and audit settings. Recurring work includes upgrades, such as tracking Jenkins LTS baselines, Java support dates and Argo CD's three supported minor versions, plus plugin maintenance. Log retention costs rise with the volume of audit records you keep, and the secrets store charge depends on how many credentials runbooks read. Confirm whether each of these is priced by node, by user, by credential or by hour.
When requesting a quote, ask for a written scope listing each component, the hosting model (existing clusters or dedicated servers), the expected upgrade cycle, and the responsibilities split for on-call support. Ask how audit records will be retained and exported, since StackStorm can ship them to external systems such as Splunk or syslog, and confirm which of those integrations your SIEM already supports. Request a line item for the runbook test environment, because a runbook that changes production targets needs a non-production place to run. Finally, ask what happens to the stack at the end of the engagement, so you know who owns the code, the secrets and the operating documentation.
How to migrate Octopus runbooks to code
This sequence turns each Octopus runbook into version-controlled code that runs in StackStorm, Jenkins or a Kubernetes Job, with access controlled by groups from your identity provider and an audit trail for every run. The result is a tested replacement for each runbook and a documented cutover date.
Inventory every runbook and its owners
List each runbook in the Octopus Server or Cloud project pages, and for each one record its target machines or clusters, the variables and credentials it reads, the people who run it today, and the last time it ran. Ask the runbook owners to confirm the list, since runbooks that nobody claims are often the ones that break after cutover. The inventory is done when every runbook has one named owner and a target list that the owner has signed off.
Classify each runbook by trigger
Mark each runbook as scheduled, manual or event-driven. Scheduled work usually maps to a cron-style trigger in Jenkins or a CronJob manifest in Kubernetes. Manual work, such as an incident restart, usually maps to a parameterized Jenkins job or a StackStorm action run from the CLI or web UI. Event-driven work, such as remediating an alert, is a good fit for StackStorm sensors and rules, which watch external systems and fire triggers. The output is a classification table that the owners review.
Rewrite each runbook as code
Translate each runbook into a StackStorm workflow with actions and a pack, a Jenkinsfile with stages and steps, or a Kubernetes Job manifest, and store it in Git. Keep one runbook per file or pack so reviews stay small. Replace Octopus step variables with parameters or configuration files, and do not copy secret values into the repository. Each rewritten runbook is complete when it has a readable definition in version control and a pull request that the owner has approved.
Re-enter sensitive values from their source
Octopus does not export sensitive variables as plain values, so every password, token and key the runbooks use must be re-entered from its original owner or issuing system, such as the database team, the cloud account or the certificate authority. Store these values in your secrets manager and reference them by name from the StackStorm, Jenkins or Kubernetes definitions. Confirm the exact export behavior for your Octopus version with the vendor before you plan this step. The check is that each runbook resolves every secret from the store in a test run.
Map access groups from your identity provider
Create groups in your identity provider that match who may run each class of runbook, then map them to StackStorm RBAC roles (available in open source since version 3.4, including LDAP group mapping), Jenkins authorization, or Argo CD RBAC if the Job is triggered from Argo CD. Remove standing access that Octopus granted through teams that no longer need it. The check is a test login for one user per group that shows each role can run only its own runbooks.
Run parallel dry runs against non-production targets
Run each new runbook alongside its Octopus version against non-production targets, and compare the outputs, exit codes and changed state. Confirm that audit records appear in StackStorm execution history, Jenkins build logs or Kubernetes Job logs, and that they reach your log platform. Record each difference and fix it or accept it in writing. The step is complete when every runbook has a matching result in non-production for at least one full run of its trigger.
Cut over and retire the Octopus runbooks
Switch each runbook's trigger to the new implementation in an agreed change window, disable the Octopus runbook schedule, and keep the Octopus definition readable for a defined retention period set by your change policy. Confirm with your compliance team which audit evidence must be kept from Octopus. Once the retention period ends, remove the Octopus runbooks and their connected targets. Done means no runbook runs from Octopus and the owner has signed the cutover record.
What do teams ask before replacing Octopus runbooks?
How long does a runbook migration take, and what drives the timeline?
The timeline depends on how many runbooks exist, how many steps call external systems, and how many of them rely on secrets or approvals that have to be redesigned. Start with an inventory: count runbooks, list their targets (servers, Kubernetes clusters, cloud accounts, ticketing systems), and mark which ones run on a schedule or on an alert. Each runbook that becomes a StackStorm rule, workflow or action needs its own build, test and sign-off, so the count of runbooks and their dependencies sets most of the effort. No duration is stated here because it has not been supplied for this topic. Ask any implementation partner to break the estimate into inventory, build, test, cutover and handover, and to tie each phase to a written scope before work starts.
Can our team do this migration without outside help?
A team with platform or automation experience can do it in-house, provided someone owns the design of packs, rules and access policies. The work is mostly writing actions and workflows, wiring sensors and rules, and integrating with your identity provider and log pipeline. Outside help is most useful for the parts that are easy to get wrong: separating duties between runbook authors and approvers, deciding which secrets move into a secrets store, and producing evidence that auditors can follow. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms in your own environment under a written scope, and it can cover only the phases you choose to hand over.
What skills and access does our staff need for StackStorm?
Expect to need three skill sets: Python for custom actions and sensors, YAML for rules and workflow definitions, and Linux and container operations for running the services. StackStorm's services use MongoDB for storage and RabbitMQ for messaging, and its HA reference is a Helm chart on Kubernetes that is still a beta blueprint, so Kubernetes access and someone who can operate MongoDB and RabbitMQ are also needed. Your identity provider administrator must configure group mapping for RBAC through LDAP. Confirm these needs against your own environment before committing to a timeline.
Are RBAC and audit free in StackStorm, and what must we still build?
Yes, both are part of the open-source project. Role-based access control was donated to the Linux Foundation and has been in StackStorm open source since version 3.4, including role assignment from LDAP group membership. StackStorm also records an audit trail of every manual or automated action execution and can ship it to LogStash, Splunk, statsd or syslog. What you still build is the policy layer around them: which roles may run which runbooks against which targets, how credentials are scoped per target, how the audit stream is retained and reviewed, and how evidence is packaged for an assessment. The latest release referenced for this topic is v3.9.0, published January 12, 2026, so confirm the version you deploy against the StackStorm releases page.
How do approvals work for emergency and routine runbooks?
StackStorm does not replace Octopus's approval flow with a built-in ticket-style approval step for this topic, so approvals are a design decision you must make. The common pattern is to split runbooks into routine runs that a role can execute directly and high-impact runs that a workflow holds until a second person confirms through your ticketing or chat system. Emergency runbooks usually need a shorter path with stronger logging. Decide who can approve, how approvals are recorded, and what happens when the approver is unavailable before you write any workflow. Confirm the exact approval mechanism you intend to build with your team before sizing the work.
What happens to our run history during the migration?
Octopus keeps task logs and runbook run history in its own database, and that history does not move automatically into StackStorm. Export what you must keep before cutover, including the Octopus task logs for runs that matter to audits, and store them in your records system. From the migration date onward, StackStorm's execution records and audit trail become the source of truth. Run both systems in parallel for a period you agree in writing, and confirm with your compliance lead how long each history must be retained. Do not decommission the Octopus database until that retention decision is signed off.
What does a DeployOpen engagement cover for runbooks?
DeployOpen works under a fixed scope agreed in writing before work starts. For this topic that can include inventorying existing runbooks, deploying StackStorm in your own infrastructure, building packs, rules and workflows for the runbooks you select, configuring RBAC and audit shipping, documenting the controls, and preparing evidence for a compliance assessment. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do. Ongoing upgrades and support are available as retainers. Ask for a written quote that lists the runbooks in scope, the targets, the identity and logging integrations, and the handover deliverables.
How DeployOpen scopes and delivers runbook replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For runbook replacement, that means moving routine and emergency operations tasks into StackStorm, Jenkins jobs or Kubernetes jobs triggered from Argo CD, with access control and audit trails defined before anything goes live.
How we scope
- Inventory every Octopus runbook, its targets, its owners and how often each one runs in production.
- Classify runbooks by trigger type, such as manual, scheduled or event-driven, to choose StackStorm, Jenkins or Argo CD jobs for each.
- Agree in writing which runbooks, environments and access roles are in scope, since engagements are fixed-scope.
How we build
- Convert each runbook into version-controlled code, with StackStorm packs, Jenkinsfile stages or Kubernetes Job manifests.
- Map Octopus roles and scoped permissions to StackStorm RBAC, Jenkins authorization or Argo CD RBAC, including LDAP or SSO group mappings.
- Test each runbook against non-production targets and confirm that execution logs reach your chosen audit sink.
How we hand over
- Deliver runbook source, deployment configuration, secrets handling notes and an access control matrix for review.
- Document how each runbook is triggered, how approvals work and how to roll back a failed run in your environment.
- Run a handover session with operators and confirm that they can execute, audit and retire runbooks without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover platform upgrades, such as Jenkins LTS and Argo CD minor releases, and re-testing of changed runbooks.
- Confirm with us during scoping which support level, response expectations and upgrade cadence your written scope will include.
