Remote-first private corporate batches in ICT (UTC+7), onsite in Thailand by arrangement — taught by a practitioner who runs DevOps 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 DevOps for multi-site delivery: reproducible builds and artefact promotion to constrained locations, configuration and secret handling per site, image and registry design for links that are slow or occasionally absent, autoscaling and load rehearsal for campaign peaks, and runbooks written for the people who are actually on shift. Sessions are scheduled in ICT and every concept is demonstrated live against a working pipeline and a real cluster rather than a slide deck.
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 DevOps that means a trainer who has run it in production — delivery for plant floors, store networks and campaign-day retail — build once, ship to many sites, survive the peak — 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.
Onsite delivery in Thailand is booked with two to three weeks' lead time; travel to a plant or distribution site outside the capital is planned into the schedule rather than assumed, and the client provides the room, network access and a screen while the trainer brings the lab, materials and assessment. Live online is the default, scheduled in ICT (UTC+7), with a second sitting where operations staff work shifts. Quotes are issued in THB with INR retained as the source price, purchase orders and vendor registration are handled before day one, and applicable value-added tax is stated on the invoice. Batches run 8 to 30 engineers, and the agenda is rebuilt around your own site topology, container tooling and campaign calendar during a discovery call.
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 DevOps batchDevOps is the practice of shortening the distance between a change being written and that change running safely in front of users, with the same people accountable for both ends. Most Thai engagements put an unusual twist on that definition, because production is not one place. It is a central platform plus a long tail of sites — factories, distribution centres, branches and retail outlets — each running some of the same software on hardware nobody is standing next to.
That changes which practices matter. Building once and shipping the identical artefact to many sites matters more than deploying quickly to one. Bandwidth to a plant is finite, so image size, registry mirroring and offline promotion stop being optimisations and become design constraints. A rollback has to work when the person nearest the machine is an operator, not an engineer.
The second pattern is the campaign peak. Consumer platforms here plan their year around a handful of enormous sales events, so capacity work, load rehearsal and graceful degradation are recurring engineering commitments rather than one-off projects. DevOps in Thailand is therefore judged on two things: whether a release reaches every site identically, and whether the platform holds on the day the traffic arrives.
Thai industry is digitising at the operational edge rather than only in head office. Manufacturers are instrumenting lines and pushing data off the plant floor, retailers are running applications in stores instead of only in a data centre, and logistics operators are tracking movements in something close to real time. Each of those puts software into places with intermittent connectivity and no on-site engineer.
At the same time consumer platforms have concentrated an outsized share of annual revenue into a few campaign days, which converts capacity planning from an annual exercise into a rehearsed operational discipline with a hard deadline.
Both trends demand the same skills and neither is well served by generic training. Teams need people who can produce reproducible artefacts, distribute them to constrained sites, keep configuration and secrets straight across dozens of locations, rehearse a peak honestly, and write runbooks that a bilingual operations team can follow at two in the morning. Those are engineering practices, not tool features, which is why they transfer badly from vendor documentation.
Mapping delivery when production is distributed across a data centre and many locations. Which components move weekly, which move quarterly, what the site can be trusted to do unattended, and where the boundary between IT and operational technology sits.
Topics: Delivery mapping across central and site systems · Release cadence per component class · The IT and operational-technology boundary · Safety and production constraints on change · Site inventory and what you actually know about it · Choosing a first automation target
Branching that works when the same team ships central services and site software with different lifecycles. Release branches, version pairing between components, and tagging that lets you tell exactly what is running at a given location.
Topics: Repository layout for central and site components · Release branches and long-lived support versions · Version pairing between coupled components · Tagging and release notes that identify site builds · Small-team review practice · Handling a hotfix that must reach one site only
Artefact management for distribution rather than a single deploy target. Reproducible builds, artefact repositories, mirrors close to the sites, offline bundles, checksum and signature verification at the destination.
Topics: Reproducible builds and pinned dependencies · Artefact repositories and retention · Mirrors and pull-through caches · Offline bundles for disconnected transfer · Checksum and signature verification at the site · Promotion between environments without rebuild
Provisioning what you cannot walk up to. Terraform for the central estate, Ansible for site bootstrap and ongoing configuration, site templates with per-location variables, and recovery when a machine at a location has to be rebuilt from nothing.
Topics: Terraform for the central estate · Ansible for site bootstrap and configuration · Site templates and per-location variables · Bootstrapping a machine you cannot physically reach · Rebuild-from-nothing procedure · Configuration drift across a fleet of locations
Container practice tuned for constrained links. Image size and layer strategy, base-image standardisation, registry mirrors and pre-pull, resumable transfers, and what happens to a deployment when the connection drops halfway.
Topics: Image size, layers and build caching · Base-image standardisation across teams · Registry mirrors and pre-pull strategies · Resumable and scheduled image distribution · Deployment behaviour on link failure · Local storage and cleanup on constrained hosts
Preparing for the days that carry the year. Load modelling from real traffic shapes, autoscaling limits and warm capacity, queue back-pressure, graceful degradation, and a rehearsal calendar that finds the breaking point before the customers do.
Topics: Modelling load from historical traffic shapes · Autoscaling limits and warm pools · Queue back-pressure and shedding · Graceful degradation and feature toggles · Load rehearsal and game-day scheduling · Post-peak analysis and carry-forward actions
Handling customer and employee data properly under Thailand's personal-data regime. Keeping identifiers out of logs, masking in non-production, retention decided before collection, and access to production data as an audited exception.
Topics: Identifying personal data in logs and traces · Masking and synthetic data for non-production · Retention and deletion as a pipeline concern · Access to production data as an audited exception · Data flows across borders and vendors · Evidence for a data-protection review
Making the operational side work for the people actually on shift. Runbooks in Thai and English, alerts that distinguish an application failure from a dropped link, escalation between site staff and central engineering, and blameless review after an incident.
Topics: Runbooks as maintained assets, in two languages · Alerting that separates app failure from connectivity loss · Escalation between site and central teams · Handover between shifts · Incident review without blame · Tracking corrective actions to completion
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a signed artefact once, distribute it through a mirror to simulated site hosts, and verify at each destination that what arrived is what was built.
Destroy a configured site machine, then bring it back from code alone — bootstrap, configuration, secrets and workload — and time how long it takes.
Throttle and interrupt a network link, then make a container deployment complete anyway using pre-pull, mirrors and resumable transfer.
Model a campaign-day traffic shape, drive load until something fails, then add back-pressure and a degradation ladder and repeat until the failure is graceful.
Audit a live log stream for identifiers, implement masking at source, and produce a masked dataset suitable for a test environment.
Run a staged release to a central service and a fleet of sites, hit an injected failure at one location, roll it back, and write the review.
The Thai engagements that reach this practice come from a distinct set of industries: electronics and automotive component manufacturing with plants outside the capital, food and beverage production, retail chains and marketplaces, logistics and cold-chain operators, hospitality and travel platforms, and the technology functions of local banks. Very few of them look like a pure cloud-native software company, and the training request reflects that — it is usually about getting reliable delivery into places without an engineer, rather than about squeezing another minute out of a build.
Stacks combine accordingly. A central platform on a public cloud or in a Bangkok data centre, a fleet of small machines or lightweight clusters at plants and outlets, Windows still present on the operations side, and a mix of vendor-supplied line-of-business software that cannot be containerised beside newer services that can. Two constraints show up in almost every Thailand conversation: the link to a site is slower and less reliable than head office believes, and the year's revenue is concentrated into a few campaign days, which makes rehearsed capacity work a board-level concern. Teams also want documentation that a bilingual operations group can maintain after the batch ends.
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.
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.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
| 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.