Private corporate batches, live online cohorts and 1-on-1 mentoring in one to three day hands-on intensives built backwards from a working artefact the team keeps and uses afterwards — 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 designs and facilitates technical workshops backwards from the artefact — deciding what will exist in the team's repository at the end, cutting the syllabus to the minimum needed to build it, and scaffolding the day with checkpoint branches so a delayed attendee rejoins at the next segment rather than falling out entirely. The delivery is facilitation rather than lecture: pre-flight environment verification, enforced timeboxes, a majority of hands-on time, and a written follow-through plan for the artefact. The technical range spans containers, Kubernetes, CI/CD, infrastructure as code, observability and secure pipelines, drawing on 20 years across DevOps, SRE and Security and 10,000+ engineers trained.
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 Technical Workshops that means a trainer who has run it in production — one to three day hands-on intensives built backwards from a working artefact the team keeps and uses afterwards — 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 Technical Workshops batchTechnical workshops are a delivery format, not a shorter course. A course covers a subject; a workshop produces an artefact. The format runs one to three days, holds a single narrow objective, spends the majority of its time with attendees at a keyboard, and finishes with something concrete in the team's own repository — a working pipeline, a deployed cluster with an application on it, a Terraform module, an instrumented service with an alert that fires, or a documented incident timeline from a game day.
That constraint drives the design. A workshop is built backwards from the artefact: decide what will exist at the end, work out the minimum concepts needed to build it, and cut everything else. Content is scaffolded so that nobody is stranded — each segment starts from a known-good state in a branch, so an attendee who falls behind rejoins at the next checkpoint rather than spending the afternoon debugging a typo from the morning. Timeboxes are enforced, environments are verified before the day starts rather than during it, and the trainer works as a facilitator moving between people rather than presenting from the front.
The formats that work differ in shape. A build workshop produces a pipeline or a module. A migration workshop moves one real service onto a new platform as a worked reference for the rest. A game day breaks a running system deliberately and exercises detection, diagnosis and communication under time pressure. An architecture workshop produces a decision record with the trade-offs written down. All of them share the same rule: technical workshops that end in slides and good intentions have failed, and the test is whether the artefact is still in use a month later.
Attention is the scarce resource in corporate learning. A five-day programme is hard to schedule across a delivery team, and a one-hour lunch session teaches nothing that survives the week. The intensive sits in between: short enough that an engineering manager will release the team, long enough that something real gets built.
The format also matches how adoption actually happens. Platform migrations, tooling changes and new architectural patterns stall not because engineers cannot learn them but because nobody has time to do the first one. A workshop that takes a real service through the change, with the team doing the work and a practitioner in the room, converts a backlog item into a worked example the rest of the estate can follow.
And it fits how teams already meet. Offsites, quarterly planning weeks, hackathons and onboarding cohorts are all existing slots where a focused technical intensive lands better than a lecture. The value is not the day itself but what leaves with the team: a repository they wrote, a pipeline that runs, and a shared reference point that makes the next conversation shorter.
How a day is built so that it produces something. Working backwards from the artefact to the minimum concept set, scaffolding with checkpoint branches, splitting content into enforced timeboxes, and the environment pre-flight that prevents the first two hours being lost to installation. Relevant to buyers scoping a workshop and to teams running their own internal enablement.
Topics: Defining a single objective and the artefact that proves it · Working backwards from the artefact to the concept set · Scaffolding: starting states, checkpoint branches and rejoining · Timeboxing and the ratio of hands-on to explanation · Pre-flight environment verification before day one · Cohort size, pairing and facilitation ratios · Choosing the format: build, migration, game day or decision workshop · Measuring whether the artefact survived
A one-day intensive that ends with a real application containerised properly and published to a registry. Images and layers, writing a Dockerfile that is small and cacheable rather than merely working, multi-stage builds, and the security and networking basics needed to run it somewhere other than a laptop.
Topics: Images, layers, tags and registries · Writing a Dockerfile: caching, ordering and multi-stage builds · Image size, base image choice and what to exclude · Running containers: ports, volumes, environment and lifecycle · Networking between containers and composing a topology · Non-root users, capabilities and image scanning · Debugging a container that starts and immediately exits · Publishing to a registry and tagging strategy
Two days that take a team from an image to a running, exposed, scalable workload they can debug. Deliberately narrow: the objects needed to run a real service and the diagnostic skills to fix it when it does not start, with the rest of the API surface left out.
Topics: Pods, ReplicaSets, Deployments and rollout behaviour · Services, ingress and getting traffic in · ConfigMaps, Secrets and configuration injection · Requests, limits and what happens when they are wrong · Probes: liveness, readiness and startup · Horizontal scaling and rollout or rollback under load · Debugging: events, logs, exec, describe and pending pods · Persistent storage when the workload needs it
One to two days ending with a pipeline that actually runs on the team's repository. Commit stage design and its time budget, artefact production and promotion, environment progression, and the deployment strategy the team will use — with quality gates wired in rather than bolted on afterwards.
Topics: Pipeline stages and what belongs in each · The commit stage and its feedback budget · Building an artefact once and promoting it · Environment progression and configuration per environment · Secrets and credentials in pipelines · Quality and security gates: what blocks and what reports · Deployment strategies: rolling, blue-green, canary · Pipeline as code, reuse and shared libraries
Two days producing a reviewed, versioned infrastructure module with state handled correctly — which is the part that decides whether infrastructure as code survives contact with a second engineer. Covers the plan and apply lifecycle, remote state with locking, modules, and the review workflow around changes.
Topics: Declarative infrastructure and the plan and apply lifecycle · Remote state, locking and why local state fails a team · Resources, data sources, variables and outputs · Modules: composition, versioning and reuse · Environments without copy-paste · Reading a plan and spotting a destroy-and-recreate · Importing existing infrastructure and handling drift · Pipeline execution and change review
One or two days split between building the telemetry and using it under pressure. The morning instruments a service and defines an alert; the afternoon breaks the system deliberately while the team detects, diagnoses and communicates, then writes a timeline and a set of actions.
Topics: Metrics, traces and logs and what each answers · Instrumenting a service and naming its telemetry · Dashboards built for diagnosis rather than decoration · Symptom-based alerting and proving the alert fires · Game day design: injecting realistic failure safely · Detection, triage, communication and roles during an incident · Writing a timeline from telemetry evidence · Blameless review and turning findings into actions
One to two days adding security controls to a delivery pipeline without stopping delivery. Dependency and container scanning, static analysis, secret detection including in history, signing and provenance — each placed where it is cheapest and tuned so the findings are credible enough to act on.
Topics: Threats specific to the build and delivery path · Dependency scanning and triage by reachability · Container image scanning and base image policy · Static analysis placement and rule tuning · Secret detection in the working tree and in Git history · Credential handling and short-lived pipeline identities · Artefact signing, provenance and software bills of materials · Rolling gates out in advisory mode before blocking
The delivery mechanics that decide whether a workshop lands. Verifying environments before the day, running the room as a facilitator rather than a presenter, handling a wide skill spread without stalling, and the follow-through plan — owner, next step, review date — that keeps the artefact from being abandoned on the Monday.
Topics: Pre-flight checks and access requirements before day one · Facilitating rather than presenting: circulating, pairing, unblocking · Managing a wide skill spread inside one room · Checkpoint recovery when someone falls behind · Energy, breaks and the realistic hands-on ceiling per day · Capturing decisions and open questions as they arise · Handover: repository, documentation and named owner · Follow-up review and measuring whether the artefact survived
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a real application from the team's repository to a small, cacheable, non-root multi-stage image published to a registry — in a single day.
Deploy a real application with configuration, probes and ingress, then diagnose four deliberately broken workloads and demonstrate a rollback.
Build a commit-to-deploy pipeline against the team's own repository, with an artefact promoted rather than rebuilt and a gate that blocks a bad change.
Write a reusable infrastructure module, wire remote state with locking, and apply it through a pipeline with the plan reviewed before it runs.
Instrument a service, define a symptom-based alert, then inject realistic failure and run detection, diagnosis and communication under time pressure.
Package what the workshop produced into the team's repository with documentation, a named owner, a next step and a review date agreed before the day ends.
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
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
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.