Private corporate batches, live online cohorts and 1-on-1 mentoring in declarative, pull-based delivery with Git as the source of truth and continuous reconciliation — 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 GitOps as an operating model rather than a controller install — the four principles and their consequences, repository topology and promotion design, the boundary between what Git owns and what a runtime controller owns, and the drift and reconciliation behaviour that makes the model worth adopting. Sessions work through both major controllers so the decision is informed rather than inherited, and cover the parts that break in production: secrets in a public model, environment promotion without branch sprawl, progressive delivery, and recovering a cluster from Git alone.
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 GitOps that means a trainer who has run it in production — declarative, pull-based delivery with Git as the source of truth and continuous reconciliation — 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 GitOps batchGitOps is an operating model for delivery, not a product. Four properties define it: the desired state of a system is described declaratively; that description is versioned and immutable, so every state has an identity you can name; a software agent pulls the description rather than a pipeline pushing into the target; and the agent continuously reconciles actual state toward desired state, forever, not once at deploy time.
The consequences follow from those four properties rather than from any tool. Because state is declared and versioned, a rollback is a revert and an audit trail already exists in the commit history. Because the agent pulls, deployment credentials stay inside the target environment instead of being handed to a CI runner. Because reconciliation is continuous, a change made by hand at 2am is detected and either corrected or surfaced — configuration drift stops being invisible.
GitOps is frequently confused with two neighbours. It is not simply infrastructure as code: storing Terraform in Git is a prerequisite, not GitOps, because nothing reconciles continuously. Nor does it replace continuous integration: CI still builds, tests and publishes artifacts. GitOps takes over at the boundary where an artifact becomes running state. Kubernetes is the most common substrate because its API server already accepts declarative desired state and its controllers already reconcile, but the model applies wherever a reconciling agent can be run.
Two forces made this shift practical. Kubernetes gave the industry a declarative API with reconciliation built into the platform itself, and the security review of CI systems got serious after a decade of build servers holding production credentials. GitOps addresses both at once, which is why it moved from a niche practice to the default deployment architecture for Kubernetes estates in only a few years.
The operational argument is stronger than the security one for most teams. Drift is the quiet cost of push-based deployment: nobody knows how many live resources no longer match anything in a repository, and the answer is discovered during an incident. A reconciling agent turns that into a continuously answered question, and turns rollback into an ordinary Git operation rather than an emergency procedure.
What organisations are hiring for is the design work, not the installation. Repository topology, how environments are promoted, where the boundary sits between Git-owned and runtime-owned state, how secrets live in a public model, and how a hundred teams share a platform without stepping on each other — those decisions are made once and lived with for years.
The model stated precisely before any tool appears. Where the practice came from, the problems it was a response to, and the two things it is most often confused with: infrastructure as code, and continuous deployment.
Topics: Origins and the problem being solved · GitOps is not infrastructure as code · GitOps does not replace continuous integration · How GitOps reverses the traditional CI/CD picture · Where the model does not apply · Required knowledge: Git, Kubernetes, containers, CI
Each principle and what it buys. Declarative state and immutability, the pull agent and the credential argument, convergence and continuous reconciliation, and how immutable infrastructure and orchestration fit around the model.
Topics: Declarative desired state · Versioned and immutable state · Pull versus push and credential blast radius · Continuous reconciliation and convergence · Immutable infrastructure · Orchestration as the reconciling substrate · Drift: detection, correction and acceptance
The end-to-end shape of the system. Where CI stops and GitOps starts, how the artifact and the manifest relate, what the agent does on each interval, and the architectural pieces a full implementation needs.
Topics: GitOps workflow end to end · GitOps architecture and components · The CI/CD boundary and the artifact handoff · Application repository vs infrastructure repository · Pull request as the change interface · Reconciliation loop timing and webhooks · Observability of the delivery system itself
The decision that outlives every other. Mono-repo versus repo-per-team versus repo-per-environment, directories versus branches versus repositories for environments, and how to model differences between environments without duplicating manifests.
Topics: Mono-repo, per-team and per-environment topologies · Environments as folders, branches or repositories · Why branch-per-environment usually fails · Overlays and templating for environment difference · Directory conventions and ownership boundaries · CODEOWNERS and review policy · Blast radius and repository permissions
The working environment for everything that follows. Cluster access and kubectl or k9s checks, the infrastructure and application repositories, a container registry, and a sample service that can actually be deployed and changed.
Topics: Cluster access and kubeconfig credentials · Checking pods, deployments and events with kubectl · k9s for fast inspection · Creating the infrastructure repository · Creating the application repository · Building and pushing a sample service image · Registry choice and pull credentials
The first real GitOps loop. Installing a reconciling controller into the cluster, pointing it at the infrastructure repository, and deploying a Deployment and Service entirely through commits rather than kubectl apply.
Topics: Installing a controller into its own namespace · Registering a repository as a source · Declaring the first application · Deployment manifest in code · Adding a Service to expose it · Exposing externally with a load balancer or ingress · CLI-driven versus Git-driven changes · Verifying with kubectl and curl
Turning a one-shot deploy into continuous reconciliation. Automatic sync, pruning, self-healing, and the deliberate exceptions — plus what happens when a manifest change and an image change arrive at once.
Topics: Enabling automatic synchronisation · Pruning deleted resources · Self-healing and manual override · Updating a deployment manifest and syncing · Updating a container image and syncing · Introducing configuration drift and observing correction · Ignoring server-populated fields · Sync ordering and dependencies
Getting a change from development to production without copy-paste. Registering a second cluster, the options for representing stages, and building a promotion path that is reviewable and reversible.
Topics: Registering a second cluster with the controller · Options for representing stages, and their trade-offs · Promotion by folder, by repository and by branch · Promoting a version between environments · Pull requests and required checks as promotion gates · Automated promotion on successful staging deploy · Environment-specific configuration without duplication · Preview environments per pull request
Replacing an all-at-once rollout. Blue/green and canary strategies, how a progressive-delivery controller cooperates with a reconciling controller, and how to gate promotion on metrics instead of on a person watching.
Topics: Rolling update, blue/green and canary compared · Progressive delivery controllers alongside GitOps · Blue/green with preview and active services · Canary with weighted traffic steps · Metric analysis as a promotion gate · Traffic shaping via ingress or service mesh · Automatic abort and rollback · Trade-offs of each strategy
The discipline that makes GitOps operationally honest. A broken deployment is expected; the response is a code change, not a panicked kubectl edit. Detecting failure, reverting deliberately, and the cases where breaking glass is legitimate.
Topics: Introducing a deliberate application failure · Confirming failure with kubectl and controller status · Reverting a failed change through Git · Rollback versus roll-forward · Break-glass access and how to make it visible · Health assessment and what 'healthy' means · Alerting on reconciliation failure · Post-incident reconciliation of manual changes
The hardest part of GitOps. Why plaintext secrets can never be committed, the three workable patterns, and the operational reality of each: key custody, rotation, and what happens when the decryption key is lost.
Topics: Why no plaintext secret ever goes in Git · Sealed secrets: controller, encryption and cluster binding · SOPS with age or cloud KMS · External secret operators pulling from a secret manager · Vault as a backing store · Injecting a secret into a workload · Rotation and key loss recovery · Auditing who can decrypt what
The recap and the next mile. Why kubectl is not observability, what metrics and logs a GitOps estate needs, how access to production is granted and audited, and what changes when the model spreads across many teams and clusters.
Topics: kubectl access is not observability · Metrics, logging and tracing for meshed services · Monitoring the reconciliation loop itself · Access control and audit for production clusters · Multi-tenancy and platform team boundaries · Fleet management across many clusters · Onboarding a new team onto the platform · Choosing a controller: Argo CD versus Flux on real criteria
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall a reconciling controller, point it at a repository, and get a service running externally where every change arrives as a commit.
Create drift by editing a live resource, deleting an object and scaling a replica set, then record precisely which are corrected and which are not.
Register a second cluster and promote a version between environment folders with a required check gating the production change.
Run a blue/green cutover, then a weighted canary that aborts automatically when error rate regresses against a baseline.
Seal a secret into the infrastructure repository, inject it into the service, then rotate the key and recover from a simulated key loss.
Destroy the cluster entirely, restore every workload from the repository, and document precisely what Git did not hold and why.
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.
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.
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.
| 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.