Private corporate batches, live online cohorts and 1-on-1 mentoring in repository governance, Actions pipelines, supply-chain security and Enterprise administration — 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 GitHub as a platform to be administered rather than a site to browse: organisation and team permission design, CODEOWNERS with required reviews and required status checks, rulesets and branch protection, and GitHub Actions in depth — event triggers, job dependencies and matrices, reusable workflows and composite actions, self-hosted runner fleets, GITHUB_TOKEN permissions and OIDC federation into AWS and Azure instead of stored cloud keys. Sessions extend into Advanced Security workflows — Dependabot, CodeQL, secret scanning and push protection — and GitHub Enterprise Server operations including pre-receive hooks, high availability, backup and ghe-migrator migrations, demonstrated live against real repositories and runners.
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 GitHub that means a trainer who has run it in production — repository governance, Actions pipelines, supply-chain security and Enterprise administration — 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 GitHub batchGitHub is a hosted platform built around Git repositories, but the repository is the smallest part of what an organisation actually adopts. Around it sit organisations and teams, permission models, protected branches and rulesets, pull requests with required reviews and required status checks, an automation engine in GitHub Actions, package hosting, an issues and projects layer, and a set of supply-chain security products — Dependabot, CodeQL code scanning, secret scanning with push protection.
GitHub Actions is the piece that changes how teams work. Workflows are YAML files in .github/workflows that respond to events — pushes, pull requests, schedules, manual dispatch, or events raised by other workflows — and run jobs on GitHub-hosted or self-hosted runners. Jobs declare dependencies, fan out over a matrix, publish artifacts, and gate deployments through environments with protection rules. Reusable workflows and composite actions turn copy-pasted CI into a governed, versioned internal library, and OIDC lets a workflow assume a cloud role without a long-lived secret stored anywhere.
GitHub comes in more than one deployment shape. GitHub Enterprise Cloud adds SAML SSO, SCIM provisioning and enterprise policy; GitHub Enterprise Server is an appliance you install, network, monitor, back up, cluster for scale and configure for high availability, with pre-receive hooks and ghe-migrator for policy enforcement and migration. Running GitHub well means treating it as a platform to administer, not a website to log into.
GitHub is where most software now lives, and that concentration has moved the skill requirement well past 'can open a pull request'. When the repository host is also the CI system, the artefact registry, the identity boundary and the vulnerability scanner, the decisions made there become production decisions.
The demand is concentrated in three areas. First, Actions at scale — teams start with a workflow that runs tests and end up with hundreds of workflows, self-hosted runner fleets, secrets sprawl and no reuse strategy, and they need someone who can consolidate that into reusable workflows with pinned actions and least-privilege tokens. Second, governance — CODEOWNERS, rulesets, required checks, branch protection and organisation policy are how audit requirements are actually satisfied, and most teams configure them once, incorrectly. Third, supply-chain security, which has moved from optional to contractual in a large share of enterprise procurement.
Add GitHub Enterprise Server administration and migrations from other platforms, and the gap is not familiarity with GitHub's interface — it is engineering judgement about how to configure it for an organisation that has to prove what it did.
What GitHub actually is beyond repository hosting, and which GitHub you are running. Enterprise Cloud, Enterprise Server and github.com differ in identity, policy and networking, and those differences determine most later decisions. The object model — enterprise, organisation, team, repository, project — and how it maps to a real company.
Topics: github.com vs Enterprise Cloud vs Enterprise Server · The enterprise, organisation, team and repository hierarchy · Exploring projects and the platform surface · Repository visibility: public, internal, private · Where policy is set at each level · Licensing and seat models
How identity works on GitHub and how it fails. Personal account setup and profile management, two-factor enforcement, SSH and GPG keys, commit signing and verified commits, then SAML SSO and SCIM provisioning for organisations that need joiners and leavers to be automatic rather than remembered.
Topics: Setting up and managing a GitHub account and profile · Authenticating to GitHub: SSH keys, HTTPS and credential helpers · Two-factor enforcement and recovery · GPG and SSH commit signing, verified commits · SAML SSO and SCIM provisioning · User security settings and session management · Authenticating users on a GitHub Enterprise instance
The permission layer teams misconfigure first. Organisation roles and base permissions, nested teams and team-based access, repository roles including custom roles, outside collaborators, and the repository settings that quietly matter — merge strategies, auto-merge, deletion protection, archiving and transfers.
Topics: Organisation settings, roles and base permissions · Teams, nested teams and team-based repository access · Repository roles and custom repository roles · Outside collaborators and managing repository collaborators · Creating, cloning, transferring and archiving repositories · Administering a repository: merge strategies, auto-merge, default branch · Managing remotes and repository topics · Gists, wikis and repository metadata
The engineering process, expressed as configuration. Pull requests and review mechanics, draft PRs, suggested changes and review conversations; then the enforcement layer — CODEOWNERS, required reviews, required status checks, linear history, blocking force pushes, and repository rulesets as the modern replacement for per-branch protection.
Topics: Collaborating with issues and pull requests · Review mechanics: draft PRs, suggestions, review states · CODEOWNERS: syntax, precedence and required owner review · Branch protection rules and repository rulesets · Required status checks and merge conditions · Blocking force pushes and enforcing linear history · Merge, squash and rebase — and which one your history needs · Writing on GitHub: Markdown, templates and PR/issue forms
From a first workflow to a working mental model of the execution engine. Events and triggers, jobs and steps, runners, contexts and expressions, artifacts and caching, and the debugging techniques that matter when a workflow behaves differently from the same commands on a laptop.
Topics: Workflow syntax and the .github/workflows layout · Events: push, pull_request, schedule, workflow_dispatch, repository_dispatch · Jobs, steps, runs-on and job dependencies with needs · Contexts, expressions, conditionals and job outputs · Matrix builds, include/exclude and fail-fast · Artifacts, caching and dependency restoration · Using and pinning marketplace actions · Debugging workflows: logs, re-runs and local reproduction
What separates a hundred copy-pasted workflows from a platform. Reusable workflows and composite actions, an internal actions library with versioning, self-hosted runners and runner groups, then environments, deployment protection rules and OIDC federation so deployments are gated and credentials are short-lived.
Topics: Reusable workflows: inputs, secrets and versioning · Composite actions and building an internal action library · Self-hosted runners, runner groups, labels and autoscaling · Runner security: ephemeral runners and untrusted code · Environments, required reviewers and deployment protection rules · OIDC federation to AWS, Azure and GCP without stored keys · GITHUB_TOKEN permissions and least-privilege workflow tokens · Concurrency, timeouts and cost control
The security products, and — more importantly — the triage discipline that makes them useful rather than noise. Dependabot alerts, security updates and version updates; CodeQL code scanning including custom configuration; secret scanning with push protection; dependency review on pull requests; and the policy questions of what blocks a merge and what only warns.
Topics: Dependabot alerts, security updates and version updates · Code scanning with CodeQL: default setup and advanced configuration · Secret scanning and push protection · Dependency review and the dependency graph · Security advisories and private vulnerability reporting · Triage: severity, false positives and dismissal policy · Blocking vs warning — designing enforceable security gates · Pre-receive hooks to enforce policy on Enterprise Server
Driving GitHub from outside the interface. The REST and GraphQL APIs and when each is the right choice, GitHub Apps versus PATs versus fine-grained tokens, webhooks for continuous integration and external systems, and the CLI and Octokit clients that make bulk administration possible.
Topics: REST API and GraphQL API — choosing between them · GitHub Apps vs OAuth Apps vs PATs vs fine-grained tokens · Installation tokens and app permissions · Using webhooks for continuous integration and external systems · gh CLI and Octokit for scripted administration · Rate limits, pagination and conditional requests · Checks API and status reporting from external CI · Connecting GitHub Enterprise Server and GitHub.com
The parts of GitHub that are not code but end up carrying the process. Issues, labels, milestones and Projects for planning; search and code navigation; Pages for documentation sites; and Git LFS for repositories that carry binaries — including what LFS costs and when it is the wrong answer.
Topics: Issues, labels, milestones and issue forms · GitHub Projects: views, fields and automation · Managing your work and notifications on GitHub · Searching for information across code, issues and organisations · Visualising repository data with graphs and insights · Managing files and non-code content in a repository · Managing large files with Git LFS, including LFS on Enterprise Server · GitHub Pages: basics, sources and customisation
Operating the appliance. Installation and configuration, network settings, monitoring and resource sizing, high availability and clustering, backup and upgrade procedure — the work that exists only when GitHub runs on infrastructure you own.
Topics: Installing and configuring GitHub Enterprise Server · System overview and the management console · Network settings, TLS and DNS configuration · Monitoring the appliance and updating virtual and physical resources · Configuring high availability and replication · Clustering: overview, cluster instances and how it differs from HA · Backup, restore and disaster recovery · Working with GitHub Support and support bundles
Moving onto GitHub, and moving between GitHubs. Exporting migration data from Enterprise Server and from github.com, importing with ghe-migrator, importing from third-party version control systems, and the parts that never migrate cleanly — permissions, CI history, webhooks and integrations.
Topics: Planning a migration: inventory, ownership and cutover · Exporting migration data from GitHub Enterprise Server · Exporting migration data from GitHub.com · Importing migration data with ghe-migrator · Importing from third-party version control systems · Migrating user, organisation and repository data · What does not migrate: permissions, CI history, integrations · Post-migration verification and rollback
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a written engineering policy and implement it entirely as CODEOWNERS, rulesets, required reviews and required status checks — then attempt to bypass it and prove you cannot.
Build a workflow that lints, tests across a matrix, caches dependencies, publishes artifacts and reports a check on every pull request.
Refactor duplicated workflows into versioned reusable workflows and composite actions, then consume them from three repositories.
Delete a stored cloud access key, configure OIDC trust, and deploy from a gated environment with short-lived credentials only.
Enable CodeQL, Dependabot and secret scanning with push protection on a real repository, then triage the results and decide what blocks a merge.
Design an organisation and team model, automate it through the API, then plan an Enterprise Server migration with verification and rollback.
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.
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.
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.
| 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.