Private corporate batches, live online cohorts and 1-on-1 mentoring in declarative pipelines-as-config, containerised steps and versioned resources with no mutable build state — 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 Concourse from its model outward — resources and versions before syntax, the passed constraint as the mechanism that makes promotion provable, and tasks as containers with declared inputs and outputs rather than shell scripts on a shared machine. Sessions cover fly hijack and intercept for live debugging inside a failing container, credential managers with Vault and CredHub so nothing sensitive lives in the pipeline file, writing a custom resource type from its check, in and out scripts, and operating the web and worker fleet including drains, garbage collection and database care.
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 Concourse that means a trainer who has run it in production — declarative pipelines-as-config, containerised steps and versioned resources with no mutable build state — 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 Concourse batchConcourse is an open-source continuous integration system built on a deliberately narrow set of ideas. There are no plugins, no jobs configured through a web form, and no mutable state on a build machine. A pipeline is a YAML document that you push to the server with the fly CLI, and everything the pipeline touches is either a resource — an external, versioned thing such as a Git repository, an S3 object or a container image — or a task, which is a container with declared inputs, declared outputs and a command to run.
That design produces two properties most CI systems cannot offer. The first is reproducibility: because every task declares its own image and its own inputs, a build cannot accidentally depend on something a previous build left behind on the worker. The second is the passed constraint, which is Concourse's genuinely distinctive feature. When a job says it wants a version of a resource that has passed through an earlier job, Concourse tracks version propagation across the whole pipeline graph, so the artifact you deploy is provably the same one that was tested rather than a rebuild that happens to share a commit.
Architecturally Concourse is small: a web node running the ATC scheduler, API and UI, a TSA gateway that workers register through over SSH, a fleet of stateless workers running containers, and PostgreSQL holding all the state that matters. Workers are cattle — drain one and rebuild it. Credentials never live in the pipeline file; they are interpolated at runtime from Vault, CredHub, AWS Secrets Manager or Kubernetes secrets. Teams provide multi-tenancy with role-based access, and the set_pipeline step lets pipelines configure themselves from source control.
Concourse solves a problem that becomes acute at scale: CI estates that drift because build machines accumulate state and configuration lives in a database rather than in Git. Once you have hundreds of pipelines, the ability to delete every worker and rebuild the whole system from YAML and a Postgres backup stops being an aesthetic preference and becomes an operational requirement.
It is also the system of choice where release provenance is scrutinised. Regulated platform teams, infrastructure providers and anyone shipping software other people run in production need to demonstrate that the binary going to production is the exact version that passed the security scan and the integration suite. The passed constraint answers that directly, in a way that a pipeline built from independent jobs sharing a workspace does not.
The learning curve is the honest reason training is bought. Concourse asks engineers to think in versioned resources and immutable containers rather than build steps on a machine, and teams that approach it as "YAML Jenkins" produce pipelines that fight the tool. The gap between a working pipeline and an idiomatic one is large, and it shows up as slow builds, custom resource types that should never have been written, and credentials pasted into the pipeline file.
The mental model before any YAML. Why Concourse has no plugins and no mutable worker state, what a resource actually is, how versions are discovered and propagated, and an honest comparison against script-driven CI systems including where Concourse is the wrong choice.
Topics: Pipelines as configuration, not database state · Resources, resource types and versions · Jobs, builds and the scheduler · Containers as the unit of execution · Concourse compared with script-driven CI · Where Concourse is the wrong answer
Getting a working cluster and the command line that operates it. Quickstart with docker-compose, then the real architecture: web node, TSA worker registration, worker fleet and PostgreSQL. Then fly, which is the only interface that matters day to day.
Topics: Architecture: web, TSA, workers, PostgreSQL · Deployment options: binary, docker-compose, Helm, BOSH · fly login and target management · set-pipeline, unpause-pipeline, destroy-pipeline · validate-pipeline and format-pipeline · watch, trigger-job and check-resource · The web UI and what it is good for
The pipeline language in depth. Build plans made of get, put and task steps, running work concurrently with in_parallel, grouping with do, tolerating failure with try, and the hooks that run on success, failure, error and abort.
Topics: get, put and task steps · Build plan structure and ordering · in_parallel, do and try · on_success, on_failure, on_error, on_abort and ensure · trigger: true and manual jobs · Job serial, serial_groups and max_in_flight · Groups for organising a large pipeline
The unit of work, treated properly. Task configuration files versus inline task specs, choosing an image resource, declaring inputs and outputs so files flow between steps, caches, params, and privileged execution when it is genuinely required.
Topics: Task config files vs inline task specs · platform and image_resource · Declared inputs and outputs · params and environment · Task caches · run: path and args · Privileged tasks and their cost · Sharing task files across pipelines
The feature that distinguishes Concourse. How version propagation works across the pipeline graph, why passed makes artifact promotion provable, and the resource types teams actually use — plus writing your own when nothing fits.
Topics: The passed constraint and version propagation · git, s3, semver, time and registry-image resources · github-release, slack-notification and pool resources · Locking with the pool resource · Custom resource types: check, in and out · Packaging a resource type as a container image · version: every vs latest · Resource checking, intervals and webhooks
Multi-tenancy and secrets, which in Concourse are the same conversation. Var interpolation from an external credential manager, team-scoped and pipeline-scoped secret paths, authentication providers and the four RBAC roles.
Topics: Var interpolation and why secrets never live in pipeline YAML · Vault as a credential manager · CredHub, AWS Secrets Manager and SSM · Kubernetes secrets backend · Team and pipeline credential path scoping · Teams and multi-tenancy · OAuth, OIDC, GitHub and LDAP authentication · Roles: owner, member, pipeline-operator, viewer
Keeping a hundred pipelines maintainable. Var files and var_sources, the across step for matrix builds, set_pipeline so pipelines configure themselves from Git, and templating strategies including their failure modes.
Topics: Var files and -l on set-pipeline · var_sources and per-pipeline credentials · The across step for matrix execution · load_var for runtime values · The set_pipeline step and self-updating pipelines · Pipeline templating approaches and their trade-offs · Instanced pipelines · Archiving and pausing pipelines
Running Concourse in production. Debugging live inside a failing container with intercept and hijack, worker lifecycle and draining, garbage collection and disk pressure, build log retention, upgrades, metrics and the database that holds all the state.
Topics: fly intercept and hijack for live debugging · Worker states, draining, retiring and landing · Garbage collection and volume disk pressure · Build log retention policies · Upgrading web and worker nodes · PostgreSQL sizing, backup and migration · Prometheus metrics and alerting · Scaling web and worker tiers · Common failure signatures and their causes
We rebuild the agenda around the tools you actually run.
Request a custom agendaStand up web, worker and PostgreSQL, register a second worker through the TSA, and set your first pipeline entirely from the fly command line.
Take a monolithic shell build script and decompose it into resources, tasks with declared inputs and outputs, and a build plan that fans out in parallel.
Build a promotion pipeline where the passed constraint makes it structurally impossible for an untested version to reach the deploy job, then try to break it.
Implement check, in and out for a resource Concourse has no type for, package it as a container image, and consume it from a pipeline.
Move every credential in a working pipeline into Vault with team-scoped paths, then verify a second team cannot read them.
Debug a failing build from inside its container with intercept, then drain and replace a worker and restore the database without losing pipeline configuration.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
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.
| 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.