Private corporate batches, live online cohorts and 1-on-1 mentoring in runbook automation and self-service operations — jobs, nodes, workflows and delegated access with a full audit trail — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Rundeck as an operations delegation platform rather than a job scheduler: how the resource model and node filters decide what a job can touch, how workflow strategies, error handlers and job references compose into runbooks that fail safely, and how typed and secure options make a job usable by someone who is not its author. Sessions cover projects and configuration, the plugin surface across step, node executor, notification, log filter and orchestrator types, ACL policy files mapped to LDAP or SSO groups, and the API and rd CLI for driving Rundeck from CI. The delivery deliberately includes the failure paths as well as the working ones — jobs that time out, node sets that partially fail, options that were not validated — because that is where a runbook either holds or does not.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Rundeck that means a trainer who has run it in production — runbook automation and self-service operations — jobs, nodes, workflows and delegated access with a full audit trail — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Rundeck batchRundeck is a runbook automation platform. It takes the operational work that currently lives in shell scripts, wiki pages and individual engineers' heads, and turns it into jobs: named, parameterised, access-controlled, schedulable units of work with a complete execution record. A job is a workflow of steps run against a set of nodes; the nodes come from a resource model — a static YAML or XML file, the output of a script, or a plugin querying AWS, an Ansible inventory or a CMDB — and execution happens over SSH, WinRM or a node executor plugin.
The point of Rundeck is delegation rather than automation for its own sake. Automation you can only run yourself has moved the problem; automation a first-line engineer, a developer or a support analyst can run safely has removed it. Rundeck's job definition, access control policy and audit log exist so that someone without production SSH access can restart a service, rotate a credential, run a database export or promote a build — with typed and validated inputs, an approval path if required, and a permanent record of who ran what, against which hosts, with what output.
The primitives are few and worth learning precisely. Projects group jobs, nodes and configuration. Node filters select targets by attribute rather than by hostname list. Workflows sequence steps with node-first or step-first ordering, error handlers per step, and strategies for sequential, parallel or rule-based execution. Options are typed inputs, including secure options and values fetched from a remote URL. Plugins extend every seam — workflow steps, node executors, notifications, log filters, orchestrators and resource models. ACL policies written in YAML control permission by project, job, node and action, authenticating against LDAP, Active Directory, PAM or single sign-on, and the REST API and rd command-line tool make all of it scriptable from CI.
Operational toil is measurable and expensive, and most organisations still pay it in the same way: an engineer with production access runs a script, and the knowledge of how to run it correctly stays with that engineer. That model fails twice — it makes on-call depend on individuals, and it makes every privileged action an unaudited event. Rundeck exists precisely at that seam, and it is why runbook automation shows up in SRE, platform and operations job specifications as a named capability rather than a nice-to-have.
The compliance pressure is just as real. Auditors increasingly ask not whether a change was approved but who executed it, on which hosts, with which parameters, and what the output was. A Rundeck execution record answers that natively, and doing the same with ad-hoc SSH means reconstructing it from bastion logs and hope. Teams under SOC 2, ISO 27001, PCI DSS or internal separation-of-duties requirements adopt Rundeck for the audit trail as often as for the automation.
And it fills a gap the rest of the toolchain leaves open. Ansible and Terraform describe desired state; CI/CD tools ship code; incident tools page people. None of them give a support analyst a safe, parameterised button for a production task. Rundeck wraps the automation you already have — Ansible playbooks, scripts, API calls — in access control, inputs, scheduling and audit, which is why it usually complements those tools rather than competing with them.
The problem before the product. Why operational knowledge concentrates in individuals, what that costs on-call and audit, and how runbook automation differs from configuration management, CI/CD and orchestration. Then Rundeck's core concepts and an honest account of where it is the wrong tool.
Topics: Operational toil, tribal knowledge and the on-call dependency problem · Runbook automation compared with configuration management and CI/CD · Core concepts: project, job, node, execution, workflow, option · Rundeck Community versus Enterprise and PagerDuty Process Automation · Where Rundeck complements Ansible, Terraform and Jenkins · Where Rundeck is the wrong answer · Tour of the web interface and the anatomy of an execution
How the server is put together and how to stand one up you would be willing to depend on. Process architecture and the execution path from request to node, the datastore options, container and package installation, JVM and resource sizing, and TLS from the start rather than later.
Topics: Rundeck system architecture and the execution path · Deployment options: WAR, DEB and RPM packages, Docker, Kubernetes · Datastore choices: the embedded database versus MySQL, PostgreSQL and MSSQL · rundeck-config, framework.properties and realm configuration · JVM sizing, thread pools and concurrent execution limits · TLS termination, reverse proxy and base URL configuration · Log storage, execution retention and file upload storage · Sizing for node count, job count and execution volume
Everything that is set once and lived with. Server configuration and its precedence, then project creation and the project-level settings that determine node sources, SSH behaviour, key storage, execution defaults and log filtering. Project SCM integration so jobs live in Git rather than only in the database.
Topics: Server configuration files and setting precedence · Creating projects and project-level configuration · Key Storage: passwords, private keys and access from jobs · Default node executor and file copier settings · Execution mode, activity retention and cleanup · Project SCM import and export with Git · Project configuration as code, and promoting between environments · Readme, motd and project-level documentation · Backing up and restoring project and job definitions
The half of Rundeck that decides what a job can touch. Resource models from static files, scripts and plugins; node attributes and tags as the vocabulary of targeting; then node filter syntax, and why filtering by attribute rather than by hostname is what makes a job survive an infrastructure change.
Topics: The resource model: resources.xml and resources.yaml · Node attributes, tags and naming conventions worth adopting · Script-based and URL-based resource model sources · Resource model plugins: AWS EC2, Ansible inventory, Kubernetes, CMDB · Node filter syntax: attributes, tags, negation, regular expressions · Filter exclusion and combining include with exclude · Node executors: SSH, WinRM, local and plugin-based · File copiers and how job steps transfer files · Node health, ping and troubleshooting an unreachable node · Threadcount, keepgoing and node ordering
Before jobs, the direct path. Running a command or script across a filtered node set from the interface and from the command line, watching output stream back, and understanding how ad-hoc execution differs from a job in access control and audit. Then the rd tool as the scriptable front door.
Topics: Ad-hoc commands against a node filter · Running a local script across remote nodes · Reading streaming output and per-node results · Ad-hoc execution permissions and why they are restricted · Installing and configuring the rd command-line tool · Authentication for rd: tokens and credentials · rd adhoc, rd run, rd jobs and rd projects · Scripting Rundeck operations with rd in a shell pipeline · Converting an ad-hoc command into a saved job
Turning a command into something a colleague can run. Job definition structure, node targeting within a job, and then options in depth — typed inputs, validation, allowed values, remote option values, secure options and secure authentication options, and the context variables that carry them into steps.
Topics: Job anatomy: name, group, description, node set, workflow · Job UUIDs, groups and organising a growing job library · Defining options: text, date, file upload, multi-valued · Validation with regular expressions and allowed-value lists · Remote option values fetched from a URL or another job · Cascading and dependent options · Secure options and secure authentication options · Context variables: option, job, node and execution contexts · Option defaults, required flags and safe failure when input is wrong · File upload options and their storage · Job description and documentation that survives handover
Composing steps into runbooks that behave under failure. Node-first versus step-first execution and why the difference matters, workflow strategies including the ruleset strategy, error handlers per step, job references for reuse, and the timeout, retry and keepgoing settings that decide what a partial failure leaves behind.
Topics: Command, script, script-file and inline-script steps · Node steps versus workflow steps · Node-first and step-first execution order · Workflow strategies: sequential, parallel and ruleset · Error handlers and continuing after failure · keepgoing, thread count and failure thresholds · Job references and building composite runbooks · Job timeouts, retries and retry delay · Passing data between steps with data capture and log filters · Conditional execution and step-level node filters · Idempotency and making a runbook safe to re-run
The extension points, and how far they go. Workflow step and node step plugins, notification plugins for chat and incident tools, log filter plugins that turn output into structured data, node orchestrators that control how a node set is worked through, then writing a plugin when nothing existing fits.
Topics: The plugin types and where each attaches · Installing, listing and troubleshooting plugins · Workflow and node step plugins, including Ansible and script plugins · Notification plugins: email, Slack, webhook, PagerDuty · Notification triggers: start, success, failure, retry, average duration exceeded · Log filter plugins: key-value, JSON, highlight, progress and masking · Node orchestrator plugins: rank, maxpercentage, subset and orchestration order · Secret and key storage plugins for external vaults · Writing a script plugin: structure, metadata and packaging · Java plugin development and the plugin API · Testing and distributing an internal plugin
What happens after someone presses run. Manual runs and run-again, scheduling with cron expressions and schedule ownership in a cluster, the execution model and its states, the activity view as the operational record, and a structured way to diagnose the executions that go wrong.
Topics: Running a job, running again, and running with different options · Scheduling: cron syntax, time zones and schedule enablement · Execution states and the execution lifecycle · Killing a running execution and what actually stops · Execution history, filtering and the activity page · Reading per-node log output and downloading full logs · Execution retention, cleanup and log file storage · Missed schedules, overlapping executions and concurrency control · Diagnosing timeouts, unreachable nodes and partial failures · Common execution failure signatures and their causes
The module that makes delegation possible. Authentication against LDAP, Active Directory, PAM or single sign-on; then ACL policy files — the resource types, actions and contexts — written so an operator can run a specific job against a specific node set and nothing else. Plus the security practices that keep a Rundeck server from becoming the softest target in the estate.
Topics: Authentication: realm.properties, LDAP, Active Directory, PAM, SSO · User groups and how they map to authorisation · ACL policy structure: description, context, for, by · Project context versus application context policies · Resource types: job, node, adhoc, project, storage, api_token · Actions: read, run, runAs, kill, create, update, delete · Writing least-privilege policies and testing them with the ACL tools · System-level ACLs and separation of duties · API tokens, token roles and rotation · Key storage access control and protecting credentials from job authors · Audit logging and producing evidence for a compliance review · Hardening the server: TLS, network exposure, session settings
Rundeck as a component rather than a destination. The REST API surface, authentication and versioning, driving jobs from CI and from other tools, importing and exporting job definitions as code, and webhooks that let an incident or monitoring system trigger a runbook.
Topics: REST API structure, versioning and authentication · Running jobs via API and polling execution status · Retrieving execution output and log data · Job import and export: YAML, XML and idempotent updates · Managing projects, nodes and ACLs through the API · Webhooks and inbound triggers from monitoring or incident tools · Integrating Rundeck into a Jenkins or GitLab CI pipeline · Triggering runbooks from an alerting system · Client libraries and writing an API wrapper · Rate limits, error handling and retry behaviour
Running Rundeck as supported infrastructure over years. Backup and restore of database, key storage and project definitions, upgrade procedure and rollback, database and log maintenance, monitoring the server itself — then a walkthrough of what the Enterprise edition adds, so the build-versus-buy decision is made on evidence.
Topics: Backup scope: database, key storage, project configuration, log storage · Restore and disaster recovery testing · Upgrade procedure, version compatibility and rollback · Database maintenance, execution cleanup and log retention · Monitoring Rundeck: health endpoints, metrics and log analysis · Capacity signals: thread pool saturation and execution queueing · High availability and clustered scheduling considerations · Enterprise features: cluster management, runners, enterprise plugins, tiered access · PagerDuty Process Automation and incident-time runbooks · Licensing and the build-versus-buy decision · A migration path from scripts and cron to managed runbooks
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a dynamic node source from a cloud account, tag hosts by role and environment, then rewrite a hardcoded job to use filters and prove it survives a rebuild.
Build a job with typed, validated and remotely populated options, secure credential handling and documentation, then hand it to a colleague and watch them run it unaided.
Compose a multi-step workflow with per-step error handlers, retries and timeouts, then break a subset of nodes and account for exactly what the partial failure left behind.
Wire authentication to a directory, write a least-privilege ACL policy, then prove an operator can run one job against one environment and is refused everything else.
Drive a job from a pipeline through the REST API, poll for completion, fail the build on job failure, and export every job definition back into Git.
Deliver a project with version-controlled jobs, dynamic nodes, least-privilege access, notifications, scheduling and a full audit trail that answers who ran what, where and with what result.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.