rundeck · smartinellibenedetti · Aug 4, 2025 · Apr 23, 2025 · Apr 23, 2025 · Apr 24, 2025
diff --git a/.docsearch/config.json b/.docsearch/config.json
@@ -8,7 +8,7 @@
         "version": [
           "docs",
           "4.0.x",
-          "5.13.0"
+          "5.14.0"
         ]
       }
     }

diff --git a/docs/.vuepress/setup.js b/docs/.vuepress/setup.js
@@ -1,8 +1,8 @@
 import { BaseTransition } from "vue"
 
-const RUNDECK_VERSION='5.13.0'
-const RUNDECK_VERSION_FULL='5.13.0-SNAPSHOT'
-const API_VERSION='52'
+const RUNDECK_VERSION='5.14.0'
+const RUNDECK_VERSION_FULL='5.14.0-SNAPSHOT'
+const API_VERSION='53'
 const API_DEP_REL='6.0.0'
 const API_DEP_VER='17'
 const API_MIN_VER='14'

diff --git a/docs/.vuepress/sidebar-menus/history.ts b/docs/.vuepress/sidebar-menus/history.ts
@@ -70,6 +70,10 @@ export default [
             text: 'Version 5.x',
             collapsible: true,
             children: [
+              {
+                text: "5.14.0",
+                link: "https://docs.rundeck.com/5.14.0/"
+              },
               {
                 text: "5.13.0",
                 link: "https://docs.rundeck.com/5.13.0/"

diff --git a/docs/administration/runner/index.md b/docs/administration/runner/index.md
@@ -33,56 +33,7 @@ Tasks can be carried out over multiple environments simultaneously, thereby redu
    - The Runner can be used to discover inventory in secure or remote environments. 
 8. The Runner can be deployed as a container within Kubernetes clusters to perform actions within the cluster.
 
-
-[//]: # (#### Providing Teams with Autonomy & Flexibility)
-
-[//]: # ()
-[//]: # ()
-[//]: # ()
-[//]: # (![Runners for Distributed Teams]&#40;/assets/img/runners-for-distributed-teams.png&#41;<br>)
-
-
-[//]: # (Building and orchestrating automation in complex multi-cloud and remote environments presents several challenges. The first challenge is that DevOps and Operations engineers need an alternative  to run automation in secure application environments that mandate a zero trust architecture where accessing private networks through SSH is deprecated. Next, significant engineering effort is required to deploy and manage automation that performs well across many remote environments and geographical regions. Lastly, creating resilient automation runbooks is time consuming and prone to error when coordinating a variety of complex environments.)
-
-[//]: # ()
-[//]: # (We are introducing a next generation architecture to address these challenges. With the new Runbook Automation architecture,  DevOps and Operations engineers can easily manage automation in a central UI while delegating job execution within different private networks or multi-cloud environments without needing to open SSH ports for accessing those networks. The new architecture separates workflow orchestration from task execution. It offers next generation remote Runners that include common integration plugins like Ansible and Kubernetes that execute locally to the application environment.)
-
-[//]: # ()
-[//]: # (![Next generation automation]&#40;/assets/img/architecture-nextgen.png&#41;)
-
-[//]: # ()
-[//]: # (The Runner, available for both Runbook Automation, securely opens up network/communication between data centers and the Automation Cluster. The Runner is a Remote Execution hub for Node Steps to run on specified endpoints, rather than from the Automation server itself.)
-
-[//]: # ()
-[//]: # (## System Architecture)
-
-[//]: # ()
-[//]: # (The Runner is a Java based program which uses a polling model to pick up work from the Automation Server. During each polling cycle &#40;every 5 seconds&#41; the Runner checks for executions that it is responsible for. Communication from the Runner to the Automation Server happens over https and is initiated from the Runner. This allows for enhanced firewall security as ports no longer need to be open for the Automation Server to talk to nodes over more sensitive ports. _&#40;e.g. SSH/22&#41;_)
-
-[//]: # (![Runner Architecture]&#40;/assets/img/runner-arch-diagram.png&#41;)
-
-[//]: # ()
-[//]: # (## Example scenario using the runner architecture)
-
-[//]: # ()
-[//]: # (With the next generation architecture, automation authors can select which Runners will carry out the tasks for a given job using Runner tags. Authors can also choose if tasks will execute on a Runner or if tasks will be dispatched to nodes through the selected Runner set. There are two types of Runners: Local and Remote. The Local Runner tasks execute from the Rundeck instance. The Remote Runner tasks execute from the Runners installed in the environment.)
-
-[//]: # ()
-[//]: # (![Private networks scenario]&#40;/assets/img/runner-scenario.png&#41;)
-
-[//]: # ()
-[//]: # (In the example below, we have a job that will span three different environments.)
-
-[//]: # ()
-[//]: # (1. The 1st step &#40;Check Cloud Services Status&#41; is a reference job that is configured with a Remote Runner which will execute a Kubernetes plugin as a workflow step.)
-
-[//]: # (1. Steps 2,3, and 4 are configured to run on the Local Runner.)
-
-[//]: # (1. Step 5 &#40;Check System Resources&#41; is also a reference job similar to step 1, but executes an Ansible playbook through the Ansible plugin and targets nodes in the second environment through a separate Remote Runner.)
-
-[//]: # (1. Step 7 &#40;Run DB Lock Check&#41; is also a reference job similar to step 1 and 5, but executes a Powershell command through the WinRM plugin and targets nodes in the third environment through a separate Remote Runner.)
-
-## Enabling the Latest Runner Features
+### Enabling the Latest Runner Features
 
 To use the latest Enterprise Runner features, the following feature-flag must be enabled in **System Configuration** or optionally in the `rundeck-config.properties` file if using the self-hosted software.
 

diff --git a/docs/administration/runner/runner-installation/creating-runners.md b/docs/administration/runner/runner-installation/creating-runners.md
@@ -21,14 +21,19 @@ If setting up Enterprise Runners on virtualized environments, here are baseline
 
 |               | **Minimum** | **Medium** | **Large** |
   |---------------|-------------|------------|-----------|
-| **vCPU**      | 4 cores     | 8 cores    | 12 cores  |
-| **Memory**    | 8 GiB       | 16 GiB     | 32 GiB    |
-| **Java Heap** | 6 GiB       | 12 GiB     | 24 GiB    |
-| **Storage**   | 40 GiB      | 40 GiB     | 40 GiB    |
+| **vCPU**      | 2 core      | 4 cores    | 8 cores   |
+| **Memory**    | 4 GiB       | 8 GiB      | 16 GiB    |
+| **Java Heap** | 2 GiB       | 6 GiB      | 12 GiB    |
+| **Storage**   | 8 GiB       | 20 GiB     | 20 GiB    |
 
 ### Permissions
+
+<details>
+    <summary> ACL Permissions for Creating Runners at <strong>System</strong> level</summary>
+
 To create a Runner at the **System level**, users will need the following ACL permissions:
-```
+
+```acl
 by:
   group: my-user-group-name
 description: Allow creating of Runners at the System level
@@ -41,42 +46,50 @@ context:
 
 ---
 by:
-  group: my-user-group-name
+group: my-user-group-name
 description: Allow "write" access within Runner management at the System level
 for:
-  resource:
-  - allow:
+resource:
+- allow:
     - admin
-    equals:
+      equals:
       kind: runner
-context:
-  application: rundeck
+      context:
+      application: rundeck
 ---
 by:
-  group: my-user-group-name
+group: my-user-group-name
 description: Allow creation of apitokens (general)
 for:
-  apitoken:
-  - allow:
+apitoken:
+- allow:
     - create
-context:
-  application: rundeck
+      context:
+      application: rundeck
 ---
 by:
-  group: my-user-group-name
+group: my-user-group-name
 description: Restrict apitoken creation to only generate_service_token to be used for Runners
 for:
-  resource:
-  - allow:
+resource:
+- allow:
     - generate_service_token
-    equals:
+      equals:
       kind: apitoken
-context:
-  application: rundeck
+      context:
+      application: rundeck
 ```
 
+* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
+
+</details> 
+<br>
+<details>
+    <summary> ACL Permissions for Creating Runners at <strong>Project</strong> level</summary>
+
 To create a Runner within a Project, users will need the following ACL permissions:
-```
+
+```acl
 by:
   group: my-user-group-name
 description: Allow "write" for runner feature within specific project
@@ -126,6 +139,9 @@ context:
 
 * Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
 
+</details>
+
+
 :::warning Error Without API Permissions
 If the user does not have the necessary API permissions, the following error will be displayed when attempting to create a Runner:
 
@@ -155,7 +171,7 @@ To create a Runner through at the System level:
    * **`Windows`**
    * **`Docker`**
    * **`Kubernetes`**
-   :::warning Platform Selection Implications
+   :::warning Platform Selection
    Once a platform is selected, it cannot be changed for a given Runner. If the platform needs to be changed in the future, a new Runner will need to be created.
    :::
 7. Click **Next**.
@@ -176,8 +192,8 @@ To create a Runner through at the System level:
     * **Kubernetes**: The code snippet for installing the Runner as a Kubernetes deployment is provided:
        ![Install Kubernetes Runner](/assets/img/install-kubernetes-runner.png)<br>
 
-Copy and paste the code snippet into the terminal of the host where the Runner will be installed.
-   
+Copy and paste the code snippet into the terminal of the host where the Runner will be installed. 
+
 11. Click **Close and Complete**.
 
 On the subsequent screen, the new Runner will be listed along with any other Runners that have been created:
@@ -231,6 +247,6 @@ To create a Runner within a Project:
       ![Install Docker Runner](/assets/img/install-docker-runner.png)<br>
     * **Kubernetes**: The code snippet for installing the Runner as a Kubernetes deployment is provided:
       ![Install Kubernetes Runner](/assets/img/install-kubernetes-runner.png)<br>
-12. Click **Close and Complete** to finish the Runner creation process. 
+12. Click **Close and Complete** to finish the Runner creation process.
 
-On the subsequent screen, the new Runner will be listed along with any other Runners that have been created:
+On the subsequent screen, the new Runner will be listed along with any other Runners that have been created.
diff --git a/docs/administration/runner/runner-installation/runner-install.md b/docs/administration/runner/runner-installation/runner-install.md
@@ -162,7 +162,6 @@ docker run -it \
 	 rundeckpro/runner:{{ $rundeckVersion }}
 ```
 
-
 ## Secure the Runner Deployment
 
 We recommend installing Runners in private directories that are only accessible by the user/group holding the runner process (e.g.: `C:\Users\runnerUser\` directory) so that other users are not able to access or even modify script files created by the runner. 

diff --git a/docs/administration/runner/runner-management/managing-runners.md b/docs/administration/runner/runner-management/managing-runners.md
@@ -2,15 +2,51 @@
 redirectFrom: /administration/runner/management
 ---
 
-# Managing Runners
-
-## Overview
+# System & Project Runner Management
 
 Runners can be managed at the System level as well as at the Project level of Runbook Automation (cloud and self-hosted).
 Both the System and Project level management interfaces allow users to create, edit, and delete Runners.  
-However, there are specific actions that can only take place depending on whether operating in the System or Project level.
+However, there are specific actions that can only take place in the System Level - such as assigning a Runner to multiple projects - or at the Project level - such as defining the Node Filter for dispatching to nodes.
+
+## System Level Runner Management
+<br>
+<details>
+    <summary><u>ACL Permissions for Managing Runners at <strong>System</strong> level</u></summary>
+
+To manage a Runner at the **System level**, users will need the following ACL permissions:
 
-### Managing Runners at the System level
+```acl
+---
+by:
+  group: my-user-group-name
+description: Update Runners at System Level
+for:
+  runner:
+  - allow:
+    - update
+    - delete
+    - read
+context:
+  application: rundeck
+
+---
+by:
+  group: my-user-group-name
+description: Write Access to Runner Feature at System Level
+for:
+  resource:
+  - allow:
+    - read
+    - admin
+    equals:
+      kind: runner
+context:
+  application: rundeck
+```
+
+* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
+
+</details> 
 
 At the System level, in addition to creating, editing, and deleting Runners, users can also assign Runners to Projects.
 
@@ -30,7 +66,7 @@ From this interface, users can:
 
 [//]: # (- Delete Runners.  For detailed steps, see [Deleting a Runner]&#40;/administration/runner/runner-installation/delete-a-runner&#41;.)
 
-#### Assigning Runners to Projects
+### Assigning Runners to Projects
 
 To assign a Runner to a project, follow these steps:
 
@@ -43,21 +79,45 @@ To assign a Runner to a project, follow these steps:
 
 The Runner can now be used within the designated projects for various tasks such as job execution, node discovery, and secrets-management integration.
 
-In order to assign a Runner to a Project, the user must have the following ACL permission:
+## Managing Runners within a Project
+<br>
+<details>
+    <summary><u>ACL Permissions for Creating Runners at <strong>Project</strong> level</u></summary>
 
-```
+To create a Runner within a Project, users will need the following ACL permissions:
+
+```acl
+---
 by:
   group: my-user-group-name
-description: Allow [update] for runner
+description: Manage Existing Runners within Project
 for:
   runner:
   - allow:
+    - read
     - update
+    - delete
 context:
-  application: rundeck
+  project: my-project-name
+
+---
+by:
+  group: my-user-group-name
+description: Write access to Runners at the Project Level
+for:
+  resource:
+  - allow:
+    - read
+    - admin
+    equals:
+      kind: runner
+context:
+  project: my-project-name
 ```
 
-### Managing Runners within a Project
+* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
+
+</details>
 
 At the Project level, users can create, edit, and delete Runners for that specific Project.
 However, Runners created at the Project level are only available for use within that Project and cannot be used in other Projects.
@@ -77,7 +137,7 @@ From this interface, users can:
 
 [//]: # (- Delete Runners.  For detailed steps, see [Deleting a Runner]&#40;/administration/runner/runner-installation/delete-a-runner&#41;.)
 
-#### Removing a Runner from a Project
+### Removing a Runner from a Project
 
 To remove a Runner from a Project, follow these steps:
 
@@ -142,7 +202,7 @@ by:
 ```
 :::
 
-### Changing Runners from Single to Multiple Projects
+## Changing Runners from Single to Multiple Projects
 
 When a Runner is assigned to a single Project, then users within a Project and with the appropriate permissions can make any changes to the Runner from the Project level interface. This includes the ability to:
 - Edit the Runner's Name
@@ -158,14 +218,7 @@ However, when a Runner is assigned to multiple Projects, then users within Proje
 
 This is because when a Runner spans multiple Projects it is considered a _shared resource_.
 
-
-### Viewing Runner details
-
-A new section Tags is available  at the bottom of the Runner information page. Like in the summary page, a list of associated tags are displayed.
-
-![View details](/assets/img/runner-config-viewdetails.png)<br>
-
-### Runner Tags
+## Runner Tags
 
 Runner Tags are used to select on or more Runners for specific operations - such as for Job execution when using [**Manual Runner Dispatch Configuration**](/administration/runner/runner-management/project-dispatch-configuration.md#manual-runner-selection) or when using [Runners for Node Source](/administration/runner/using-runners/runners-for-node-discovery.md) plugins.
 
@@ -205,4 +258,4 @@ Users can check that a Runner is available via an ad hoc "ping" operation:
 3. If the Runner is available, the response show that the message was received:
     ![Ping Runner Response](/assets/img/runner-ping-response.png)<br>
 4. If the Runner is unavailable, the response will show that the ping response timed out:
-    ![Ping Runner Unavailable](/assets/img/runner-ping-unavailable.png)<br>
+    ![Ping Runner Unavailable](/assets/img/runner-ping-unavailable.png)<br>
-Original file line number
+Diff line change
@@ Expand Up / @@ -162,7 +162,6 @@ docker run -it \ @@
     	 rundeckpro/runner:{{ $rundeckVersion }}
     ```
     ## Secure the Runner Deployment
     We recommend installing Runners in private directories that are only accessible by the user/group holding the runner process (e.g.: `C:\Users\runnerUser\` directory) so that other users are not able to access or even modify script files created by the runner.
@@ Expand Down @@