Rundeck vs Ansible AWX: which to choose

Rundeck or Ansible AWX: when each one fits

Choose Rundeck if your operations team runs runbooks made of any script or tool reachable over SSH, and needs access control, scheduling and an audit trail around them. Choose AWX if your automation already is, or will be, Ansible playbooks and inventories, and you want a web UI and REST API that run them. The two overlap where both can execute a playbook, so the decision usually turns on what your existing automation is written in, not on which tool has more features.

Start with the content you already own. If you have a large library of Ansible roles, playbooks and inventories, AWX runs them with little rework and keeps the Ansible model intact. If your runbooks are shell, Python or vendor CLIs, Rundeck's job model fits them directly, and Ansible can still be called from a Rundeck job if you need it. Next, check the target platform. Rundeck reaches Linux and Unix nodes over SSH with public-key authentication, so confirm which of your hosts, network devices and Windows systems are reachable that way. Then check infrastructure: Rundeck's system requirements list supported databases, and AWX installs through the AWX Operator on Kubernetes, which adds a cluster dependency your team must already run.

Weigh the paused AWX releases against your risk tolerance. The AWX README states the last release was published on July 2, 2024, and that releases are paused during a large-scale refactoring, so the 24.6.1 release is the newest you can pull from the release page. Teams with a strict patch cadence or a formal vulnerability management process should ask how they would receive and test fixes if one is needed, and whether their own build of AWX will be supported. Rundeck, by contrast, publishes releases on its GitHub releases page. Confirm the current release status of both projects on the day you decide, because this is the factor most likely to have changed since this page was written.

Which platform fits which operations scenario

This table maps common operations scenarios to the platform that fits each one better, with the condition under which the other platform would win. Read each row as a starting point: your existing automation assets, host mix and on-call model usually decide the outcome more than feature lists do.

Scenario	Better fit and reason	The other platform wins when
Existing Ansible playbook library	AWX, because it runs your playbooks, inventories and credentials natively through a web UI and API without rewriting them.	You want to wrap playbooks inside broader runbooks that also call scripts, CLI tools or APIs, and Rundeck jobs can call the playbooks directly over SSH.
Mixed scripts and CLI tools across Linux and Unix hosts	Rundeck, because its jobs run any script or tool on nodes reached over SSH with public-key authentication.	Your estate is almost entirely managed through Ansible modules and idempotent configuration, where AWX's inventory and playbook model is the more natural control plane.
Self-service runbooks for on-call staff	Rundeck, because its web console exposes jobs with options, access control and logging that non-specialists can run safely.	On-call staff only need to trigger a fixed Ansible playbook, and AWX's job templates and surveys cover that without a second tool.
Kubernetes-first estates	Neither is a clear default. AWX is installed through the AWX Operator on Kubernetes, but its releases have been paused since July 2024, so confirm the support path before committing.	Your Kubernetes work is mostly GitOps or cluster-native tooling and runbooks are rare, which may make a dedicated operator-driven platform the simpler choice. Confirm both options against your cluster policies.
One tool for both runbooks and Ansible automation	Rundeck, if most of your operations logic is scripts and jobs and Ansible is one step among many. It can invoke Ansible from its job steps.	Ansible is your primary automation language, so AWX keeps inventory, credentials and playbook runs in one place without an extra layer.
Audit trails and job history for operations	Rundeck, which provides logging, execution history and access control as core job features. Confirm the exact audit fields your assessor needs.	Your audit requirements center on playbook change history and Git-based records, which AWX's project and job views may already satisfy. Verify this in a test environment.
Database and availability planning	Rundeck, which supports PostgreSQL, MySQL, MariaDB, SQL Server and Oracle for production, avoiding the embedded H2 default.	Your organization has already standardized on a Kubernetes-hosted PostgreSQL service that AWX's operator can use, and you accept the operator-managed install model.

How Rundeck and AWX are deployed and what that means for operations

Rundeck's default installation uses the embedded H2 database. The Rundeck documentation says H2 is not considered safe for production because it is not resilient if Rundeck is not shut down gracefully, so a production deployment needs an external database. The system requirements list MariaDB 10.11.6 or later, MySQL 8.0.35 or 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022 and Oracle 19c or later as supported options, and the Java 17 runtime is required. Because Rundeck runs as a service on a host or set of hosts, your team owns the operating system, the Java runtime, the database and the network path to the nodes it manages.

Database ownership: Your team provisions, backs up and patches the chosen external database, and Rundeck's job history and configuration live there.
Upgrades: You schedule Rundeck upgrades against a supported Java and database version, and test them before rollout. Current release lines are published on the Rundeck releases page.
Node access: Linux and Unix nodes are reached over SSH with public-key authentication, so key distribution and rotation sit with your team.
Single service footprint: A typical install is one application service plus its database, which keeps the moving parts small for a team without Kubernetes.
Commercial add-ons: Support, enterprise features and hosted options are a separate decision covered by PagerDuty's offerings, not by the open-source install.

Before you commit, confirm the database versions you plan to use against the current system requirements and the backup and restore process your team will run.

How Rundeck reaches nodes and what AWX drives through Ansible

Rundeck targets a node set and reaches Linux and Unix nodes over SSH with public-key authentication, according to its system requirements documentation. A job runs whatever command, script or tool the operator defines, so the reach extends to any system you can address over that channel, including network devices or appliances only if they accept a supported login path. The decision to make first is whether your node inventory and the private keys that open it will live in Rundeck's resource model and key storage, and who is allowed to run jobs against which nodes. Confirm with your security team how keys are generated, rotated and revoked, and test that a job fails cleanly when a key is removed.

AWX sits on top of Ansible. It provides a web-based user interface, a REST API and a task engine that executes playbooks, so its targets are the hosts in your Ansible inventory and its credentials are the machine, cloud and vault credentials you register inside AWX. That model suits teams whose change work is already written as playbooks and whose inventory is already maintained. The trade-off is reach: a step that is not an Ansible module, such as a call to an internal ticketing API or a vendor CLI with its own login flow, usually needs a wrapper playbook or a separate tool. Ask your platform team which systems sit outside Ansible today and whether AWX credentials can cover them without broadening standing access.

Before you choose, run a short proof of concept against a representative node group in your own environment. Verify SSH connectivity through your bastion and firewall rules, confirm where credentials are stored and who can read them, and check how each tool records which user ran which action on which host. Because AWX releases have been paused since July 2024, also confirm with Red Hat or your upstream maintainers how the installation path and Kubernetes operator will be supported for your planned deployment. Document the results so the decision rests on your network and credential policy, not on the tools' feature lists.

Scope, install methods, databases and release status compared

This table compares Rundeck and Ansible AWX on what each tool runs, how it reaches nodes, how it is installed and which databases it supports, along with license and release status. Read the release rows first if you are weighing AWX for new work, because its releases have been paused since July 2024.

Dimension	Rundeck (open source)	Ansible AWX
Primary scope	Runbook automation: runs any script, command or tool as a job across a set of nodes	Ansible control plane: runs Ansible playbooks through a web UI, REST API and task engine
Job model	Jobs with options, schedules, error handling and logging, defined in the web console or API	Job templates and workflows built around Ansible playbooks and inventories
Node reach	Linux and Unix nodes over SSH with public-key authentication, plus other integrations	Hosts reached through Ansible connection plugins, mainly SSH for Linux targets
Access control and scheduling	Documented access control and scheduling in the open source docs; confirm the exact role model for your version	Role-based access control and scheduling are part of the platform; confirm feature parity with your Ansible version
API and CLI	Web API and command line tools	REST API and web UI; confirm the CLI tooling your team needs
Install methods	Standard server install; the default embedded H2 database is not considered safe for production	AWX Operator is the preferred install since version 18.0; Docker install is for development and test only
Supported databases	MariaDB 10.11.6 or later, MySQL 8.0.35 or 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022, Oracle 19c or later	Confirm the database versions supported by the AWX release you deploy
Java or Kubernetes requirements	Java 17 runtime	Kubernetes cluster required for the AWX Operator install
License	Apache Software License 2.0	Apache-2.0
Latest release	v6.2.1, published September 9, 2026	AWX 24.6.1 and AWX Operator 2.19.1, both published July 2, 2024
Release status	Actively released, with 6.3.0 release candidates following	Releases paused during a large-scale refactoring; confirm current status before adopting

What the AWX release pause since July 2024 means for planning

The most important planning fact about AWX is that its last release, AWX 24.6.1, was published on July 2, 2024, and the project's README states that releases are paused during a large-scale refactoring. Treat AWX as a platform whose upstream release cadence you cannot currently rely on. The README links community posts describing a move toward a pluggable, service-oriented architecture and upcoming changes to AWX Operator installation methods. Both point to structural change ahead, which means the version you deploy today may not be the version whose upgrade path you can follow later.

For patching, the practical risk is that a security fix may arrive only as a change on the default branch rather than as a tagged release your change process can pin and test. Ask the project whether it will publish security fixes for the 24.6.x line, and how it will announce them. Your security team should decide in advance whether an unreleased fix from the repository is acceptable, and who approves it. Kubernetes compatibility carries the same uncertainty: the AWX Operator, the AWX custom resource and the Kubernetes version you run must be checked together. The AWX Operator's last release, 2.19.1, also dates from July 2, 2024, so confirm which Kubernetes versions the operator was tested against and whether that list will be updated.

Before committing, confirm three things in writing with the AWX maintainers or your Red Hat Ansible Automation Platform contact if you rely on that product. First, the planned release date or criteria for resuming releases. Second, whether the new installation method will be supported on your cluster platform and whether migration from the current operator-based install is documented. Third, what the upgrade path from 24.6.1 looks like if the architecture changes. Your security team should then decide whether a paused project is acceptable for the systems AWX would control, and whether Rundeck, with its own release line and the paid support options described in the sibling sections, is the better fit for that risk tolerance.

What is free and what is paid in Rundeck and AWX

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 covers the software itself, so you do not pay a license fee to run the open-source build in your own infrastructure. Your costs are the people and infrastructure needed to operate it.

License: Apache-2.0 for the open-source project, with the source available in the rundeck/rundeck repository.
Stated scope: the documentation frames free use around small-scale job writing and running, not a specific node count or user count.
Core features: access control, scheduling, error handling, logging, option passing, a web GUI, a REST API and CLI tools are part of the documented product.
Your costs: database hosting, Java 17 runtime operations, upgrades, backups and any custom integrations you build.
Default install: the embedded H2 database is not considered safe for production, so a supported external database is part of the real footprint.

Before you commit, confirm with PagerDuty which features and scale limits apply to the open-source build you plan to run in production, and do not assume small-scale wording covers your team's size.

What drives the running cost of each platform

Running Rundeck and AWX both carry infrastructure, skills, support and upgrade costs, but they fall on different teams and recur on different schedules. The cards below separate those components so a written quote can be compared line by line.

Database and runtime footprint

Rundeck needs a Java 17 runtime and an external database for production, and its supported options include MariaDB 10.11.6 or later, MySQL 8.0.35 or 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022 and Oracle 19c or later. AWX on Kubernetes needs a cluster plus a PostgreSQL database it manages with the AWX Operator. Ask the vendor or your platform team which database and cluster capacity the quote assumes, and who pays for backups and patching of each.

Cluster operations for AWX

The AWX Operator is the preferred install path since version 18.0, so AWX cost is mostly Kubernetes cost: cluster nodes, storage, ingress, certificate management and the staff who run them. Docker installs are for development and test only and have no official published release. Confirm whether your quote includes cluster build, monitoring and on-call coverage, or only the AWX deployment itself.

Job and playbook authoring skills

Rundeck jobs can call any script or tool over SSH, so the skill cost is in shell, scripting and node targeting. AWX runs Ansible playbooks, so the cost is in Ansible roles, inventories and idempotent task design. Both recur as runbooks change. Ask who will write and maintain the first set of jobs or playbooks and whether that work is in scope or billed separately.

Upgrade effort during the AWX pause

AWX's last release, 24.6.1, was published on July 2, 2024, and the README states releases are paused during a large-scale refactoring. The AWX Operator's latest release, 2.19.1, matches that date. Any AWX deployment you run now is pinned to a version that will not receive new releases, so the upgrade path and any refactoring-driven install changes become a planning risk. Ask how the quote handles upgrades if the project resumes.

Support and commercial edition

Rundeck Open Source is Apache-2.0 licensed and free for small-scale use, while PagerDuty's Runbook Automation, formerly Rundeck Enterprise and Process Automation, is the commercial offering built on it, available self-hosted or as SaaS. AWX is Apache-2.0 with no paid edition in its own repository, but Red Hat Ansible Automation Platform is built on it. Ask whether the quote includes vendor support, which tier it assumes, and whether it recurs annually.

What to request in a written quote

Ask for each line to be split into one-time work (design, installation, job or playbook migration, hardening, initial documentation) and recurring work (retainers, upgrades, backups, support subscriptions, database and cluster hosting). DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Request the assumed node count, job count, database version and any excluded upgrade or AWX refactoring work.

Moving from AWX to Rundeck or the reverse

This sequence moves automation from one control plane to the other without losing working jobs, access rules or audit history. It ends with both systems running in parallel and a documented cutover that the operations team has signed off.

Inventory current jobs and playbooks
The platform team lists every AWX job template, workflow, schedule and the playbooks, roles and scripts each one calls, and the operations team adds the runbooks that run outside AWX today. Record the owner, the trigger (manual, scheduled or API) and the target hosts for each item. Done means every automation has a row in one inventory and every row has a named owner who has confirmed it still runs in production.
Map credentials and inventories to node sets
Translate AWX inventories, groups and host variables into Rundeck node sets through its resource model, and identify which AWX credentials become SSH keys or stored secrets in Rundeck. Confirm with the security team how each credential is stored, rotated and scoped before any value is moved. Done means every target host resolves to a Rundeck node, each credential has a documented replacement and no secret is copied in plain text into a configuration file.
Decide what stays as Ansible content
Classify each automation as one of three outcomes: keep the playbook and run it from Rundeck as a job step, keep it in AWX because it depends on AWX-only features, or retire it. Note that Rundeck reaches Linux and Unix nodes over SSH with public-key authentication, so anything that relies on AWX's own execution environment or inventory plugins needs a specific test. Done means a decision record exists for every item, reviewed by the platform and security leads.
Rebuild schedules and access rules
Recreate schedules as Rundeck job schedules and rebuild permissions as Rundeck access control policies, mapping each AWX team and role to a Rundeck group with the narrowest rights that still allow the job. Test each permission with a non-administrative account before relying on it. Done means every scheduled job runs in Rundeck at its planned time and each role can perform only the actions it held in AWX.
Rebuild audit and integration hooks
Repoint notifications, ticketing and log forwarding that currently receive AWX job events to Rundeck's logging and API outputs, and confirm the retention period in each destination. Rundeck's API and external authentication integrations should be checked against the identity provider you already run. Done means a test job produces the same audit record in your central log store that the AWX job produced before, with the same user attribution.
Run both platforms in parallel
Keep AWX running for production jobs while Rundeck runs the migrated set against the same non-production nodes, and compare job output, exit status and changed-state results for each run. Use a written test plan that names who reviews each difference. Done means every migrated job has a recorded result matching the AWX result, or a logged and approved reason for each difference.
Cut over and document the outcome
Switch production schedules and triggers to Rundeck in batches, starting with the lowest-risk jobs, and set AWX schedules to disabled rather than deleting them so they can be restored. Confirm the rollback steps with the operations lead before each batch. Done means all in-scope jobs run from Rundeck, the decommission of AWX is recorded as a separate decision, and the change record is filed with the security and compliance owners.

Where Rundeck and AWX implementations usually run long

Rundeck implementations usually run long on the database and identity work, not on installing the server. The default install uses the embedded H2 database, which the Rundeck documentation says is not considered safe for production, so a production build means provisioning one of the supported external databases (MariaDB, MySQL, PostgreSQL, SQL Server or Oracle, at the versions listed in the system requirements) and deciding how Rundeck runs across more than one node. Plan the backup and restore path for that database early, and confirm with your own platform team how failover will work, since the documentation does not give you a high availability design for you. Identity is the second long item. Rundeck's access control policies, its integration with external authentication sources and its SSH public-key setup for Linux and Unix nodes each need an owner and a test plan before jobs go live.

AWX work runs long for different reasons. Since version 18.0 the AWX Operator is the preferred install method, so the project becomes a Kubernetes project first, with cluster sizing, storage classes, ingress, secrets and operator upgrades to settle before any playbook runs. Confirm with your Kubernetes team who owns the operator lifecycle, because AWX releases have been paused since July 2024 and the upgrade path is an open question you must answer from the project's own posts and your risk appetite, not from the release history. Credential management and identity integration (who logs in, which teams can launch which templates) also take longer than expected, because the access model usually has to be redesigned rather than copied from the existing shared-account habits.

The longest items on both platforms are usually migration and cleanup. Existing automation often lives in undocumented scripts, cron jobs and personal shell aliases that nobody has inventoried, and inventory data drifts from what is actually running. Budget time to map each job to an owner, a target set and a credential, and retire what no one uses. Scope, deliverables and timelines for an implementation of either platform are agreed in writing before work starts, so ask any partner, DeployOpen included, to list which of these items sit inside the fixed scope and which are retainer work.

Questions buyers ask before choosing between Rundeck and AWX

Is AWX still maintained after the release pause?

AWX is not shipping releases right now, so confirm its status before you commit to it. The ansible/awx README states that the last release was published on July 2, 2024, and that releases are paused during a large-scale refactoring. AWX 24.6.1 is the latest release on the releases page, and the AWX Operator's latest release, 2.19.1, was published the same day. The README links community posts on a move to a pluggable, service-oriented architecture and on upcoming changes to Operator installation methods. Those changes affect install and upgrade planning. Ask who will provide patches and upgrade paths in the interim, and whether any Red Hat Ansible Automation Platform subscription you hold covers the version you plan to run.

What does Rundeck's free open source edition cover?

Rundeck Open Source is Apache-2.0 licensed, and the Rundeck documentation describes it as free for teams that write and run jobs at small scale. It includes job scheduling, access control, error handling, logging, option passing, a web GUI, a REST API with CLI tools, and integration with external sources for authentication, resource model and option data. The license fee is zero, so your costs are staff time for installation, job authoring, database operations and hosting. Once you need PagerDuty's commercial Runbook Automation, in its self-hosted or SaaS form, that is a separate paid decision. The sources for this page do not give its price or feature list, so request both from PagerDuty in writing. Define "small scale" against your own job count and user count before you rely on the free edition.

Which database should Rundeck use in production?

Do not run production on the default embedded H2 database. The Rundeck documentation says H2 is not considered safe for production because it is not resilient if Rundeck is not shut down gracefully. The system requirements list MariaDB 10.11.6 or later, MySQL 8.0.35 or 8.4 or later, PostgreSQL 15.5 or later, SQL Server 2022 and Oracle 19c or later as supported options. Choose the database your DBAs already back up, patch and monitor, because it becomes part of your recovery plan. Cost drivers include schema setup, backup and restore testing, and connection and failover design. Ask the implementer to prove a restore on a copy of production before go-live.

Can existing Ansible playbooks run from Rundeck without a rewrite?

Usually yes, if the playbooks already run unchanged from the command line. Rundeck runs any script or tool, so a job step can call ansible-playbook on a node that has Ansible installed, and Rundeck reaches Linux and Unix nodes over SSH with public-key authentication. Check the parts that depended on AWX: inventory sources, vault passwords, stored credentials, surveys and workflow templates. Those need a Rundeck equivalent, such as option inputs, a resource model and project-level access control. Illustrative example: a playbook that an operator runs by hand from a jump host becomes one Rundeck job with an option for the target host limit. Test each converted job against non-production hosts before you retire the AWX template.

What does the internal team need to run Rundeck or AWX?

Rundeck needs people who can operate a Java 17 service, manage a supported SQL database, set up SSH public-key access to target nodes and design job authorization. AWX needs container platform skills, since the AWX Operator has been the preferred install method since version 18.0 and the Docker-based install is recommended only for development and test, with no official published release. You also need Ansible content skills in either case. Cost drivers are the number of nodes and jobs, existing Kubernetes capacity, and any gap in skills. Ask any implementer for a list of day-two operations tasks and who performs each one, then confirm effort with a pilot in your own environment.

Which AWX install method should you pick if you still choose AWX?

Use the AWX Operator. The ansible/awx INSTALL.md says the Operator has been the preferred install method since version 18.0, and the Docker-based install is recommended only for development and test. The AWX Operator is an Apache-2.0 Kubernetes operator built with the Operator SDK and Ansible, so you need a Kubernetes cluster you can run and patch. The README also links upcoming changes to Operator installation methods, so pin the Operator and AWX versions in your change records and plan an upgrade test for each change. Ask whoever installs it to document the cluster prerequisites, backup of the AWX database, and the upgrade path you will follow.

Is a partner worth hiring to deploy Rundeck or AWX?

A partner is worth considering when the gap is skills, time or evidence, and less so when your team already runs similar automation well. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for scope items that map to your node count, job inventory, database choice, identity integration and the AWX version decision. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

How access control and audit differ across both platforms

Access control and audit decide who can run what, against which hosts, and how that activity is recorded. Rundeck and AWX both expose a web interface and an API, but the supplied facts only document Rundeck's controls in detail, so the AWX side of each card is a set of questions to verify.

External authentication sources

Rundeck's documentation describes integration with external sources for authentication, which is the first thing to map against your directory. Confirm which identity protocols and directory services Rundeck supports in your version, and whether group membership from the directory maps to Rundeck roles. For AWX, confirm in its current documentation which single sign-on, LDAP or SAML options it supports and whether they are configured through the operator or the UI. Test a departed user's access on both platforms before go-live.

Role-based access control

Rundeck's documented access control covers who can view, run and administer projects and jobs. Map your existing roles to Rundeck's access policies before building jobs, because retrofitting roles after jobs are shared is slower. For AWX, read its current documentation on RBAC for organizations, teams, inventories and job templates, and confirm how it models a role that can launch a job without editing the playbook behind it.

Job-level permissions

Rundeck lets administrators control access at the level of individual jobs, so an operator can run a restart job without seeing the commands it executes. This matters for runbooks that touch production hosts. For AWX, check whether permissions attach to job templates, workflows and credentials, and whether a user who can launch a template can also read the credential it uses. Ask both vendors how a single permission change is reviewed.

Logging and audit trails

Rundeck's documented feature list includes logging, and job execution output is central to incident review. Confirm what Rundeck records per execution, who started it, which options were passed, and how long logs are kept, then decide where they are forwarded for retention. For AWX, confirm what its activity stream and job output capture, and whether logs leave the cluster in a form your SIEM can ingest. Do not assume either platform meets your evidence requirements without testing.

API access and tokens

Rundeck offers a REST API with CLI tools, so automation and chat integrations can trigger jobs. Each API token should carry only the rights of the account that owns it, and tokens should be rotated on a schedule. For AWX, the REST API is part of the product, but confirm how its tokens are scoped, expired and revoked. Pilot a token from a CI pipeline and verify that a revoked token stops working immediately on both platforms.

Credential storage and SSH keys

Rundeck reaches Linux and Unix nodes over SSH with public-key authentication, so the private keys it holds become a high-value target. Decide where keys live, who can read them, and how they rotate. For AWX, confirm how it stores machine and cloud credentials and whether those secrets can be displayed to users who only launch jobs. Ask both vendors what gets written to logs when a credential is used.

How DeployOpen helps choose, implement or migrate

DeployOpen approaches Rundeck vs Ansible AWX as a scoping question first, then as an implementation in your own infrastructure. We plan, implement, integrate, harden, back up, document and support self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.

How we scope

Written scope covers which automation paths you need: SSH-based jobs, Ansible playbooks, or both.
We document the target databases, install method and node reach before any build work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We install and configure the chosen platform inside your environment, including the database and authentication links.
Access control, job definitions and node targeting are set up to match your existing operating model.
Security testing and hardening are scoped in advance, so findings are tracked against the written plan.

How we hand over

You receive documentation of the configuration, integrations, backup routines and upgrade steps.
Handover covers the operating runbooks your team needs to run, change and recover the platform.
We confirm with you which open items remain and who owns each one after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer scope is set in writing, so you know which upgrade and maintenance tasks it covers.
Before any upgrade decision, we review the upstream release status with you and confirm the path.

Rundeck vs Ansible AWX