Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Nexus 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 three-shape repository model and the two things that decide whether an instance survives contact with a real estate: where the bytes live, and who is allowed to move them. Sessions run live across Maven, Gradle, Docker, npm, NuGet, PyPI, Helm, Git LFS and raw repositories, then continue past where most courses stop — blob store separation and capacity forecasting, cleanup policies against the cleanup and compaction tasks and the difference between marking content and reclaiming disk, realm ordering across LDAP, SAML, Crowd and the per-format token realms, privileges, roles and content selectors, staging and promotion, IQ Server and Repository Firewall as a build-time gate rather than a report, backup with a verified restore, upgrades, high-availability clustering and its licence boundary, and driving the whole thing through the REST API instead of the administration screens. Two decades of hands-on delivery in DevOps, SRE and security roles sit behind that syllabus, together with a teaching record of more than 10,000 engineers.
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 operations for Pune's air-gapped and cost-conscious estates — 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 covers Kharadi, Hinjewadi, Baner, Balewadi, Magarpatta, Yerwada and Viman Nagar; you provide the room, a screen and network, we bring trainer, agenda, lab material, assessments and certificates. Hours are 09:30 to 17:30 IST, and this batch is best booked outside a release window, because the storage, cleanup-task and blob-store labs are the ones that make people want to change production the same week. For labs each group needs one virtual machine with a few tens of gigabytes of disk to run its own instance — that is genuinely all Nexus needs — plus a build tool the attendees already use so resolution behaviour is theirs rather than a sample project's. Where your estate is air-gapped we stage the package formats and any licensed extension in advance so nothing in the session waits on an outbound fetch. Invoicing is in INR with GST against your purchase order from the Indian entity.
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, and in most Pune engineering organisations it arrived the same way: one virtual machine, one proxy repository sitting in front of a public Java registry, stood up in an afternoon to stop builds failing whenever the internet did. Everything after that was accretion — a hosted repository for internal libraries, a container registry, an npm group, a raw repository somebody used for installers — and none of it revisited the decisions taken on that first afternoon. Which is why a Nexus batch is normally booked to repair something rather than to install something.
The design underneath the sprawl is simpler than the sprawl suggests. Bytes live in blob stores. Repositories expose them in three shapes: hosted for what you publish, proxy for what you cache from an upstream, and group for a single URL that fronts several of the others so a build's configuration never has to change again. That pattern repeats identically across Maven, npm, Docker, NuGet, PyPI, RubyGems, Helm, Composer, Git LFS and raw, which is why learning one format properly teaches most of the rest.
Two consequences decide whether an installation stays healthy. The first is storage: Nexus does not free disk on its own, so without cleanup policies, the cleanup and compaction tasks, and a deliberate blob store layout, the disk fills and the fix becomes an emergency on a build-blocking server. The second is access: authentication runs through an ordered stack of realms — local, LDAP, SAML, Crowd, Docker bearer token, npm bearer token, NuGet API key, user token — and authorisation through privileges rolled into roles and narrowed by content selectors. On an estate with no outbound path at all that is not administrative detail, because the repository is the single door every dependency comes through, and the routing rules and the role model are the control.
Two things are driving Nexus work in Pune, and neither of them is a new installation. The first is storage economics. Mid-size product estates around Baner, Balewadi and Viman Nagar are running instances sized years ago against a fraction of today's snapshot volume and container image churn, and the recurring emergency is a full disk on a server that blocks every build when it stops. The fix is unglamorous and entirely learnable: separate blob stores, cleanup policies written per format, the cleanup and compaction tasks scheduled rather than run in a panic, retention that keeps releases while letting snapshots expire, and a usage threshold wired into whatever monitoring the team already runs so the trend is visible months before it becomes an incident.
The second is provenance. Customers and auditors now ask which third-party components entered a build and where they came from, and an organisation resolving straight from public registries has no answer to give. Routing every fetch through one repository manager produces that answer as a by-product, and adding policy — IQ Server and Repository Firewall — converts it from a report written after release into a gate that stops a vulnerable component before a build ever sees it. The practical work is a bill of materials somebody will actually read, a triage and remediation route for the findings, and an exception workflow with an owner and an expiry rather than a permanent waiver.
For the regulated captives with no outbound internet, the same skills are simply mandatory rather than advisable. Every format has to be proxied or seeded offline, group ordering has to make resolution predictable, staging and promotion have to make a release deliberate, and backup and high availability matter more here than anywhere else, because the moment the repository is unavailable every build in the estate stops at once.
Start with the estate rather than the product. Trace what one real build actually fetches, from where, over which network path, and what happens to it when the upstream is unreachable or the disk is full. Then repository manager concepts, the hosted, proxy and group model, blob stores as the storage layer beneath it, and an honest comparison against Artifactory and Archiva for a single-site estate.
Topics: Package management and how a build resolves its dependencies · What a repository manager changes: reliability, provenance, bandwidth · Repositories, components, assets and blob stores · Hosted, proxy and group repository types · Nexus, Artifactory and Archiva compared against a stated requirement list · Free edition versus licensed features, and where the boundary matters · Bandwidth, egress charges and the argument for caching close to the builders · Who owns the repository: the platform team, the build team, or nobody · Consolidating two or three repository managers, and decommissioning the ones that lose · Reading an existing installation: what grew, what nobody owns
Nexus genuinely runs on one machine, which is both its appeal and the reason estates outgrow it without noticing. Installation, the split between application directory and data directory, heap and direct memory sizing, running it as a service behind a reverse proxy with TLS, and the first security decisions — anonymous access, the initial credential, and the base URL that half the later problems trace back to.
Topics: System requirements, heap and direct memory sizing · The Java runtime support matrix, and choosing a version that stays supported · Installation, and the application versus data directory split · The systemd unit, umask and file ownership for the service account · Running as a service, file descriptors and process limits · Reverse proxy, TLS termination and the base URL setting · Anonymous access and the initial administrative credential · Email server configuration and task notifications · Where the logs are, and what they say when startup fails
The layout decisions everything downstream inherits. Creating each repository type, ordering group members so resolution is predictable, routing rules that stop internal coordinates leaking to an upstream proxy, negative cache and auto-blocking behaviour, and the offline case: seeding a format with no outbound path and keeping a proxy usable when its remote is permanently unreachable.
Topics: Creating hosted, proxy and group repositories · Group member ordering, and why order decides resolution · Routing rules and blocking coordinate leakage to an upstream · Proxy remote settings: timeouts, negative cache, auto-blocking · Running a proxy with no outbound route, and seeding content offline · Online, offline and read-only repository states · Repository health checks and remote availability signals · Ordering when two teams publish the same coordinate into different repositories · Naming conventions that survive a second team joining the instance · One stable URL per format, so the build never changes again
The format with the most subtlety and the most disk consumption. Release and snapshot repositories and the deployment policies that separate them, the group that fronts them, and the client side — settings.xml mirrors and server credentials, Gradle repository and publishing declarations, distributionManagement, and the snapshot timestamping behaviour that quietly produces most of the storage growth people complain about later.
Topics: Release and snapshot hosted repositories, and deployment policies · Proxying a public Java registry and other remotes · settings.xml: mirrors, servers, profiles and credential handling · Gradle repository declarations and publishing configuration · distributionManagement and mvn deploy · Snapshot timestamping, rebuild behaviour and storage growth · Classifier attachments: sources, javadoc and test jars, and whether you keep them · Reproducibility: pinning plugin versions as well as dependency versions · Diagnosing a resolution failure from the request log
The same three-shape pattern applied to the formats that expose the rough edges. Docker wants its own connector port or path routing through the reverse proxy, plus a bearer token realm. npm wants scoped package handling and credentials in the right client file. NuGet wants an API key and nothing else. Then PyPI, Helm, RubyGems, Composer, Git LFS and raw, each with the client configuration its own ecosystem expects.
Topics: Docker hosted, proxy and group repositories · Docker connectors, ports, path routing and the bearer token realm · docker login, push and pull against Nexus over TLS · npm repositories, scoped packages and .npmrc credentials · NuGet repositories and API key handling · PyPI index configuration and Helm chart repositories · Multi-architecture image manifests, and what the instance stores for them · Untagged image layers, and the corner of the disk where they accumulate · RubyGems, Composer, Git LFS and raw repositories · Choosing a native format over a raw repository, and when not to
Where the bytes actually are. File and object blob stores and their trade-offs, blob store groups and fill policies, separating stores by repository so one runaway format cannot take the whole instance down, soft quotas, and measuring the real growth rate instead of guessing at it. This is the module that decides whether the disk emergency happens a second time.
Topics: File blob stores, object storage blob stores and the trade-offs · Blob store groups and fill policies · Separating blob stores by repository, format or team · Soft quotas and monitoring blob store usage · How components, assets and blobs relate to actual disk usage · Filesystem choice, inode pressure and free-space thresholds · S3-compatible object storage as a blob store, and its latency profile · Monitoring usage with Prometheus and Grafana, and alerting on headroom rather than on failure · Setting a usage threshold and tracking the growth trend month by month · Measuring growth per format and forecasting capacity · Moving a repository to a different blob store safely
Deleting content in Nexus is a three-step process and most teams configure one step of it. Cleanup policies mark components by criteria, the cleanup task removes them, and blob store compaction returns the space to the file system. The module works through each step on an instance deliberately overgrown with snapshots and untagged images, then measures how much disk actually came back.
Topics: Cleanup policy criteria: last downloaded, last updated, release type, asset name · Applying policies per repository and per format · Scheduled tasks: cleanup, compact blob store, purge unused components, rebuild index · Task scheduling windows and their effect on a live instance · Marking versus reclaiming, and why the disk did not shrink · Orphaned assets, stale uploads and duplicate content, and the footprint each leaves · Dry-run previews before a destructive task is allowed to run · Task concurrency, and what competes for throughput with a nightly build · Retention that keeps releases while letting snapshots expire · Removing content without breaking reproducible builds
Nexus evaluates an ordered stack of realms, and realm order is the most common cause of login behaviour nobody can explain. What each realm is for, connecting to a corporate directory without locking yourself out, per-format token realms for automated clients, and then the authorisation side: privileges rolled into roles, external group mapping, and content selectors that limit access to paths inside a repository.
Topics: Realm ordering, and how a login is evaluated against the stack · Local authenticating and local authorizing realms · LDAP realm, group mapping and connection troubleshooting · SAML and Crowd realms · Docker bearer token, npm bearer token, NuGet API key and Rut Auth realms · User tokens for CI instead of stored passwords · Privileges, roles, nested roles and external role mapping · Content selectors for path-level access across teams and vendors · Anonymous access: when it is convenient, and when it becomes an audit finding · Locking yourself out of the instance, and the documented way back in · Auditing the effective permissions of a single account
Making a release deliberate, and stopping a bad component earlier than the release note. Staging repositories and promotion between them, then Sonatype policy: IQ Server applications and policy definitions, evaluating a build, the difference between reporting a vulnerable component and refusing it, and Repository Firewall quarantining a component at the proxy before it ever reaches a build.
Topics: Staging repositories and the promotion model · Release candidates, promotion criteria and rollback · IQ Server: organisations, applications and policy definitions · Evaluating a build and reading a policy violation report · Policy actions — warn and fail — and the pipeline stage each applies at · Repository Firewall: quarantine at the proxy, and release from quarantine · Licence policy alongside security policy · Component allow lists for an estate that cannot reach a public advisory feed · Software bill of materials output, and what a customer actually asks to be sent · CVE severity, triage, and a remediation deadline the delivery team has agreed to · An exception approval workflow with a named owner and an expiry date · Waivers that expire instead of quietly becoming permanent · Setting a policy a delivery team can live with rather than route around
Continuity and operations for a service whose outage stops every build at the same moment. Preparing and scheduling a backup, restoring exported databases alongside their blob stores, proving the restore worked instead of trusting that it did, upgrade paths and rehearsal, what high-availability clustering does and does not provide under its licence, and provisioning repositories, roles and tasks through the REST API instead of by clicking.
Topics: Preparing a backup and configuring the backup task · Restoring exported databases with the matching blob stores · Verifying a restore by resolving a real dependency from the rebuilt instance · Volume snapshots of the underlying disk versus a genuine repository backup · Checksum verification, and detecting blob corruption before a restore depends on it · Export and import when moving an instance between hosts · Rehearsing the restore on a schedule rather than once at go-live · Upgrade paths: freeze window, parallel run, cutover and the rollback baseline · High availability clustering, its licence requirements and its limits · Read-only mode during maintenance and planned migrations · Load balancer health checks, and keeping a cold standby worth switching to · Disaster recovery for a single-instance estate · REST and integration API: scripted provisioning of repositories, roles and users · Webhooks and event-driven automation · Jenkins and TeamCity integration, publishing with tokens rather than passwords
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild proxy, hosted and group repositories for one format, point a real build at the group, then swap the members behind it and show the build never noticed.
Seed the formats one application needs, add routing rules, then block the outbound path entirely and prove every dependency still resolves through the instance.
Take an instance overgrown with snapshots and untagged images, write cleanup policies, run the cleanup and compaction tasks, and measure the space actually reclaimed.
Connect to a directory, map groups to roles, narrow one repository with a content selector, then move a pipeline from a stored password onto a user token.
Configure policy that quarantines a known-vulnerable component at the proxy, fail a build on it deliberately, then run the documented exception path end to end.
Back up databases and blob stores, destroy the instance, restore it, upgrade across a version boundary, and prove every published artifact still resolves.
Nexus is the incumbent repository manager across a large slice of Pune's mid-size engineering organisations, and the reason is prosaic rather than architectural: it starts free, it runs on a single virtual machine, and it handles Maven, npm, PyPI, NuGet, Docker and raw formats without a per-seat conversation. Product firms and independent software vendors around Baner, Balewadi, Kalyani Nagar and Viman Nagar typically stood one up years ago as a proxy for a public Java registry, then bolted on hosted repositories for internal libraries, a container registry and a package group without ever revisiting blob store layout, cleanup policies or the scheduled tasks that stop the disk filling. Repairing exactly that is what most Pune batches are actually booked to do.
The other Pune population is the regulated captive around Kharadi, Yerwada and Magarpatta, where the estate has no outbound internet at all and Nexus is the single door every dependency comes through. There the curriculum becomes routing rules and repository groups, staging and release promotion, seeding a new package format offline, LDAP-backed roles and privileges, tokens for automated builds, and policy that blocks a vulnerable component before it reaches a build rather than reporting it afterwards. High availability and backup matter more in that group too, because a repository outage stops every build in the estate at once. Locally, Nexus appears in build-and-release postings beside an automation server and a JVM build tool, and repository ownership is treated as part of that role rather than as a separate job.
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
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.
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.
| 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.