Private corporate batches, live online cohorts and 1-on-1 mentoring in release management and deployment automation — environments, lifecycles, scoped variables, multi-tenancy and operations runbooks — 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 Octopus Deploy around the release object rather than the user interface — why a Release snapshots process and variables, how Lifecycles and Channels make promotion enforceable, and where variable scoping resolves when environment, role, channel and tenant scopes all apply at once. Sessions cover Tentacle listening and polling targets, SSH and Kubernetes targets, workers and worker pools, packaging and build server integration, custom and community step templates, tenant modelling for multi-customer deployments, operations runbooks, and the operational side: SQL Server backing store, high availability, retention policies, config-as-code and a full backup and restore drill.
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 Octopus Deploy that means a trainer who has run it in production — release management and deployment automation — environments, lifecycles, scoped variables, multi-tenancy and operations runbooks — 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 Octopus Deploy batchOctopus Deploy is a release management and deployment automation platform. It deliberately does not build your software. It takes the package your build server produced, wraps it in a Release together with the deployment process and the variable values as they existed at that moment, and then deploys that immutable Release to Development, Test, Staging and Production in an order you define. Building once and promoting the same package everywhere is not a convention you have to enforce by discipline in Octopus Deploy; it is the shape of the product.
The concepts that carry the weight are Environments, Lifecycles, Channels and Variables. A Lifecycle defines the phases a Release must pass through and which of them require sign-off, so a package cannot reach production without having succeeded in test. Channels let a hotfix or a prerelease follow a different route through those phases. Variables are the part teams underestimate: values are scoped by environment, role, machine, channel, step or tenant, snapshotted into the Release, and substituted into configuration files at deployment time — which is how one package can be genuinely environment-agnostic.
Deployment targets are equally broad. Tentacle agents run in listening or polling mode for Windows and Linux servers, SSH targets cover anything else, and there are first-class targets for Kubernetes clusters, Azure web apps and cloud regions, with Workers running steps that should not execute on the target itself. Steps come from a large built-in and community template library, and can be extended with your own. Runbooks apply the same engine to operations work — restarting services, rotating certificates, restoring databases — and multi-tenancy lets one project deploy to hundreds of customers or regions with per-tenant variables.
Most organisations have solved continuous integration and left deployment as the manual step at the end. The symptoms are consistent: a different artifact built per environment, configuration edited by hand on the target server, a release process that lives in someone's head, and no reliable way to answer what version is in production and who approved it. Octopus Deploy is bought specifically to close that gap, and it is bought most often by teams that already have a build system they are happy with.
The second driver is auditability. Regulated environments need to show that the binary in production is the one that passed testing, that a named person approved the promotion, and that the variables used were the ones recorded against the release. Because Octopus Deploy snapshots the process and variables into an immutable Release and logs every deployment, that evidence is a by-product rather than a project.
Multi-tenancy is the third, and it is where teams most often need help. Deploying one product to two hundred customers, each with their own database, domain and licence key, is a modelling problem before it is a tooling problem. Getting tenants, tenant tags, tenant variables and tenant-connected environments right is the difference between a clean promotion and two hundred hand-edited project variables.
Hands on the product before the theory. A working deployment from package to running application in the first session, then a first runbook run, so every later concept attaches to something the attendee has already seen execute.
Topics: Introduction to Octopus Deploy · Terminology and glossary · Your first Octopus deployment · Your first runbook run · The dashboard and project view · Deployment logs and what they tell you · Best practices overview
What is actually happening when you click deploy. The server, the SQL Server backing store, the task queue, Tentacle communication in both directions, and the Release as an immutable snapshot of process, variables and packages.
Topics: Octopus Deploy architecture · How a deployment executes end to end · Server, database and task queue · Tentacle communication: listening vs polling · Releases as immutable snapshots · Deployments versus releases · Spaces and how they isolate everything · Where deployments fail and how to read the log
Both hosting models, honestly compared. Self-hosted installation requirements, SQL Server, service accounts and troubleshooting; then Octopus Cloud, its data and network characteristics, and what migrating between the two actually involves.
Topics: Installation requirements and sizing · SQL Server database configuration · Permissions for the Octopus Windows Service · Using a Managed Service Account · Troubleshooting the Octopus installation · Automating installation · Running Octopus as a container · Isolated Octopus servers · Octopus Cloud overview, data and static IP addresses · Cloud permissions and dynamic workers · Migrating between self-hosted and Octopus Cloud
The estate Octopus Deploy deploys to. Environments and their ordering, every target type and when to use each, machine roles and target tags, cloud accounts, and workers for steps that must not run on the target.
Topics: Environments and environment ordering · Listening and polling Tentacles · SSH targets and Linux deployment · Kubernetes cluster targets · Azure and cloud region targets · Machine roles and target tags · Accounts: AWS, Azure, Google Cloud, SSH keys and tokens · Workers and worker pools · Health checks and machine policies
How code becomes something Octopus Deploy can promote. Package formats and versioning, creating packages from your build, pushing them to a feed, and wiring the build server so a successful build produces a release automatically.
Topics: Creating packages: zip, NuGet and tar.gz · Package versioning conventions · The built-in package repository · External feeds: Artifactory, Nexus, Maven, Docker registries · Build server integration and plugins · Push package, create release, deploy release · Container images as deployable packages · Package retention
Where the deployment is actually defined. Project structure, ordering and parallelism in the deployment process, the built-in step template library, community templates, writing custom templates and — the part teams get wrong — updating template versions across projects.
Topics: Projects and project groups · The deployment process and step ordering · Built-in step templates · Deploy a package, run a script and manual intervention steps · Kubernetes, Helm and Terraform steps · Community step templates · Custom step templates and parameters · Updating step templates across projects · Exporting and importing projects · Project recommendations and structure
The most powerful and most misunderstood part of the product. Variable scoping across environment, role, machine, channel, step and tenant; library variable sets; sensitive variables; configuration file substitution; output variables; and how to debug which value actually won.
Topics: Variable scoping rules and precedence · Library variable sets · Sensitive variables and secret handling · Variable substitution syntax and configuration transforms · Structured configuration variables in JSON and YAML files · Output variables between steps · Variable snapshots on the release · Variable preview and debugging · Prompted variables at deployment time
Making promotion a rule rather than a habit. Lifecycle phases and optional or required environments, retention per phase, channels for hotfix and prerelease routes, version rules, and the triggers that automate promotion.
Topics: Lifecycles and phases · Optional and mandatory phase environments · Retention policies per phase · Channels and channel rules · Version rules and prerelease tags · Hotfix channels and emergency paths · Project triggers: scheduled, deployment target and release · Coordinating multiple projects · Deploy release step and orchestrating dependent projects
One project, many customers or regions. Tenant modelling before tooling — tenant types, tenant-connected environments, project and common variable templates, tag sets for grouping, tenant lifecycles, and the deployment patterns that keep two hundred tenants manageable.
Topics: When multi-tenancy is the right model · Tenant types and tenant creation · Connecting tenants to projects and environments · Tenant variables: project templates and common templates · Tenant tags and tag sets · Tenant infrastructure and dedicated targets · Tenant lifecycles · Tenant roles and security · Multi-tenant deployment patterns and guides
The same engine applied to operations rather than releases. Runbooks for restarts, certificate rotation, database restores and disaster recovery; runbook snapshots and publishing; scheduled triggers; and running operations work against production with the same audit trail as a deployment.
Topics: Runbooks versus deployment processes · Runbook snapshots and publishing · Scheduled runbook triggers · Runbooks against production targets · Common runbooks: restart, rotate, restore, scale · Permissions for runbook execution · Runbook parameters and prompted variables · Auditing operations work
Operating Octopus Deploy for an organisation. Spaces, teams and user roles; external authentication; API keys and service accounts; version-controlled deployment processes; then high availability, retention, backup, restore and upgrade.
Topics: Spaces and isolation between business units · Teams, user roles and scoped permissions · External authentication: Active Directory, Entra ID, LDAP, Okta · API keys, service accounts and the REST API · The audit log and change traceability · Config as code and version-controlled projects · High availability and multiple nodes · Retention policies for releases, packages and tasks · Backup, restore and upgrade procedure
We rebuild the agenda around the tools you actually run.
Request a custom agendaRegister listening and polling Tentacles, an SSH target and a Kubernetes cluster, assign roles, and route steps to a worker pool instead of the targets themselves.
Make a single package deploy correctly to dev, test and production using scoping, library variable sets and configuration substitution — then debug a case where the wrong value wins.
Build lifecycles and channels so a release cannot reach production without passing test, then add a legitimate hotfix route that bypasses exactly one phase.
Model tenants with per-customer databases and domains using tenant variable templates and tag sets, then onboard a new tenant without touching the project.
Convert three production procedures currently done by hand into published, scheduled runbooks with parameters, permissions and an audit trail.
Configure high availability, retention and roles, then back up the server and SQL Server database, destroy the instance and restore every project, release and variable.
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 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.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
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.
| 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.