Private corporate batches, live online cohorts and 1-on-1 mentoring in NGINX as web server, reverse proxy, load balancer and TLS terminator in 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 teaches NGINX around request flow rather than directive lists: how a request selects a server block and then a location, how contexts and directive inheritance actually resolve, and why most proxy defects are matching problems rather than syntax problems. The syllabus runs the full operational surface — reverse proxy and header handling, upstream load balancing with active and passive health checks, the caching subsystem read from real cache-control headers, rate limiting and authentication, TLS termination graded against a scanner, dynamic module builds and a WAF rule set — with every configuration demonstrated against running upstreams and inspected on the wire.
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 NGINX that means a trainer who has run it in production — NGINX as web server, reverse proxy, load balancer and TLS terminator in 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 NGINX batchNGINX is an open-source web server that also functions as a reverse proxy, load balancer, HTTP cache, TLS terminator and API gateway. Its defining characteristic is the concurrency model: instead of a process or thread per connection, NGINX runs a small number of worker processes, each driving an event loop that handles thousands of connections. That is why its memory use stays flat as connection counts climb, and why it became the standard answer for serving static content and fronting slower application servers.
Configuration is declarative and hierarchical. Directives live in nested contexts — main, events, http, server, location — and inherit downward, with specific rules about which directives are inherited and how they can be overridden. Request handling flows through a matching sequence: server block selection by listen address and server_name, then location matching by prefix, priority prefix and regular expression, with variables, rewrites, try_files and named locations shaping the rest. Most NGINX configuration bugs are really matching bugs, which is why understanding that sequence matters more than memorising directives.
Operationally, NGINX sits at the edge of almost everything. It proxies to upstream applications over HTTP, FastCGI, uWSGI and gRPC; balances across upstream pools with active and passive health checks and several distribution methods; caches responses according to HTTP cache-control semantics; enforces rate limits, connection limits, IP allow-lists and authentication; and terminates TLS with modern ciphers, OCSP stapling and automated certificates. It is also the data plane inside the Kubernetes Ingress NGINX controller, which means the same directives that configure a single host also generate the configuration for an entire cluster's ingress.
NGINX is the piece of infrastructure that sits in front of everything else, which makes it the piece where a misconfiguration is most expensive. A proxy that drops the original client address breaks rate limiting, allow-lists and audit trails everywhere downstream. A cache directive that ignores the upstream's cache-control serves stale or private data to the wrong users. A location block that matches in an unexpected order silently bypasses an authentication rule. None of these throw an error — the server starts, returns 200, and behaves wrongly.
At the same time the surface has grown. NGINX is no longer just the web server on a VM: it is the ingress controller in front of a Kubernetes cluster, the TLS termination point where certificate automation and OCSP live, the rate limiter protecting an API, and often the first place a WAF rule set is applied. Engineers are expected to reason about HTTP semantics — conditional requests, partial content, content negotiation, cache-control, keep-alive — because the proxy is where those semantics are actually enforced.
That combination is why NGINX shows up in almost every infrastructure, SRE and platform job specification, usually assumed rather than listed. The hiring gap is not people who can install it; it is people who can read a configuration and predict exactly which server block, which location and which upstream a request will reach, and who can prove a TLS configuration grades well and a cache is doing what the headers claim.
What NGINX is, where it sits, and how it differs from a process-per-connection server such as Apache. The master and worker process model and its event loop. Then installation properly: package manager, official repository, source build, and a lab environment on cloud infrastructure that the rest of the course runs against.
Topics: About NGINX and where it fits · NGINX versus Apache: concurrency models compared · Master and worker processes, the event loop · Installation methods: package manager, official repo, source · Launching lab infrastructure and installing NGINX · Service management, reload versus restart, and configuration testing · Server overview and the default site layout
You cannot configure a proxy correctly without knowing the protocol it speaks. Request methods and their semantics, conditional and partial requests, response status codes and what a proxy should return in each situation — all inspected on the wire rather than described.
Topics: Introduction to protocols and the HTTP request/response cycle · GET, partial GET and byte-range requests · Conditional GET, If-Modified-Since and ETag · POST, HEAD, OPTIONS and TRACE · The full request method set and safe versus idempotent methods · HTTP response status codes and correct proxy behaviour · Inspecting traffic with curl and browser tooling
The mental model that makes every other module easier. Configuration contexts and how they nest, directive types and which ones are inherited into child contexts, the include directive and file organisation, and the command-line options that let you test, reload and debug a configuration safely.
Topics: Understanding configuration terms and file structure · Configuration contexts: main, events, http, server, location · Understanding HTTP contexts and nesting · Inheritance and directive types · The include directive and configuration file organisation · NGINX command line options: test, reload, signal handling · Debugging a configuration that does not do what it reads like
The matching sequence where most NGINX defects live. Virtual host selection by listen and server_name, location matching order across prefix, priority prefix and regex, the variable set NGINX exposes, rewrites and redirects with their flags, and try_files with named locations for fallback handling.
Topics: Understanding server blocks and virtual hosts · Configuring multiple websites on one NGINX instance · Location blocks and the full matching order · Variables and where they come from · Rewrites and redirects, and the difference between them · try_files and named locations · Diagnosing a request that reached the wrong location
NGINX in front of something else. Proxy setup and the pass semantics that trip people on trailing slashes, forwarding the real client address with X-Real-IP and X-Forwarded-For, the Host header decision, proxy buffering and timeouts, and application protocols beyond HTTP — FastCGI for PHP, plus uWSGI and gRPC.
Topics: Overview of a reverse proxy and why it is used · Configuring NGINX as a reverse proxy · X-Real-IP and forwarding the original client address · The proxy host header and when to preserve it · Proxy buffering, timeouts and body size limits · PHP processing over FastCGI · Proxying to uWSGI and gRPC upstreams · Serving static assets alongside a proxied application
Distributing traffic across a pool and removing bad members from it. Upstream blocks, distribution methods including round-robin, weights, least-connections and hashing, the difference between passive and active health checks, the parameters that govern them, and session persistence when the application demands it.
Topics: Introduction to load balancers and their role · Implementing NGINX as a load balancer with upstream blocks · Traffic distribution: server weight and round-robin · Least-connections and hash-based methods · Understanding health checks · Active versus passive health checks · Health check parameters: fails, timeouts and recovery · Backup servers, slow start and draining a member
Caching done from the protocol rather than from guesswork. The HTTP caching model, every cache-control directive that matters and what each one instructs an intermediary to do, revalidation, the Expires and Date headers, keep-alive connections, and NGINX's own proxy and FastCGI cache with keys, zones, purging and stale-while-revalidate behaviour.
Topics: Introduction to HTTP caching and intermediaries · HTTP cache-control headers in detail · no-store, no-cache and must-revalidate · max-age, s-maxage and shared cache behaviour · If-Modified-Since and revalidation · The Expires and Date headers · Cache time analysis in the browser · Keep-alive connections and their effect · NGINX proxy_cache and FastCGI cache: keys, zones and purging
Serving files well and shipping fewer bytes. Static asset handling and the directives that affect it, gzip and the accept-encoding negotiation behind it, plus the other negotiation headers a proxy is expected to handle — content language, referrer and the quality factor that ranks client preferences.
Topics: Understanding static assets and how NGINX serves them · Headers and Expires for static content · Accept-Encoding and content negotiation · Getting started with gzip compression in NGINX · Compression levels, MIME types and what not to compress · The quality factor in negotiation headers · Accept-Language and Content-Language · The HTTP referrer and referrer-based rules
Tuning NGINX for the connection profile you actually have. Worker process and connection counts against available cores and file descriptors, buffer sizing for requests and proxied responses, the full timeout set and what each one protects against, keep-alive to both clients and upstreams, and HTTP/2 with server push.
Topics: Worker processes, worker connections and CPU affinity · File descriptor limits and OS-level tuning · Buffers for client requests and proxied responses · The timeout set: client, proxy, keepalive and send · Keep-alive to clients and to upstreams · HTTP/2 and its configuration · Server push and its practical value · Benchmarking a configuration change honestly
Enforcement at the edge, which is the only place it can be enforced consistently. IP allow-lists and deny rules, connection and request rate limiting with zones and bursts, basic authentication and the hashing behind it, digest authentication, and GeoIP-based decisions — plus what each of these does when the proxy is behind another proxy.
Topics: Allow-listing and IP-based access control · The limit_conn module and connection limiting · Request rate limiting with zones, bursts and delay · Basic authentication and its practical configuration · Understanding hashing for credential storage · Digest authentication and when it is worth it · GeoIP-based routing and blocking · Access control behind a CDN or upstream proxy
The cryptography module, taught so the configuration choices make sense. Asymmetric encryption and what a certificate actually asserts, plaintext versus encrypted protocols, the HTTPS handshake, NGINX TLS configuration and cipher selection, grading the result with a scanner, automated certificates with Let's Encrypt, and revocation through CRL and OCSP.
Topics: Asymmetric key encryption and certificate basics · Plain text versus encrypted protocols on the wire · Understanding the HTTPS protocol and handshake · NGINX TLS configuration: protocols, ciphers and session settings · Grading an SSL/TLS configuration and fixing what fails · Creating an HTTPS site with Let's Encrypt and automated renewal · CRL and OCSP, and OCSP stapling · Certificate revocation in practice · SSL termination and re-encryption to upstreams
The extension and observability surface. Access and error logs including custom formats suitable for machine parsing, then NGINX's modular architecture — compiling from source, building static modules into the binary, and building dynamic modules that load at runtime — and installing a web application firewall with custom responses on rule matches.
Topics: Access logs, log formats and custom access logging · Error logs, levels and what each one tells you · Shipping and analysing NGINX logs · The modular architecture of NGINX · Compiling NGINX from source · Building static modules into the binary · Building and loading dynamic modules · Installing and configuring a WAF on NGINX · WAF custom messages on rule matching patterns
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a configuration with overlapping prefix, priority-prefix and regex locations, predict where ten sample requests land, and verify every prediction from the access log.
Put NGINX in front of an application and prove the upstream receives the correct client address, host and protocol — then break it and observe what fails downstream.
Balance across three upstreams with active and passive health checks, remove one mid-test, and document the exact client impact and recovery time.
Configure proxy caching and demonstrate every cache state from response headers, then prove that authenticated responses are never stored.
Start from a deliberately weak TLS configuration, fix protocols, ciphers and stapling until a scanner grades it top, and automate certificate renewal.
Assemble a full edge: TLS termination, routing, load balancing with health checks, caching, rate limiting, WAF and structured logging — then load test and tune it.
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
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.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
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.
| 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.