Private corporate batches, live online cohorts and 1-on-1 mentoring in Sonatype Nexus Repository — hosted, proxy and group repositories across Maven, npm, Docker, PyPI, NuGet and Helm — 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 Nexus around the repository model rather than the menu — how hosted, proxy and group repositories compose per format, how blob stores and content selectors decide where bytes actually live, and how a single group URL keeps build configuration stable while the estate behind it changes. Sessions run live across Maven, npm, Docker, NuGet, PyPI, Helm, RubyGems, Composer, Git LFS and raw repositories, then move into the parts teams get wrong: realm ordering across LDAP, SAML, Crowd and token realms, privilege and role design, cleanup policies and scheduled tasks, backup of the databases and blob stores, upgrades, high-availability clustering, and driving the whole thing from the REST API and webhooks.
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 Nexus that means a trainer who has run it in production — Sonatype Nexus Repository — hosted, proxy and group repositories across Maven, npm, Docker, PyPI, NuGet and Helm — 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 Nexus batchNexus is Sonatype's repository manager: the server that sits between your builds and the public internet, holding every binary your organisation consumes and every binary it produces. Sonatype Nexus Repository stores artifacts in blob stores and exposes them through repositories of three kinds — hosted repositories for things you publish, proxy repositories that cache a remote registry, and group repositories that present several of the others behind a single URL a build can point at.
That three-shape model is the whole design, and it repeats across every format Nexus supports. Maven, npm, Docker, NuGet, PyPI, RubyGems, Helm, Composer, Git LFS and raw all work the same way: proxy the upstream, host your own, group them, and give the build one endpoint. A developer changes one line in settings.xml or .npmrc and every dependency now arrives through a server you control, log and can take offline.
What that buys is more than a cache. Builds stop failing because a public registry had a bad day. Dependencies become auditable, because everything that entered the build passed through one place. Storage is bounded, because cleanup policies and scheduled tasks remove what is no longer referenced instead of letting a disk fill silently. And access becomes something you can actually reason about: Nexus authenticates against a stack of pluggable realms — local, LDAP, SAML, Crowd, Docker bearer token, npm bearer token, NuGet API key and user tokens — and authorises through privileges rolled up into roles.
Supply-chain security turned the repository manager from convenience infrastructure into a control point. Once regulators, customers and security teams started asking which third-party components entered a build and where they came from, an organisation that pulls straight from public registries has no answer. One that routes every fetch through a repository manager does.
The operational case is just as direct. Build reliability, bandwidth cost, and the ability to keep building when an upstream registry is unreachable are all decided by whether a proxy layer exists. So is storage cost — most self-hosted repository estates grow until someone runs out of disk, and the fix is cleanup policies and blob store compaction that nobody configured on day one.
Skills demand follows the polyglot reality. A single organisation now publishes Java artifacts, container images, npm packages, Python wheels and Helm charts, and expects all of them to live in one managed place with consistent authentication. Standing that up, wiring the realms to a corporate directory, designing roles that survive an audit, and keeping the thing running through upgrades and a high-availability migration is a specific and hireable skill.
The problem before the product. Why builds that fetch straight from public registries are unreliable and unauditable, what a repository manager changes, and an honest comparison of Nexus against Artifactory and Archiva — including the cases where Nexus is not the right answer.
Topics: Understanding package management · What Sonatype Nexus Repository is · Why an organisation needs a repository manager · Nexus vs Artifactory vs Archiva · Repository manager concepts · Repositories and blob stores · Nexus repository types: hosted, proxy and group
Getting a working instance: system requirements, the directory split between the application and the data store, JVM sizing, running as a service, and the first pass through the administration interface — because nearly every later topic is a screen in it.
Topics: System requirements and JVM sizing · Installing Sonatype Nexus Repository · Application directory versus data directory · Running Nexus as a service and behind a reverse proxy · The Nexus user interface and administration menu · Email server configuration · Anonymous access and the first security decision
Nexus authenticates through an ordered stack of realms, and realm order is the single most common source of confusing login behaviour. What each realm is for, when a format needs its own token realm, and how to connect to a corporate directory without locking yourself out.
Topics: How the realm stack is evaluated · Local authenticating and local authorizing realms · LDAP realm and directory mapping · SAML realm for single sign-on · Crowd realm · Docker Bearer Token realm · npm Bearer Token realm · NuGet API-Key realm · Rut Auth realm · User Token realm and why CI should use tokens
The model that decides who can read, deploy and delete. Privileges are fine-grained and numerous; roles compose them; content selectors narrow access to paths within a repository. Getting this right early is far cheaper than retrofitting it after an audit finding.
Topics: Nexus authorisation model · Privileges and privilege types · Roles, nested roles and external role mapping · Users, local and external · Content selectors for path-level access · Read, browse, add and delete semantics · Auditing effective permissions for a user
The format Nexus was built for, and still the one with the most subtlety. Release versus snapshot repositories, deployment policies, the group that fronts them, and the client side — settings.xml, server credentials, mirrors and the distributionManagement block that decides where an artifact lands.
Topics: Working with Maven repositories in Sonatype Nexus · Hosted release and snapshot repositories · Proxying Maven Central and other remotes · Group repositories and member ordering · settings.xml, mirrors and server credentials · distributionManagement and mvn deploy · Snapshot retention and rebuild behaviour
The three formats that expose most of Nexus's rough edges. Docker needs its own connector port or a path-based reverse proxy and a bearer token realm; npm needs scope handling and .npmrc credentials; NuGet needs an API key. Each is straightforward once the pattern is clear, and each fails in its own characteristic way.
Topics: Docker repositories: hosted, proxy and group · Docker connectors, ports and reverse proxy path routing · docker login, push and pull against Nexus · npm repositories and scoped packages · .npmrc configuration and publish credentials · NuGet repositories and API key handling · Format-specific troubleshooting patterns
The formats teams adopt as their stack widens. Each follows the same hosted-proxy-group pattern, and the value of covering them together is seeing that pattern hold — plus the client configuration each ecosystem expects.
Topics: PyPI repositories and pip index configuration · Helm repositories for chart distribution · RubyGems repositories · Composer repositories for PHP · Git LFS repositories · Raw repositories for anything with no native format · Choosing between a native format and a raw repository
The module that saves the most money. Nexus does not reclaim space by itself: cleanup policies mark content, scheduled tasks delete it, and blob store compaction actually returns the disk. Skipping this is why repository estates end their lives as an emergency disk expansion.
Topics: Cleanup policies and their criteria · Applying cleanup policies to repositories · Scheduled tasks: compact blob store, purge unused components, rebuild indexes · Blob store sizing and separation by repository · Capacity planning and growth monitoring · Safely removing components without breaking reproducible builds
Continuity. A repository manager holds artifacts that builds are reproducible against, so losing it is worse than losing a build server. Preparing a backup, running it as a task, restoring exported databases, upgrading across versions, and what a high-availability cluster does and does not give you.
Topics: Preparing a Nexus backup · Configuring and running the backup task · Restoring exported databases · Backing up blob stores alongside metadata · Upgrading Sonatype Nexus across versions · High availability clustering and its licence requirements · Verifying a restore rather than assuming it
Treating the repository manager as infrastructure rather than a website. Provisioning repositories and roles through the API, reacting to events with webhooks, extending with plugins, and wiring builds so publishing and resolving happen with credentials that are safe in a pipeline.
Topics: Nexus REST and integration API · Scripted provisioning of repositories, roles and users · Webhooks and event-driven automation · Nexus plugins and extension points · Integration with Jenkins and TeamCity · Publishing from CI with user tokens rather than passwords · Promotion between staging and release repositories
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild proxy, hosted and group repositories for Maven and point a real build at the group, then change the members behind it without touching the build.
Connect Nexus to a directory, map external groups to roles, then issue a user token so a pipeline authenticates without a human password.
Stand up hosted, proxy and group Docker repositories, wire connectors through a reverse proxy with TLS, and push and pull real images.
Serve npm, PyPI, NuGet, Helm and raw content from the same instance and configure each client to resolve through it.
Take an instance with runaway snapshot growth, write cleanup policies, run the purge and compaction tasks, and measure the disk actually returned.
Back up databases and blob stores, destroy the instance, restore it, then upgrade across a version boundary and verify every published artifact still resolves.
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
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.
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.
| 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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.