Private corporate batches, live online cohorts and 1-on-1 mentoring in event-driven configuration management and remote execution over a persistent message bus — 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 SaltStack around the bus and the event stream rather than around YAML — targeting with grains, pillars and compound matchers, the job cache and returners, and the beacon-to-reactor path that makes infrastructure correct itself. Sessions cover the architecture decisions that determine whether a Salt estate scales: state ordering and requisites, pillar design for secrets and per-minion data, Jinja versus alternative renderers, syndic topologies for master fan-out, and Salt SSH for the hosts that will never take an agent — all demonstrated live against a running master and minions.
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 SaltStack that means a trainer who has run it in production — event-driven configuration management and remote execution over a persistent message bus — 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 SaltStack batchSaltStack — Salt — is a configuration management and remote execution framework built on a persistent, authenticated message bus. Minions maintain a long-lived connection to the master over ZeroMQ, so a command issued to ten thousand nodes fans out in seconds rather than being marshalled one SSH session at a time. That transport choice is what gives Salt its two defining properties: remote execution fast enough to be interactive, and an event stream you can react to.
The configuration management half is the state system. SLS files declare state in YAML rendered through Jinja by default, though the renderer is pluggable — you can write states in pure Python with the py renderer when the logic genuinely warrants it. Pillar holds targeted, per-minion data and secrets, kept separate from the states themselves; grains carry static facts about each minion and are the primary targeting mechanism, alongside globs, lists, compound matchers and node groups. The top file maps targets to states, and highstate applies the result.
What sets SaltStack apart in practice is the reactor. Every job return, minion start, presence change and custom event lands on the bus, and beacons let a minion emit events for things the bus would not otherwise see — a file changing, disk filling, a service dying. Reactors bind those events to states or execution modules, so infrastructure can correct itself without a human or a scheduler in the loop. Salt SSH covers hosts that cannot take an agent, and syndics let one master fan out to many.
Speed and scale are the reasons teams choose Salt, and both are structural rather than incidental. A persistent bus with pre-authenticated minions removes the per-host connection cost that dominates push-based tools at fleet scale, which is why Salt turns up in service providers, telcos, hosting platforms and anywhere the node count is measured in tens of thousands rather than hundreds.
The event-driven capability is the part with no clean equivalent elsewhere. Most automation stacks still run on a schedule and hope the interval is short enough; Salt's beacon and reactor pair lets a fleet respond to a condition at the moment it occurs. Teams building self-healing infrastructure — remediating an unauthorised file change, reclaiming disk before an alert fires, restarting a failed dependency — reach for it because the alternative is gluing together a monitoring system, a webhook receiver and a runner.
The hiring reality is that Salt expertise is thinner on the ground than Ansible or Puppet expertise, which cuts both ways: fewer candidates, but a real premium for engineers who can design pillar and grain targeting properly, keep a syndic topology healthy, and write reactors that do not loop.
The transport is the architecture, so we start there. Master and minion roles, the ZeroMQ publish and return channels, key exchange and acceptance, then targeting — the skill everything else depends on. Globs, lists, regular expressions, grains, pillars, subnets, node groups and compound matchers, practised until targeting is instinctive.
Topics: Salt architecture: master, minion and the message bus · Installing and configuring master and minions · Key management with salt-key and auto-accept trade-offs · Grains: static minion facts and custom grains · Targeting by glob, list, regex and grain · Pillar and subnet targeting · Node groups and compound matchers · Master and minion configuration files
Salt as an operational tool before it is a configuration tool. Running execution modules against the fleet, passing arguments and keyword arguments, output formats, asynchronous jobs and the job cache, runners on the master, and returners that push results into an external store for audit.
Topics: Execution modules and the module reference · Passing arguments, kwargs and complex data · Output formats and outputters · Asynchronous execution and job management · The job cache and salt-run jobs · Runners and the salt-run interface · Returners: writing results to external stores · Salt CLI ergonomics for incident work
The configuration management half. SLS file structure, state modules and their functions, IDs and names, the file_roots layout, include and extend, the top file, highstate versus targeted state runs, and test mode — the dry run that makes applying to production defensible.
Topics: SLS file structure and the state tree · file_roots, environments and the top file · Core state modules: pkg, file, service, user, cron · State IDs, names and declaration syntax · include and extend · highstate, state.apply and state.sls · test=True and reading the diff · state.show_sls and state.show_highstate for debugging
Salt's ordering model is explicit, and getting it wrong is the most common source of flaky states. The requisite system in full — require, watch, onchanges, onfail, prereq, use and their in-forms — plus failhard, retry, mod_watch behaviour and the design patterns that keep a growing state tree readable.
Topics: Declarative ordering and the state run order · require, require_in and dependency direction · watch, watch_in and mod_watch · onchanges, onfail and prereq · unless, onlyif and creates guards · failhard, retry and error behaviour · Structuring a state tree that scales · Common state anti-patterns
Separating data from logic. Pillar structure and targeting, external pillars, secrets with GPG-encrypted pillar data, then rendering — Jinja as the default renderer, its filters and Salt-specific functions, and the alternative renderers including pure Python for the cases where YAML plus Jinja stops being honest about the complexity.
Topics: Pillar structure, the pillar top file and targeting · Refreshing and inspecting pillar data · External pillars and dynamic pillar sources · Encrypted pillar data with GPG · Jinja templating in states and files · Salt-specific Jinja functions: salt[], grains, pillar · Alternative renderers and the py renderer · Choosing between Jinja logic and a custom module
The capability that most distinguishes Salt. The event bus and its tag structure, beacons that emit events for file changes, disk usage, service state and process presence, and reactors that bind those events to states, runners or execution modules — with the loop-prevention and rate-limiting discipline that keeps self-healing from becoming self-harming.
Topics: Event-driven infrastructure concepts · The Salt event bus, tags and event data · Beacons: configuration and the beacon module set · Deploying beacons and capturing events · Reactors: binding events to actions · Reactor SLS and the local, runner and wheel calls · Using reactors to correct unauthorised file changes · Using reactors to prevent disk-usage incidents · Avoiding reactor loops and thundering herds
Salt beyond a single master. Syndic topologies for fanning one master out across many, multi-master and failover configuration, master tuning and worker threads, then Salt SSH for hosts that cannot run a minion — its real advantages, its real costs, and the honest use cases. Finally orchestrate runner for multi-node, ordered change.
Topics: Scaling the master with syndic · Multi-master and failover configuration · Master performance tuning and worker threads · Salt SSH: advantages, disadvantages and use cases · Installing and configuring Salt SSH and the roster · Using Salt SSH to manage agentless infrastructure · The orchestrate runner for cross-node sequencing · Salt Cloud for provisioning minions
Writing your own, and keeping the estate healthy. Custom execution modules, state modules, grains and returners in the _modules tree; testing states; logging and debugging a run that silently does nothing; the security posture of the master; and integrating Salt with CI, containers and cloud infrastructure.
Topics: Custom execution modules and _modules sync · Custom state modules and writing idempotent functions · Custom grains and external grain sources · Custom returners and outputters · Testing states and change validation · Logging, log levels and debugging a silent run · Securing the master: eauth, ACLs and the Salt API · Salt with Docker, cloud providers and CI pipelines
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a fleet with mixed grains and write targeting expressions using globs, grains, pillars, node groups and compound matchers until each selects precisely the intended subset.
Write a state tree that takes an empty host to a configured, running service, run it in test mode first, then prove idempotency by applying it twice.
Debug a state tree that converges only on a second run, then rebuild it with explicit require, watch and onchanges requisites so it converges first time, every time.
Move every environment-specific value and credential into pillar, encrypt the secrets with GPG, and prove nothing sensitive appears in state output or logs.
Deploy a beacon that watches a config file and a disk threshold, wire reactors that remediate both, then deliberately trigger each and prove the loop terminates.
Design and build a multi-region topology using a syndic for fan-out and Salt SSH for hosts that cannot take a minion, then orchestrate one ordered change across all of it.
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
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
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.
| 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.