diff --git a/docs/.vuepress/pr-feed-config.json b/docs/.vuepress/pr-feed-config.json
index 65557aff5..4634db131 100644
--- a/docs/.vuepress/pr-feed-config.json
+++ b/docs/.vuepress/pr-feed-config.json
@@ -3,7 +3,7 @@
"version": "5.18.0",
"lastSelfHostedDate": "2025-12-16",
"lastSaasRelease": "2025-11-24",
- "lastSaasCut": "rba/5.18-RBA-20251204-16bd2b6-f14b8e9",
+ "lastSaasCut": "rba/5.19-RBA-20260107-18ac2eb-9f53a6c",
"description": "Last self-hosted release version and date"
}
}
diff --git a/docs/.vuepress/public/feeds/development-atom.xml b/docs/.vuepress/public/feeds/development-atom.xml
index 708c66117..fc120325d 100644
--- a/docs/.vuepress/public/feeds/development-atom.xml
+++ b/docs/.vuepress/public/feeds/development-atom.xml
@@ -3,8 +3,42 @@
Rundeck Development Updates
- 2025-12-18T21:47:27.699Z
+ 2026-01-07T19:35:27.592Zhttps://docs.rundeck.com/feeds/developmentRecent merged pull requests and development updates from Rundeck
-
+
+ Update Remco to newer commit that remediates some CVEs
+
+ rundeck-pr-rundeck-9936
+ 2026-01-07T17:28:56.000Z
+ Update Remco to newer commit that remediates some CVEs (Merged: Jan 7, 2026)
+
+
+ Hashi corp vault integration modification time issue
+
+ rundeck-pr-rundeckpro-4541
+ 2025-12-22T16:13:14.000Z
+ Hashi corp vault integration modification time issue (Merged: Dec 22, 2025)
+
+
+ Issues with ansible inline workflow executions where it shows an unwanted output
+
+ rundeck-pr-rundeckpro-4534
+ 2025-12-17T14:36:04.000Z
+ Issues with ansible inline workflow executions where it shows an unwanted output (Merged: Dec 17, 2025)
+
+
+ Issues with ansible inline workflow executions where it shows an unwanted output
+
+ rundeck-pr-rundeck-9940
+ 2025-12-17T14:35:57.000Z
+ Issues with ansible inline workflow executions where it shows an unwanted output (Merged: Dec 17, 2025)
+
+
+ Promote workflow tab out of alphaUi
+
+ rundeck-pr-rundeck-9928
+ 2025-12-15T16:41:42.000Z
+ Promote workflow tab out of alphaUi (Merged: Dec 15, 2025)
+
\ No newline at end of file
diff --git a/docs/.vuepress/public/feeds/development.xml b/docs/.vuepress/public/feeds/development.xml
index ffa3f4668..337a48810 100644
--- a/docs/.vuepress/public/feeds/development.xml
+++ b/docs/.vuepress/public/feeds/development.xml
@@ -5,8 +5,42 @@
https://docs.rundeck.com/docs
Recent merged pull requests and development updates from Rundecken-us
- Thu, 18 Dec 2025 21:47:27 GMT
+ Wed, 07 Jan 2026 19:35:27 GMT
-
+
+ Update Remco to newer commit that remediates some CVEs
+ https://docs.rundeck.com/docs/history/updates/
+ Update Remco to newer commit that remediates some CVEs (Merged: Jan 7, 2026)
+ Wed, 07 Jan 2026 17:28:56 GMT
+ rundeck-pr-rundeck-9936
+
+
+ Hashi corp vault integration modification time issue
+ https://docs.rundeck.com/docs/history/updates/
+ Hashi corp vault integration modification time issue (Merged: Dec 22, 2025)
+ Mon, 22 Dec 2025 16:13:14 GMT
+ rundeck-pr-rundeckpro-4541
+
+
+ Issues with ansible inline workflow executions where it shows an unwanted output
+ https://docs.rundeck.com/docs/history/updates/
+ Issues with ansible inline workflow executions where it shows an unwanted output (Merged: Dec 17, 2025)
+ Wed, 17 Dec 2025 14:36:04 GMT
+ rundeck-pr-rundeckpro-4534
+
+
+ Issues with ansible inline workflow executions where it shows an unwanted output
+ https://docs.rundeck.com/docs/history/updates/
+ Issues with ansible inline workflow executions where it shows an unwanted output (Merged: Dec 17, 2025)
+ Wed, 17 Dec 2025 14:35:57 GMT
+ rundeck-pr-rundeck-9940
+
+
+ Promote workflow tab out of alphaUi
+ https://docs.rundeck.com/docs/history/updates/
+ Promote workflow tab out of alphaUi (Merged: Dec 15, 2025)
+ Mon, 15 Dec 2025 16:41:42 GMT
+ rundeck-pr-rundeck-9928
+
\ No newline at end of file
diff --git a/docs/administration/runner/runner-management/managing-runners.md b/docs/administration/runner/runner-management/managing-runners.md
index 7084f2bc9..abbad62b1 100644
--- a/docs/administration/runner/runner-management/managing-runners.md
+++ b/docs/administration/runner/runner-management/managing-runners.md
@@ -9,7 +9,7 @@ Both the System and Project level management interfaces allow users to create, e
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
-
+
ACL Permissions for Managing Runners at System level
@@ -44,19 +44,19 @@ 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.
+- Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
-
+
At the System level, in addition to creating, editing, and deleting Runners, users can also assign Runners to Projects.
To access the System level Runner management interface, navigate to the **System menu** and select **Runner Management**:
-
+
The Runner Management interface will display a list of all Runners in the system:
-
+
From this interface, users can:
@@ -65,23 +65,21 @@ From this interface, users can:
- [Assigning Runners to Projects](#assign-runners-to-projects).
- [Manage a Runner's Replicas](managing-replicas.md).
-[//]: # (- Delete Runners. For detailed steps, see [Deleting a Runner](/administration/runner/runner-installation/delete-a-runner).)
-
### Assigning Runners to Projects
To assign a Runner to a project, follow these steps:
1. From the System level Runner management interface, click on the name of the Runner.
2. In the **Project Assignments** section, click on the **Add Projects** button.
- 
+ 
3. From the popup, select the Projects that should be able to use this Runner
- 
+ 
4. Click **Add**
The Runner can now be used within the designated projects for various tasks such as job execution, node discovery, and secrets-management integration.
## Managing Runners within a Project
-
+
ACL Permissions for Creating Runners at Project level
@@ -116,7 +114,7 @@ context:
project: my-project-name
```
-* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
+- Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions.
@@ -127,17 +125,15 @@ To access the Project level Runner management interface, navigate to a specific
The Runner Management interface will display a list of all Runners in the Project:
-
+
From this interface, users can:
-- [Creating a new Runner](/administration/runner/runner-installation/creating-runners.md).
+- Create a new Runner. For detailed steps, see [Creating a Runner](/administration/runner/runner-installation/creating-runners.md).
- [Modify a Runner's Node Dispatch Settings](/administration/runner/runner-management/node-dispatch.md).
- [Edit a Runner's Tags](#runner-tags).
- [Remove a Runner from a Project](#removing-a-runner-from-a-project).
-[//]: # (- Delete Runners. For detailed steps, see [Deleting a Runner](/administration/runner/runner-installation/delete-a-runner).)
-
### Removing a Runner from a Project
To remove a Runner from a Project, follow these steps:
@@ -163,11 +159,14 @@ context:
If using the self-hosted product and upgrading a version earlier than 5.3.0, the AppAdmin ACL policy stored on the local filesystem may need to be updated.
The following permissions must be **added** to it in order to manage Runners at the Project level:
+
```
runner:
- allow: '*' # allow read/write/delete for all Runners
```
+
Therefore, the AppAdmin ACL Policy should look like this:
+
```
description: Admin, all access.
context:
@@ -177,7 +176,7 @@ for:
- allow: '*' # allow read/create all kinds
adhoc:
- allow: '*' # allow read/running/killing adhoc jobs
- job:
+ job:
- allow: '*' # allow read/write/delete/run/kill of all jobs
node:
- allow: '*' # allow read/run for all nodes
@@ -201,11 +200,13 @@ for:
by:
group: admin
```
+
:::
## 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
- Edit the Runner's Tags
- Delete the Runner
@@ -221,14 +222,138 @@ This is because when a Runner spans multiple Projects it is considered a _shared
## 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.
+Runner Tags are used to select one 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.
Tag selection within the **Runner Selector** uses _and_ logic to define the inclusive set of Runners. For example, if a Job is configured to run on Runners with the tags `LINUX` and `DEV`, then only Runners that have _both_ tags will be listed as usable for the Job.
-
+
+
+## Editing Runner Details
+
+Rundeck provides an improved single-screen inline editing experience for managing Runner information. Instead of navigating to a separate edit page, you can now edit Runner details directly on the Runner's detail page within the **Basic Information** tab.
+
+### Accessing Edit Mode
+
+To edit a Runner:
+
+1. Navigate to the Runner Management page (system or project level)
+2. Click the **Actions** dropdown next to the Runner you want to edit
+3. Select **Edit Runner**
+
+The Runner's detail page opens with the **Basic Information** tab in edit mode, allowing you to modify Runner properties without leaving the page.
+
+### Editable Fields
+
+In edit mode, you can modify the following Runner properties:
+
+- **Name**: The Runner's display name (required)
+- **Description**: Additional information about the Runner's purpose
+- **Tags**: Labels for organizing Runners and controlling job execution targeting
+
+### Validation
+
+The edit form includes built-in validation:
+
+- **Runner Name is Required**: You cannot save a Runner without a name
+- Empty or whitespace-only names will display a clear error message
+- Invalid inputs are caught before submission to prevent errors
+
+### Saving Changes
+
+To save your edits:
+
+1. Make your desired changes to the Runner details
+2. Click **Save** to commit the changes
+
+Upon successful save:
+
+- You'll see a success notification: "Runner updated successfully"
+- The detail page returns to view mode with your updated Runner data
+- Changes are immediately reflected across the system
+
+### Canceling Edits
+
+To discard your changes:
+
+1. Click **Cancel** in the edit form
+2. All changes are discarded
+3. The detail page returns to view mode with the original Runner data
+
+### Focused Editing Experience
+
+When in edit mode:
+
+- Non-essential tabs (Node Dispatch, Replicas) are hidden to maintain focus on editing
+- Only the **Basic Information** tab is visible with the edit form
+- The **Regenerate Credentials** button is hidden during editing (only available in view mode)
+- All tabs reappear when you cancel or save
+
+**Note**: The **Node Dispatch** tab settings are managed and saved independently from the basic Runner information.
+
+To edit these settings:
+
+1. View the Runner detail page in **View Mode** (not Edit Mode)
+2. Open the **Node Dispatch** tab
+3. Adjust the settings as needed
+4. Use the **Node Dispatch** tab's save action to persist those changes without affecting the other Runner fields
+
+## Regenerating Runner Credentials
+
+Credentials may need to be regenerated if they are compromised or lost. The **Regenerate Credentials** functionality is only available when viewing a Runner's detail page in view mode (not during edit mode).
+
+### When Regenerate is Available
+
+The **Regenerate Credentials** button visibility depends on Runner type and replica configuration:
+
+#### View Mode Requirement
+
+- The **Regenerate Credentials** button is only visible in view mode (not shown during edit mode to maintain focus on basic information editing)
+
+#### When Replicas Feature is Enabled
+
+- **Ephemeral Runners**: Can regenerate credentials (designed for dynamic environments)
+- **Manual Runners**: Cannot regenerate credentials (use "Add Replica" workflow instead)
+
+#### When Replicas Feature is Disabled (Legacy Mode)
+
+- All Runner types can regenerate credentials for backward compatibility
+
+### Security Note
+
+:::warning Important
+Regenerating credentials will immediately invalidate the current credentials. Any active Runner using the old credentials will no longer be able to connect to Rundeck until you update the Runner with the new credentials and restart it.
+:::
+
+### How to Regenerate Credentials
+
+1. Navigate to the Runner's detail page (click on a Runner name from the table)
+2. Ensure you are in **View Mode** (not Edit Mode) - the **Regenerate Credentials** button is only visible in view mode
+3. Scroll to the **Regenerate Credentials** section
+4. Review the warning message about credential invalidation
+5. Click **Regenerate Credentials**
+6. Installation instructions will appear with:
+ - New Runner Token
+ - New Download Token
+ - Updated installation commands for your platform
+
+**Note**: The "Download Runner" option has been removed from the actions dropdown. Installation instructions are now displayed directly after clicking **Regenerate Credentials**.
+
+### Installing Regenerated Credentials
+
+After regenerating credentials:
+
+1. Stop the running Runner service on your Runner machine
+2. Update the Runner configuration file with the new token:
+
+```bash
+RUNDECK_RUNNER_TOKEN=your-new-token-value
+```
-[//]: # (## Listing Runners)
+3. Restart the Runner service
+4. Verify the Runner reconnects and shows "Healthy" status
-[//]: # ()
-[//]: # ( )
+For manual Runners with replicas enabled, use the **Add Replica** workflow to create new Runner instances rather than regenerating credentials.
+[//]: # "## Listing Runners"
+[//]: #
+[//]: # " "
diff --git a/docs/history/updates/index.md b/docs/history/updates/index.md
index e60a00887..070e7428d 100644
--- a/docs/history/updates/index.md
+++ b/docs/history/updates/index.md
@@ -1,7 +1,7 @@
---
title: Recent Updates
description: Latest merged changes from the Rundeck development team
-date: 2025-12-18T21:47:27.673Z
+date: 2026-01-07T19:35:27.567Z
feed: true
index: true
---
@@ -19,7 +19,33 @@ This page shows recently merged pull requests from both the Runbook Automation p
## Recent Changes
-*No new updates to report since the last release.*
+#### ::circle-dot:: Update Remco to newer commit that remediates some CVEs [PR #9936](https://github.com/rundeck/rundeck/pull/9936)
+
+
+ Enhanced Docker image security by updating Remco (the configuration management tool) to a newer version that remediates three security vulnerabilities (CVE-2025-4673, CVE-2025-22872, and CVE-2025-47906), strengthening the security posture of Rundeck container deployments.
+
+#### ::circle-dot:: Hashi corp vault integration modification time issue
+
+
+ -Fixed an issue where Vault keys displayed incorrect modification and creation timestamps in Rundeck due to missing metadata.
+
+#### ::circle-dot:: Issues with ansible inline workflow executions where it shows an unwanted output
+
+
+ Resolved an issue where Ansible inline workflow executions displayed unwanted output by properly sanitizing group names to comply with Ansible requirements, filtering out reserved host attributes that could conflict with Ansible's internal variables, and ensuring only valid host entries are processed during execution.
+
+#### ::circle-dot:: Issues with ansible inline workflow executions where it shows an unwanted output [PR #9940](https://github.com/rundeck/rundeck/pull/9940)
+
+
+ Resolved an issue where Ansible inline workflow executions displayed unwanted output by properly sanitizing group names to comply with Ansible requirements, filtering out reserved host attributes that could conflict with Ansible's internal variables, and ensuring only valid host entries are processed during execution.
+
+#### ::circle-dot:: Promote workflow tab out of alphaUi [PR #9928](https://github.com/rundeck/rundeck/pull/9928)
+
+
+ <!-- If you have suggested content that would describe this PR to other Rundeck community users, please enter it here.-->
+ Promote workflow tab out from alpha state. The updated ui will be accessible for all users with the nextUi flag enabled.
+
+
## Subscribe to Updates
@@ -40,6 +66,6 @@ The development updates are automatically generated from both our private reposi
---
-**List Last updated:** 2025-12-18
+**List Last updated:** 2026-01-07
diff --git a/docs/learning/howto/cross-account-aws-ssm.md b/docs/learning/howto/cross-account-aws-ssm.md
index 3025ada70..6c34090a8 100644
--- a/docs/learning/howto/cross-account-aws-ssm.md
+++ b/docs/learning/howto/cross-account-aws-ssm.md
@@ -298,6 +298,15 @@ The SSM Node Executor can be set as the **Default Node Executor** - thereby maki
* If you have more than one remote account, you can leave this blank.
6. See below for using **CloudWatch Logs** for larger log-output.
7. Optionally modify the **Log Filter Delay** property to be the number of seconds to wait before retrieving logs.
+
+:::tip Extended Execution Time
+SSM executions support extended timeout configurations:
+- With Assume Role: up to **12 hours (43200 seconds)**
+- Without Assume Role: up to **48 hours (172800 seconds)**
+- Inline Scripts: maximum **8 hours (28800 seconds)**
+
+See the [Execution Timeout Configuration](/manual/projects/node-execution/aws-ssm.md#execution-timeout-configuration) section for complete details and configuration methods.
+:::
The SSM File Copier can also be set as the **Default File Copier** for the whole project:
diff --git a/docs/manual/projects/node-execution/aws-ssm.md b/docs/manual/projects/node-execution/aws-ssm.md
index 99f69d50a..63f1ca867 100644
--- a/docs/manual/projects/node-execution/aws-ssm.md
+++ b/docs/manual/projects/node-execution/aws-ssm.md
@@ -199,17 +199,61 @@ Similarly, scripts that are executed using the **Inline Script** Job step will t
### Execution Timeout Configuration
AWS SSM has a default execution timeout of 1 hour (3600 seconds). You can configure a custom timeout value using the **`ssm-execution-timeout`** property to allow longer-running commands and scripts.
-To set the execution timeout for all SSM executions in a project:
+#### Maximum Timeout Limits
+
+The maximum execution timeout depends on your authentication method and execution type:
+
+- **With Assume Role**: Up to **12 hours (43200 seconds)**
+ - Applies when using cross-account access with IAM role assumption
+ - Limited by AWS IAM temporary credentials duration
+
+- **Without Assume Role**: Up to **48 hours (172800 seconds)**
+ - Applies when using direct IAM role attachment or access keys
+ - Suitable for very long-running operations
+
+- **Inline Scripts (Runbook Automation/RBA and Runbook Automation Self-Hosted/RBA-SH)**: Maximum **8 hours (28800 seconds)**
+ - This limit applies specifically to inline script steps in both Runbook Automation (RBA) and Runbook Automation Self-Hosted (RBA-SH)
+ - Applies regardless of assume role usage
+
+:::warning Important
+Ensure your IAM policies and AWS service limits support your configured timeout duration. For assume role configurations, verify the maximum session duration is set appropriately in the IAM role settings.
+:::
+
+:::tip Best Practice: Timeout Configuration
+Configure your `ssm-execution-timeout` to be **longer than your expected job duration**, with a safety margin of a few minutes. For example, if your job typically runs for 2 hours, set the timeout to 2 hours and 5-10 minutes (7500-7800 seconds) to ensure the job completes successfully without timing out. This buffer accounts for variable execution times and system delays.
+:::
+
+#### Configuration Methods
+
+**1. Project-wide Configuration (Default Node Executor)**
1. Navigate to **Project Settings** -> **Edit Configuration** -> **Default Node Executor**.
-2. In the **AWS / SSM / Node Executor** configuration, add the **Execution Timeout** value in seconds.
+2. Select **AWS / SSM / Node Executor**
+3. Set the **Execution Timeout** value in seconds (e.g., 7200 for 2 hours)
-To set the execution timeout on project config file:
-**`project.ssm-execution-timeout=3600`**
+**2. Node Source Level (EC2 Node Source)**
-To set the execution timeout at node level, add the following node-attribute to the nodes by using the [Attribute Match](/manual/node-enhancers.md#attribute-match)
-**`ssm-execution-timeout=3600`**
+Using the **Mapping Params** field:
+```
+ssm-execution-timeout.default=7200
+```
+(Example: 2 hours = 7200 seconds)
+
+**3. Project Configuration File**
+
+Add to your project configuration file:
+```
+project.ssm-execution-timeout=7200
+```
+
+**4. Node Level (Individual Nodes)**
+
+Using the [Attribute Match](/manual/node-enhancers.md#attribute-match) node enhancer, add as a node-attribute:
+```
+ssm-execution-timeout=7200
+```
-**Default Value**: If not specified, the execution timeout defaults to **3600 seconds (1 hour)**.
+#### Default Value
+If not specified, the execution timeout defaults to **3600 seconds (1 hour)**.
## Using CloudWatch Logs (Optional)
The example policies in the prior sections enable Runbook Automation to retrieve logs directly from SSM.