Private corporate batches, live online cohorts and 1-on-1 mentoring in evaluating Octopus Deploy and getting a first real deployment, runbook and pilot into production — 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 runs Octopus engagements as evaluation and onboarding rather than product demonstration: what the tool replaces, what it does not replace, and where it is the wrong answer. Sessions build a first deployment and a first operations runbook live against a real target, then model one of the client's own applications — its environments, its artifacts, its configuration differences and its approval requirements — so the decision is made against evidence rather than a vendor deck. Deeper work on lifecycles, variable scoping, multi-tenancy and server operations is covered in the full Octopus Deploy programme.
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 that means a trainer who has run it in production — evaluating Octopus Deploy and getting a first real deployment, runbook and pilot into production — 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 batchOctopus — the product is formally Octopus Deploy, and most teams shorten it — is deployment automation and release management for software you have already built. It is not a build server and it does not compile anything. It takes an artifact your CI system produced, records it as a Release together with the deployment steps and variable values in force at that moment, and then promotes that same artifact through Development, Test, Staging and Production in a defined order. Building once and deploying the identical package everywhere is not a convention you have to police; it is how the product works.
That positioning is the first thing to understand when evaluating it. Octopus is bought by teams who are broadly happy with their build system and unhappy with everything that happens afterwards: an artifact rebuilt per environment, configuration edited by hand on the target, a promotion process that lives in one person's head, and no reliable answer to what version is in production and who approved it. It deploys to Windows and Linux servers through its Tentacle agent or over SSH, and has first-class targets for Kubernetes, Azure and cloud platforms. It also runs operations tasks — restarts, certificate rotation, database restores — through the same engine, which is the feature teams tend to underestimate at evaluation time.
This page covers the front end of that journey: deciding whether Octopus is the right answer, getting a first deployment and a first runbook working, and modelling one real application as a pilot. The full curriculum — lifecycles and channels, variable scoping in depth, multi-tenancy, workers, config-as-code and running the server in high availability — is on the Octopus Deploy trainer page.
Most organisations solved continuous integration years ago and left deployment as the manual step at the end. That gap is now the visible constraint: builds finish in minutes and releases still take days, because the remaining work is people coordinating environments, editing configuration files and signing off in email.
Evaluation is where teams waste the most time. A trial gets installed, someone deploys a sample application, and then the project stalls because nobody has modelled a real application against real environments with real variables — which is the only exercise that tells you whether the tool fits. A short, structured evaluation with a working pilot produces a defensible decision in days rather than a proof of concept that drifts for a quarter.
The second driver is evidence. Regulated environments increasingly need to show that the binary in production is the one that passed testing, that a named person approved the promotion, and that the configuration used was the configuration recorded. Tools built around an immutable release object produce that trail as a by-product. Deciding whether you need that, and what it would cost to adopt, is a leadership question as much as an engineering one — which is why this page is framed around evaluation and pilot rather than around feature coverage.
The positioning question first, because getting it wrong wastes the whole evaluation. What the product does and deliberately does not do, the vocabulary you will meet in the interface, and an honest comparison against deploying straight from Jenkins, GitHub Actions, Azure Pipelines or GitLab CI.
Topics: Build versus deploy, and why separating them matters · Core vocabulary: project, release, deployment, environment, target, variable · What a Release actually captures · Deploying from your CI system versus deploying from Octopus · Where Octopus is the wrong answer · How the pieces fit: server, targets, packages, projects
Hands on the tool immediately. Provisioning a trial instance or installing the server, registering a first deployment target, pushing a package, defining a minimal deployment process and running it end to end — then reading the deployment log properly when something fails, which it will.
Topics: Provisioning Octopus Cloud or installing the server · The built-in package repository and pushing a package · Registering a first deployment target · Creating a project and a minimal deployment process · Creating and deploying a release · Reading deployment logs and diagnosing a failure · The dashboard: what is where, in which environment
Connecting Octopus to the systems you already run. Target types and when each applies, packaging an application so it is genuinely environment-agnostic, and wiring your existing build server to push packages and trigger releases so nobody creates them by hand.
Topics: Tentacle agents in listening and polling mode · SSH targets for Linux estates · Kubernetes and cloud targets · Accounts, credentials and machine roles · Packaging applications: what belongs in the artifact and what does not · External package repositories versus the built-in one · Build server integration: pushing packages and creating releases from CI · Triggering deployments automatically on a successful build
The exercise that actually settles the evaluation. Take one of your own applications and model it: environments, the deployment process step by step, the configuration that differs per environment, and the approval that has to happen before production. This is where fit or misfit becomes obvious.
Topics: Environments and the promotion path · Deployment process steps and the built-in step template library · Variables and scoping them to environments · Configuration file substitution and transforms · Sensitive variables and where secrets should live · Manual intervention and approval steps · Promoting the same release through environments · Rollback options and what they cost · A first look at lifecycles and channels — enough to plan for them
The capability that most evaluations discover late and most teams end up valuing first. Using the same engine to automate operational work — restarts, log collection, certificate rotation, database restores, scheduled housekeeping — with permissions and an audit trail instead of a shared administrator login.
Topics: Runbooks versus deployment processes · Converting a manual procedure into a runbook · Scheduled and triggered runbook runs · Parameterising runbooks with prompted variables · Delegating operations to support teams safely · Audit trail and who ran what, when · Runbooks against Kubernetes and cloud accounts · Runbooks as a low-risk way to introduce the tool
Turning a week of hands-on work into a decision someone can sign. Hosting choice, licensing and cost at your team size, security and access model, the rollout sequence that avoids a big-bang migration, and the success criteria that would make the pilot a yes or a no.
Topics: Octopus Cloud versus self-hosted: residency, network access, operational load · Licensing model and cost at your projected scale · Users, teams, roles and Spaces for separating environments or business units · Authentication integration and access control · Which application to migrate first and which to migrate last · Rollout sequence and coexistence with existing deployment scripts · Ownership: who runs the server and who owns the projects · Defining success criteria and a stop condition · What to learn next, and where the deeper curriculum goes
We rebuild the agenda around the tools you actually run.
Request a custom agendaProvision an instance, register a target, push a package and deploy it — then break it deliberately and diagnose the failure from the deployment log.
Register a Tentacle agent, an SSH target and a Kubernetes cluster, deploy to each, and record what differs in the deployment process for each.
Wire your existing build server to push a package and create a release, so a commit reaches a deployed environment without anyone opening the Octopus interface.
Model one real application with environment-scoped variables, configuration substitution and an approval step, then promote the same package through both environments.
Convert a real operational task into a runbook, parameterise it, and hand it to someone with no server access to run.
Bring the week together into a costed, sequenced pilot plan with hosting choice, ownership, success criteria and the conditions under which you would stop.
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
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.
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.
| 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.