Rundeck Setup for Centralized Task Management

# docker-compose.yml
services:
  rundeck:
    image: rundeck/rundeck:5.3.0
    environment:
      RUNDECK_GRAILS_URL: https://rundeck.mycompany.com
      RUNDECK_SERVER_FORWARDED: "true"
      RUNDECK_DATABASE_DRIVER: org.postgresql.Driver
      RUNDECK_DATABASE_URL: jdbc:postgresql://postgres:5432/rundeck
      RUNDECK_DATABASE_USERNAME: rundeck
      RUNDECK_DATABASE_PASSWORD: ${DB_PASSWORD}
      RUNDECK_SECURITY_HTTPHEADERS_PROVIDER_CSP_ENABLED: "false"
    volumes:
      - rundeck_data:/home/rundeck/server/data
      - ./etc/framework.properties:/home/rundeck/etc/framework.properties:ro
    ports:
      - "4440:4440"
    depends_on:
      - postgres
  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: rundeck
      POSTGRES_USER: rundeck
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data

In framework.properties — Node sources (server inventory) and SSH keys:

framework.ssh.keypath=/home/rundeck/.ssh/rundeck-deploy
framework.ssh.user=deploy
framework.projects.dir=/home/rundeck/projects

Architecture Comparison: Standalone vs Cluster

Step-by-Step Deployment Guide

1. Infrastructure audit: server list, OS versions, SSH accessibility.
2. Architecture selection: standalone or cluster. For cluster, configure load balancing via HAProxy.
3. Deployment with PostgreSQL, configure persistence and backups.
4. Import SSH keys into Key Storage (not on disk).
5. Create 10-15 standard jobs: service restart, log cleanup, metric collection, artifact deployment.
6. Configure RBAC: user groups (admin, developer, operator), launch policies.
7. Integrate with alerting system: Slack, email, PagerDuty.
8. Documentation and team training: 2-hour workshop, operation instructions.

Job Definition as Code (IaC)

Jobs are exported in YAML — this is Infrastructure as Code for tasks. Example "Restart Application Service" job:

---
- id: restart-app-service
  name: Restart Application Service
  description: "Gracefully restart the application on target nodes"
  group: Operations/Services
  nodefilters:
    dispatch:
      threadcount: 5
      keepgoing: false
    excludePrecedence: true
    filter: 'tags: app-server +env:${option.environment}'
  options:
    - name: environment
      label: Environment
      values: [staging, production]
      required: true
      enforced: true
    - name: service_name
      label: Service Name
      default: myapp
      required: true
  sequence:
    keepgoing: false
    strategy: node-first
    commands:
      - script: |
          #!/bin/bash
          set -euo pipefail
          SERVICE="${option.service_name}"
          echo "Checking service status..."
          systemctl is-active "$SERVICE" || { echo "Service not running"; exit 1; }
          echo "Stopping $SERVICE..."
          systemctl stop "$SERVICE"
          sleep 2
          echo "Starting $SERVICE..."
          systemctl start "$SERVICE"
          echo "Waiting for health check..."
          sleep 5
          systemctl is-active "$SERVICE" && echo "OK" || { echo "FAILED to start"; exit 1; }
  notification:
    onfailure:
      plugin:
        type: slack-incoming-webhook
        configuration:
          webhook_url: ${globals.slack_ops_webhook}
          message: "Job FAILED: ${job.name} on ${node.name}"
    onsuccess:
      email:
        recipients: [email protected]
        subject: "Rundeck: ${job.name} completed"
---

tags: app-server +env:${option.environment} — node filtering by tags with option substitution from the launch form. One job works on both staging and production depending on the selection. We use GitOps: jobs are versioned in a repository, changes go through code review.

Configuring RBAC for Operators

Rundeck uses policy-based ACL. Example for the support team:

---
# /etc/rundeck/acls/support.aclpolicy
description: Support team - read and run pre-approved jobs only
context:
  project: '.*'
for:
  job:
    - allow: [read, run]
      match:
        group: 'Operations/.*'
  node:
    - allow: [read]
  project:
    - allow: [read]
by:
  group: support-team
---

This policy grants read and run on jobs in the Operations group but forbids creating new jobs and direct node access. We configure RBAC for each role: developers can deploy, operators only restart, admins can do everything.

Typical Rundeck Usage Scenarios

Why Key Storage is Better Than Storing Keys on Disk

SSH keys on disk are a vulnerability. Rundeck Key Storage stores keys encrypted in the database or integrates with HashiCorp Vault. The command rd keys upload --path keys/project/myproject/deploy-key --type privateKey --file ~/.ssh/deploy_rsa loads the key into secure storage. As part of the implementation, we configure Key Storage and scheduled key rotation. Rundeck Key Storage is 3 times more secure than storing keys on disk — data is encrypted with AES-256. This is critical for compliance with PCI DSS and SOC 2 security standards.

Timeline and Cost

A basic deployment with 10-15 jobs and RBAC takes 2-3 days. For complex infrastructure (cluster, Vault integration, CI/CD) the timeline extends to 5-7 days. The cost is calculated individually after an audit. We offer a preliminary assessment in 1 day — we will analyze your infrastructure and prepare an accurate plan. Contact us for a consultation. Experience: 5+ years working with Rundeck, over 20 automation projects, guaranteed SLA 99.9%.

Order a turnkey Rundeck implementation — get centralized task management without SSH access. We guarantee an 80% reduction in time for routine operations and full transparency of all actions.