Rundeck or StackStorm: which fits your incident response model
Choose Rundeck when a person should decide when a fix runs. Rundeck's job model suits human-in-the-loop response: an on-call engineer or a self-service user picks a job, supplies options, and the run goes to the nodes selected through its node targeting, reaching Linux and Unix hosts over SSH with public-key authentication. Access control determines who can see and run each job, and the logs record what ran. Rundeck Open Source is Apache-2.0 licensed and, according to the Rundeck documentation, free for teams writing and running jobs at small scale. Before you commit, confirm that the embedded H2 database is replaced with one of the supported production databases, since the documentation does not consider H2 safe for production.
Choose StackStorm when you want the platform to act on events without waiting for a person. Its sensors watch external systems and fire triggers, and its rules map those triggers to actions or workflows. Content ships as packs through the StackStorm Exchange, which the repository describes as about 160 integration packs, so check whether the packs you need already exist and who will maintain them. StackStorm is Apache-2.0 licensed, and role-based access control has been part of open source since version 3.4, including role assignment from LDAP group membership. Plan for the running cost: StackStorm uses MongoDB for storage and RabbitMQ for messaging, and its high availability chart for Kubernetes is a beta blueprint, so confirm the support model you need before relying on it.
The decision turns on two questions. First, how much remediation should run without a human in the loop? Mostly supervised work points to Rundeck, while automatic response to alerts points to StackStorm. Second, which team owns the content? Rundeck jobs are often written by operations staff who run them, whereas StackStorm rules and packs are code that a platform or automation team must version, test and maintain. Map your last ten incidents against both questions before you choose, and ask a vendor or implementation partner to demonstrate the audit trail your compliance team needs in your own environment.
Which scenarios favor Rundeck and which favor StackStorm
This table maps common operations scenarios to the tool that usually fits better, with the condition that drives each choice. Read each row as a starting point: the deciding factor is often who triggers the work and whether it must react to events without a person in the loop. Where both tools could work, the condition column tells you what to test in your own environment.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| On-call operators running a known fix | Rundeck | The operator starts the job from the web console or API, and the team wants a clear, reviewed runbook step rather than an automatic trigger |
| Scheduled maintenance windows | Rundeck | Jobs run on a schedule with logging, option passing and error handling, and the work does not depend on incoming events |
| Self-service for support staff | Rundeck | Access control and option forms let non-engineers run approved jobs against limited node sets; confirm the role model fits your identity setup |
| Auto-remediation triggered by alerts | StackStorm | Sensors watch monitoring or messaging sources, and rules map those triggers to actions or workflows without a person starting each run |
| Mixed human and automated approvals | Either, after testing | Rundeck suits human-initiated approvals on jobs, while StackStorm suits event flows that pause for input; confirm how each handles your approval steps in a pilot |
| Integrating many SaaS tools | StackStorm | Packs and the StackStorm Exchange provide many prebuilt integrations, but confirm each pack's maintenance status and fit with your SaaS versions before relying on it |
How Rundeck and StackStorm are built and what that means for operations
Rundeck and StackStorm take different shapes at install time, and that shape decides who keeps them running. The cards below cover how each one stores state, reaches nodes and scales, and what a small team should check before committing to either.
Rundeck runs as one application
Rundeck is a single application with a web console, CLI and API that runs jobs across a set of nodes. Its default install uses the embedded H2 database, which the documentation says is not considered safe for production because it is not resilient if Rundeck is not shut down gracefully. A small team should plan an external database from the start, choosing from the supported MariaDB, MySQL, PostgreSQL, SQL Server or Oracle versions listed in the system requirements, and confirm the Java 17 runtime fits its patch process.
Rundeck reaches nodes over SSH
Rundeck reaches Linux and Unix nodes over SSH with public-key authentication, so the operational work sits in key distribution, the node resource model and the SSH access policy on each target. For a team that already manages SSH keys, this keeps the moving parts familiar. Confirm how the node list is sourced, whether from a static file or an external inventory, and who is responsible for rotating the keys Rundeck holds.
StackStorm is a set of services
StackStorm is built from loosely coupled microservices that communicate over a message bus, scale horizontally and expose a REST API, CLI and web UI. Its services use MongoDB for storage and RabbitMQ for messaging, so a team adopting it runs three stateful systems rather than one application. Before choosing it, confirm the team can operate MongoDB and RabbitMQ backups, upgrades and failover, not only the StackStorm processes themselves.
HA on Kubernetes is still beta
StackStorm documents a helm chart for a high-availability cluster on Kubernetes, and that chart is available as a beta blueprint. A small operations team should treat it as a starting point for a test environment, not a production runbook. If high availability is a requirement, ask the StackStorm community or your own platform team to confirm the chart's current status, supported configurations and upgrade path before you design around it.
Sensors and rules add a second moving part
StackStorm's sensors are Python plugins that watch external systems and fire triggers, and rules map those triggers to actions or workflows. This suits event-driven remediation, but every sensor is code that must be deployed, versioned and monitored. Rundeck has no equivalent always-on watcher layer for its jobs, so the question for your team is whether you want that continuous component running in production.
Access control is part of the deployment plan
StackStorm's role-based access control, which was once part of its enterprise edition, is available in open source since version 3.4, including role assignment from LDAP group membership. Rundeck also supports access control and external authentication sources. Either way, map your groups, roles and approval paths before rollout, and confirm with the vendor how each tool handles role changes that come from your directory.
Access control, node targeting, audit and extensibility compared
This table compares how Rundeck and StackStorm handle licensing, triggers, access control, node reach, audit and extensibility, with the release lines current in the supplied facts. Read each row as a question about your own operating model: who starts the work, who may run it, where it runs and what evidence remains afterward. Both platforms are Apache-2.0, so the decision usually turns on whether people or events should drive the automation.
| Capability | Rundeck | StackStorm |
|---|---|---|
| License | Apache Software License 2.0 for Rundeck Open Source | Apache-2.0 |
| Trigger model | Operators run jobs manually or on a schedule from the web console, CLI or web API | Sensors watch external systems and fire triggers, and rules map those triggers to actions or workflows |
| Access control | Access control is a documented core feature of Rundeck; confirm which roles and project-level permissions your edition provides | Role-based access control is in open source since version 3.4, including role assignment from LDAP group membership |
| Node targeting | Resource model targets nodes; Linux and Unix nodes are reached over SSH with public-key authentication | Actions such as SSH target hosts, so node reach is defined per action and per pack rather than through a central node inventory model |
| Audit trail | Logging is listed in the documentation; confirm what job execution history, output and change records your version retains and how they export | Records an audit trail of every manual or automated action execution and can ship it to LogStash, Splunk, statsd or syslog |
| Extensibility | Any script or tool that runs on a target node can be wired into a job | Integrations are delivered as packs; the repository cites about 160 integration packs with more than 6,000 actions |
| Latest release line | v6.2.1, published September 9, 2026 | v3.9.0, published January 12, 2026 |
What is free in Rundeck and StackStorm and what PagerDuty sells
Rundeck Open Source is licensed under the Apache Software License 2.0, and the Rundeck documentation describes it as free for teams that write and run Rundeck jobs at small scale. The license cost is zero, but your team still pays for the hosting, database, upgrades, backups and the staff who maintain jobs and access rules. The open source edition covers the core job model, scheduling, access control, option passing, logging, a web GUI, a REST API and CLI tools.
- License terms: Apache-2.0 allows self-hosting and modification without a license fee for the open source code.
- Small-scale wording: The documentation frames the free use around small-scale teams, so confirm with PagerDuty where your job count and node count fall.
- Database choice: The default embedded H2 database is not considered safe for production, so you need a supported external database such as PostgreSQL or MySQL.
- Operating effort: Your staff own installation, patching, backups and the Java 17 runtime.
- Support: Community support is the default, so confirm what response options exist for your environment.
Before you rely on the free tier, check your planned job volume and node count against the documented small-scale guidance.
Runbook Automation, formerly Rundeck Enterprise and Process Automation, is PagerDuty's commercial offering built on open source Rundeck. It is offered as Runbook Automation Self-Hosted and as SaaS, so the buying decision includes a hosting model as well as a feature set. Buyers pay PagerDuty for the commercial product and its support, while the open source core remains available separately.
- Two delivery forms: Self-Hosted keeps the runtime in your environment, while SaaS moves hosting to PagerDuty.
- Renamed product: The offering was formerly called Rundeck Enterprise and Process Automation, so older quotes and documents may use either name.
- Feature differences: Confirm in writing which capabilities are included in the commercial product that are not in the open source edition.
- Pricing: PagerDuty does not provide pricing in the sources we reviewed, so request a written quote that lists modules, node counts and support terms.
- Support and upgrades: Ask what support window, upgrade path and version guarantees apply to each delivery form.
Ask PagerDuty to map each feature you need to either the open source edition or the commercial product before comparing totals.
StackStorm is licensed under Apache-2.0, and its open source release includes role-based access control. The RBAC model was donated to the Linux Foundation and is available in open source since version 3.4, including role assignment from LDAP group membership. Because the supplied facts cover the open source project only, edition details beyond these points must be confirmed with the StackStorm maintainers before you assume any feature is free or paid.
- Open source license: The Apache-2.0 license covers the core platform, sensors, actions, rules and packs.
- RBAC included: Role-based access control is available in open source since version 3.4, so access control does not depend on a paid tier.
- LDAP role mapping: Roles can be assigned from LDAP group membership, which supports directory-based access.
- Current release: StackStorm v3.9.0 was published on January 12, 2026, so check the release notes for your target version.
- Edition questions: Ask the maintainers whether any commercial support, hosted service or add-on exists and what it covers.
Confirm the current edition structure and support options with the StackStorm maintainers before you write a cost comparison.
Moving runbooks from Rundeck to StackStorm, or the reverse
This sequence sorts existing Rundeck jobs into manual runbooks and event-driven rules, rebuilds access and content in the target model, and proves parity through a parallel run before any cutover. The output is a migrated set of automations with a documented audit comparison and a clear list of items that needed manual redesign.
Inventory jobs and their node sets
Export every Rundeck job definition, its options, schedules, notification settings and the node filters or resource model entries it targets. Record which jobs run over SSH, which call external APIs and which depend on Rundeck-specific option passing or step plugins. Someone who owns the operations runbooks should review the list with the platform team. The step is complete when every job has an owner, a target node set and a dependency note, and the team agrees the inventory matches what actually runs in production.
Separate manual jobs from rule candidates
Sort the inventory into two groups. Operator-triggered runbooks, such as a service restart an on-call engineer launches during an incident, stay as manual actions. Jobs that should run automatically when a signal arrives, such as a disk alert or a failed health check, become candidates for StackStorm sensors and rules. Each candidate needs a named trigger source and a clear condition. The output is a short register that marks each job as manual, automated or split, with the reason recorded beside it.
Rebuild access rules as RBAC roles
Translate the Rundeck access control policies, which govern who can view, run and edit each job and project, into StackStorm role-based access control assignments. Map each permission to the pack, action or rule it covers. Confirm with the security team which StackStorm open-source RBAC capabilities match the existing policy, since the current StackStorm RBAC documentation should be checked against the version you deploy. The check is complete when a test user with each role can perform only the actions the old Rundeck policy allowed, and the results are recorded.
Map identity groups
Connect the directory groups that Rundeck uses for authentication to the equivalent groups in StackStorm. StackStorm can assign roles from LDAP group membership, so confirm the group names, nesting and any service accounts used for automation. Document which identities can trigger jobs manually and which accounts the automated rules run under. Verify with a set of test accounts that group changes in the directory produce the expected access in StackStorm, and that removed users lose access. The output is a group-to-role map signed off by the identity owner.
Rebuild content as packs
Recreate the manual runbooks as StackStorm actions and workflows, and the rule candidates as sensors, triggers and rules, packaged in StackStorm packs stored as code. Where a Rundeck job calls a script, decide whether to wrap the script as an action, call it over SSH from an existing action or rewrite it. Check whether an existing pack in the StackStorm Exchange already covers the integration before writing new code. The step closes when every migrated item is in version control, deployed to a non-production environment and passes a documented test run.
Run both platforms in parallel
Keep Rundeck running while StackStorm handles the migrated automations in a test or shadow environment. For the same incident types, compare the actions taken, the target nodes, the timing and the outcome in each platform's logs. StackStorm records an audit trail of every execution and can forward it to LogStash, Splunk, statsd or syslog, so route both platforms' records to the same review location. The step is complete when the audit records match for each agreed scenario and every difference has an explanation or a fix.
Cut over and retire the old jobs
Switch production triggers and manual access to StackStorm one group of jobs at a time, starting with the lowest-risk runbooks. Keep the Rundeck definitions readable and exported until the rollback window you agreed closes. Update on-call documentation so responders know where to run each action. The cutover is finished when all migrated items run from StackStorm, the Rundeck export is archived with its inventory and the audit comparison is filed with the change record.
Note what does not transfer directly
Job definitions and pack content use different models, so expect manual redesign. Rundeck option passing, node filters and its resource model do not map one-to-one onto StackStorm actions, sensors and rules. Rundeck's embedded H2 database and its other database backends do not carry over as data, so plan to rebuild schedules and history by export and import where possible. Scheduled Rundeck jobs become a different construct in StackStorm, and some Rundeck plugins may have no StackStorm equivalent. Confirm each gap with the vendor documentation and your own tests before the cutover is scheduled. The same caution applies when moving in the reverse direction.
What drives the running cost of each platform
Infrastructure is the first cost driver, and the two platforms差 differ sharply in how many moving parts you run. A Rundeck deployment is a single Rundeck service backed by an external database. The supported databases listed in its system requirements include MariaDB, MySQL, PostgreSQL, SQL Server and Oracle, and the embedded H2 database is not considered safe for production. StackStorm is built from loosely coupled microservices that communicate over a message bus, and its services use MongoDB for storage and RabbitMQ for messaging. A high-availability cluster on Kubernetes is available as a beta helm chart, so a production StackStorm estate usually means operating more components, their backups and their scaling. Ask each vendor or partner to list every service, database and message broker in the target design, then price the hosts, storage, backups and monitoring for each one in your own cloud accounts or data center.
Skills are the second driver, and they are usually the largest recurring cost. Rundeck work centers on Java runtime operations, database administration, SSH key management for target nodes and writing job steps in the scripting language your team already uses. StackStorm work requires Python for sensors, actions and rules, the pack lifecycle for integrations you build or vet, and operational knowledge of MongoDB, RabbitMQ and the message bus that ties the services together. If your team lacks one of these skill sets, the cost shows up as hiring, training or outside engagement time. Before you compare quotes, have your own engineers name which of these skills they already hold, and budget for the gap as a recurring line rather than a one-time setup fee.
Support and upgrades decide how the running cost changes over time. Rundeck is open source under Apache-2.0, and PagerDuty sells commercial tiers, including Runbook Automation Self-Hosted and SaaS, built on the same codebase. Confirm with PagerDuty which support, upgrade and security response terms apply to each tier and whether any of them covers your self-hosted deployment. StackStorm is also Apache-2.0, and its release line moves through versions such as v3.9.0, which was published on January 12, 2026. Confirm with the StackStorm project, a commercial support provider or your implementation partner what support is available and how security fixes reach you. Upgrade effort on either side depends on pack compatibility, database migrations and the number of services to roll forward, so ask for a written upgrade plan and a per-release effort estimate in every quote.
Questions buyers ask before choosing Rundeck or StackStorm
How much effort does it take to run Rundeck compared with StackStorm?
Rundeck is usually the lighter system to run for operator-triggered jobs, while StackStorm asks for more moving parts because it is built from loosely coupled microservices. Rundeck needs a Java 17 runtime and a supported database, and its documentation says the embedded H2 database is not considered safe for production, so a production install means an external database such as PostgreSQL 15.5 or later. StackStorm services use MongoDB for storage and RabbitMQ for messaging, and its HA Kubernetes helm chart is a beta blueprint. Effort recurs through upgrades, database backups, credential rotation and pack maintenance on both sides. Confirm your own node count, number of jobs and integrations, and the team's existing skills with MongoDB, RabbitMQ and Kubernetes before estimating.
Can a small team realistically operate StackStorm in production?
A small team can operate StackStorm, but it needs at least one person comfortable with its services and the message bus, not just scripting skills. The platform runs sensors, rules, actions and workflows as separate services that communicate over a message bus, and it depends on MongoDB and RabbitMQ. Day-two work includes monitoring each service, keeping packs current, and handling failures in the event path, where a stalled sensor can silently stop remediation. Small teams usually fare better when they limit the first rollout to a few high-value rules and a narrow set of packs. Ask the vendor or community for the current guidance on running the HA setup, and test failover in your own environment before depending on it for incidents.
What drives the implementation work for a Rundeck or StackStorm deployment?
Implementation work is driven by the number of target systems, the authentication model, and how many automations must be written and tested. For Rundeck, the main drivers are node targeting through the resource model, SSH public-key setup across Linux and Unix nodes, and wiring authentication and option data to external sources. For StackStorm, the drivers include writing or adapting sensors for each event source, choosing packs from the StackStorm Exchange, and building rules that map triggers to actions or workflows. Both need logging and audit export configured. Scope the work in writing with a fixed list of systems, first-wave automations and acceptance tests, so the quote reflects a defined set of deliverables.
Can our own team do the Rundeck or StackStorm implementation in-house?
Your team can do it in-house if it has skills in Linux administration, the chosen database, identity integration and automation scripting, and if it has time to test failure paths. Rundeck is often the easier starting point because jobs can be written as scripts and run over SSH with few new services. StackStorm needs more platform knowledge: sensors, rule design, pack development and operating MongoDB and RabbitMQ. Ownership gaps usually appear in the first incident, when a rule fires unexpectedly or an action runs with the wrong credentials. A partial model is also common, where internal staff own day-to-day jobs and an implementation partner handles architecture, hardening and documentation under a fixed-scope agreement. DeployOpen plans, implements, hardens and documents self-hosted platforms in the client's infrastructure, so that option can be scoped in writing.
How long does a migration between Rundeck and StackStorm usually take?
Migration length depends on how many jobs, rules and integrations must be moved and how much of their logic is tied to the old platform. No duration figure is supplied for this move, so treat any number you hear as a claim to verify. The main drivers are the count of jobs that depend on Rundeck node targeting or options, the number of event sources that would need new sensors, the access model that must be recreated (Rundeck access control or StackStorm RBAC with LDAP group mapping), and the audit requirements that must carry over. Parallel running is usually needed so that both systems can be checked before old automations are retired. Ask for an inventory of jobs and rules, a cutover plan and a rollback path in the written scope.
Can Rundeck trigger automation on events, or does it need StackStorm?
Rundeck is built primarily around operator-triggered and scheduled jobs, and it exposes a web console, command line tools and a web API for running them. It does not have the sensor and rule model that StackStorm uses to watch external systems and fire triggers. Teams that need event-driven remediation with Rundeck typically call its API from an external alerting or monitoring system, and that design should be tested for ordering, retries and credential handling. StackStorm is designed for this pattern, with sensors that watch systems, rules that map triggers to actions, and an audit trail of each execution. Confirm the exact trigger options in the current Rundeck documentation for your version before designing the integration.
How do audit trails and access control compare between Rundeck and StackStorm?
Both platforms support access control and record activity, but they differ in what is recorded and how roles are assigned. Rundeck's documentation lists access control, logging and integration with external sources for authentication, which covers the job and node permissions most operators use. StackStorm records an audit trail of every manual or automated action execution and can ship it to LogStash, Splunk, statsd or syslog. Its role-based access control has been available in open source since version 3.4, including role assignment from LDAP group membership. Before choosing, confirm with your auditors which events they need, how long logs must be retained, and whether the export format meets your SIEM requirements.
Where implementation projects with each platform usually run long
Rundeck projects tend to run long on decisions made before the first job is written. The database choice comes first: Rundeck's default install uses the embedded H2 database, which the documentation says is not considered safe for production, so a production build needs one of the supported external databases (MariaDB, MySQL, PostgreSQL, SQL Server or Oracle) with versions checked against the system requirements. Next comes SSH key distribution to Linux and Unix nodes, which uses public-key authentication and needs a clear owner for key rotation. The resource model and job library decide how much rework follows. Teams that build jobs before agreeing on node tags and option naming usually rewrite them later. Confirm with your own environment how identity integration will map external groups to Rundeck roles before the job library grows.
StackStorm projects usually run long in three places. The first is service deployment: StackStorm is built from microservices on a message bus, uses MongoDB and RabbitMQ, and a Helm chart for an HA cluster on Kubernetes is listed as beta, so confirm the supported topology with the vendor before committing. The second is pack selection and authoring. Packs are stored as code, and the Exchange holds a large catalog, but each pack's actions still need review, credentials and testing in your environment. The third is sensor tuning and rule testing. Sensors are Python plugins that fire triggers, and a noisy event source can flood rules with work that is not remediation. Plan for rule test cycles against replayed or staged events, not only production traffic.
Access model design is the most common overrun for both platforms. In StackStorm, RBAC is available in open source since version 3.4, including role assignment from LDAP group membership, so the RBAC mapping from directory groups to StackStorm roles must be designed and tested with the security team, not left to a default. In Rundeck, the access control model governs who can run, edit and view jobs, and it should be settled before self-service users are onboarded. Ownership of automation content is the hidden risk in both: someone must own each job, rule and pack, approve changes and retire stale content. Ask who signs off on remediation actions that touch production, and how the audit trail will be retained and shipped to your log platform.
Risks to check before committing to either platform
Rundeck and StackStorm fail in different places. Rundeck's risks sit in who runs jobs and where its state lives, while StackStorm's sit in how many moving parts run its automation and who maintains the content it depends on. Confirm the mitigation for each card in your own environment before you commit.
Unattended remediation changing production
StackStorm rules can fire actions automatically when a sensor reports an event, so a faulty rule or a noisy sensor can restart services or change configuration without an operator present. Decide which remediations may run unattended and which must wait for approval. Ask the vendor or your test team to confirm how rules are staged, tested and disabled, and whether a rule can require a human confirmation step before its action runs. Rundeck jobs are normally started by a person or a schedule, which narrows this risk, but scheduled jobs still act without review.
Who can edit jobs and rules
In Rundeck, whoever can edit a job can change what runs on production nodes, so job editing rights are effectively execution rights. In StackStorm, role-based access control is available in open source from version 3.4, and roles can be assigned from LDAP group membership. Confirm that your identity groups map to the roles you intend, that rule and pack changes are limited to a small team, and that editing rights are reviewed on the same schedule as production access.
Database resilience for Rundeck
Rundeck's default install uses the embedded H2 database, which the documentation does not consider safe for production because it is not resilient if Rundeck is not shut down gracefully. A production deployment needs an external database from the supported list, such as PostgreSQL or MySQL, with its own backup and restore plan. Confirm which database your team will operate, who owns its backups, and how you will test a restore of job definitions and execution history before go-live.
Service sprawl for StackStorm
A StackStorm deployment brings together its microservices, a message bus, MongoDB for storage and RabbitMQ for messaging, and the sensors and rules that depend on them. Each component adds patching, monitoring and failure modes that a Rundeck single-service install does not carry. The StackStorm high availability helm chart on Kubernetes is documented as a beta blueprint. Ask who will run the message bus and datastore, how components are upgraded together, and whether your platform team has the skills to operate them.
Third-party pack maintenance
StackStorm integrations ship as packs from the StackStorm Exchange, and the repository description cites about 160 integration packs with more than 6,000 actions. Those packs are maintained by different authors, so quality, update frequency and security fixes vary. Before you rely on a pack, check its last release, its maintainer, the credentials it needs and whether you can fork and patch it yourself. Rundeck jobs call scripts and tools you already own, which keeps this dependency smaller.
Release cadence on both sides
Rundeck v6.2.1 was published on September 9, 2026, with 6.3.0 release candidates following, and StackStorm v3.9.0 was published on January 12, 2026. Both projects move at different speeds, and each upgrade can change job, rule, pack or database requirements. Set a written upgrade policy that covers test environments, rollback steps and which version you will pin. Check the release notes for each version you plan to run before you schedule a change window.
How DeployOpen helps teams choose and implement runbook automation
Choosing between Rundeck and StackStorm is easier when the decision is framed around who will own the platform after launch. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For this pair, that work usually means deciding where the Rundeck database or StackStorm's MongoDB and RabbitMQ services will run, how SSH keys or sensor credentials are stored, how LDAP groups map to roles, and where audit records are shipped. Those decisions are specific to your environment, and they shape the effort more than the choice of product does.
Every engagement starts from a written, fixed scope. Scope, deliverables and timelines are agreed in writing before work begins, and a quote follows from that scope rather than from a published price list. Ask any implementation partner, DeployOpen included, to itemize the node inventory, integrations, identity configuration, database setup, backup and restore testing, documentation and handover. Also ask which items are one-time work and which recur, such as upgrades, patch cycles and ongoing support. Ongoing support, upgrades and continuous testing are available as retainers, so the recurring cost can be scoped separately from the initial build.
DeployOpen is not a vendor partner, reseller or certified provider of PagerDuty, Rundeck, StackStorm or any related vendor, and it does not sell licenses for either platform. Licensing questions, including which Rundeck edition or support terms fit your organization, should be confirmed directly with the vendor. DeployOpen can prepare the environment, controls and evidence for your own review, but independent auditors and certification bodies issue any attestation. Before signing, request a written scope that names the platform you select and the decision points you want the partner to document.
