Remote-first private corporate batches in SGT (UTC+8), onsite in Singapore 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 regional platform teams the way those teams are actually assessed: value-stream first, then the controls. Sessions build a delivery path where the approval, the artefact provenance, the infrastructure change and the production access are all recorded by the systems that perform them, and every module is demonstrated live against a running pipeline rather than described on a slide. Scheduling is arranged in SGT so an on-call engineer can attend without giving up a working day.
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 engineering for Singapore platform teams — evidence-producing pipelines, controlled change and regional release — 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 Singapore is booked as a travel engagement: two to three weeks' lead time fixes a date, the trainer flies in, and the client provides the room, network access and a screen while we bring the lab, the materials and the assessment. Live online is the default and runs in SGT (UTC+8), aligned to the local working day, or as half-day blocks when the cohort is on call. Quotes are issued in SGD with INR retained as the source price; purchase orders, vendor onboarding and supplier registration are completed before the first session rather than chased afterwards, and travel and accommodation for onsite delivery are itemised separately. Batch sizing runs 8 to 30 engineers, and the agenda is rebuilt from your own accounts, CI system and control requirements during a discovery call before day one.
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 operating model that puts the people who write a service and the people who keep it running on one team, with one backlog and one definition of done. In Singapore that model usually arrives with a constraint attached: much of the engineering that matters here sits inside licensed banks, insurers, payment institutions and the regional platform functions of multinationals, where a release is not finished when it is deployed. It is finished when the evidence of how it was approved, built and verified can be produced on request.
So DevOps in this market is less about adopting a toolchain and more about making the toolchain the system of record. The pipeline holds the approval. The artefact carries its own provenance. An infrastructure change is a reviewed commit rather than a console click. The audit trail becomes a by-product of delivery instead of something reconstructed from memory two quarters later.
The underlying practices are the familiar ones — version-control discipline, continuous integration, infrastructure as code, progressive delivery, observability and incident review. What changes is the standard they are held to: reproducibility, segregation of duties enforced inside the automation rather than beside it, and the ability to answer who changed what, when, and on whose authority without a human going hunting through chat history.
Engineering demand in Singapore is concentrated rather than broad. Regional headquarters, licensed financial institutions and the platform groups that run all of South-East Asia from one floor hire for a specific profile: someone who can automate delivery and then defend that automation to a technology-risk function.
Two pressures push the same way. Engineering headcount here is expensive, so automation is the only way a platform team of a dozen people supports product groups spread across four or five countries. And supervisory expectations around technology risk keep climbing, which means anything still done by hand eventually becomes a finding rather than an inefficiency.
The scarce skill is therefore not writing a pipeline. It is designing delivery so control objectives are met by construction — approvals recorded by the system that performs the change, environments rebuilt from code rather than restored from tribal knowledge, and production access that is time-bound, justified and logged. That is a design skill, and it is the one teams here struggle to hire.
Start from the value stream, not the tools. We map an existing path from commit to production, mark every point where a control depends on someone remembering to do something, and decide which of those belong in automation.
Topics: Value-stream mapping for an existing service · Control objectives expressed as pipeline behaviour · Where manual steps become audit findings · Segregation of duties inside automation · Evidence: what a reviewer will actually ask for · Choosing the first three things to automate
Branching that supports frequent release without losing accountability. Trunk-based development, protected branches, required reviews, signed commits and tags, and an emergency path that does not quietly bypass the record.
Topics: Trunk-based development with short-lived branches · Branch protection and required status checks · CODEOWNERS and review routing · Signed commits and signed tags · Emergency change without breaking the audit trail · Repository topology for a multi-country team
Continuous integration where the output is not just a binary but a defensible record. Reproducible builds, immutable identifiers, dependency manifests, SBOM generation, artefact signing and approval gates that are part of the pipeline rather than an email thread.
Topics: Reproducible builds and immutable build identifiers · Artefact repositories and retention policy · SBOM generation and dependency policy · Signing and verifying artefacts · Approval gates and four-eyes inside the pipeline · Promotion across environments without rebuild
Terraform for an estate that spans several accounts and a data boundary. Module design and versioning, remote state with locking, plan review as a change control, drift detection, and policy checks that run before apply rather than after incident.
Topics: Module design, versioning and a private registry · Remote state, locking and blast-radius separation · Plan output as the change record · Drift detection and reconciliation · Policy as code before apply · Multi-account structure and shared services
What runs in production and where it came from. Base-image policy, reproducible container builds, vulnerability scanning with a triage process that is not just a wall of CVEs, image signing, and admission rules that refuse anything unsigned.
Topics: Base-image policy and rebuild cadence · Multi-stage builds and image minimisation · Scanning and CVE triage that engineers will follow · Signing images and verifying at admission · Registry structure and promotion between registries · Runtime hardening defaults
Credentials handled as a lifecycle rather than a value in a file. Centralised secret storage, dynamic database credentials, key management backed by a hardware security module, break-glass procedure, and just-in-time production access with a review trail.
Topics: Centralised secrets and namespace design · Dynamic, short-lived database credentials · Workload identity instead of static keys · Key management and HSM-backed keys · Break-glass access and its evidence · Rotation without an outage
Telemetry designed for a rota that spans several countries. Metrics, logs and traces with consistent labelling, service level objectives derived from what users notice, error-budget policy, and alerting that respects working hours across the region.
Topics: Signal design: metrics, logs, traces and cardinality · Defining SLIs and SLOs from user-visible behaviour · Error-budget policy and release throttling · Alert routing across a multi-country rota · Dashboards for incident use rather than reporting · Cost of telemetry and retention choices
The operational end. Release calendars that fit a regional business, rehearsed failover between availability zones and regions, restore verification, and incident review that produces evidence instead of blame.
Topics: Release calendars and freeze handling · Zone and region failover design · Backup restoration as a tested procedure · Recovery objectives and how they are evidenced · Incident review and corrective-action tracking · Preparing for a technology-risk review
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild once, generate an SBOM, sign the artefact, attach the approval, then promote the same artefact through three environments and verify the signature at each hop.
Take one oversized Terraform state, decompose it into bounded workspaces with versioned modules, and add a pre-apply policy check that blocks a non-compliant resource.
Replace a long-lived key with workload identity and dynamic database credentials, then rotate the backing secret while the service stays up.
Instrument a service, define SLIs and an SLO, wire the error budget into the pipeline, and watch the release gate close when the budget burns.
Fail a service to a second region on a stopwatch, fail it back, and write the recovery evidence exactly as a reviewer would want to receive it.
Assemble the whole course into one delivery path for a real service: reviewed commit, signed artefact, policy-checked infrastructure, time-bound access and a rehearsed recovery.
Singapore engagements cluster in a narrow band of industries rather than spreading evenly: licensed banks and insurers, payment and digital-asset firms operating under supervisory technology-risk expectations, the regional technology functions of shipping, aviation and commodity trading businesses that run South-East Asia from one office, and government-linked technology organisations. The request is rarely an introduction to delivery practice. It is help making a pipeline that already exists defensible in front of an internal audit or a risk review.
The stack combinations repeat with recognisable regularity. Cloud accounts pinned to a Singapore data boundary, GitLab or Bitbucket more often than a single dominant CI vendor, Terraform for infrastructure with an approval workflow bolted on top, and Kubernetes adopted as the runtime for anything new while the regulated core stays on virtual machines. Teams are small and expensive — often eight to twenty engineers supporting product groups in Indonesia, Vietnam, Malaysia and the Philippines — so training has to leave behind artefacts the team can reuse, not just understanding. Batches are usually scheduled as two blocks of two days rather than a continuous week, because the same engineers hold the pager.
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.