Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Artifactory 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 Artifactory as tier-one infrastructure, because when it is unavailable every build in the organisation stops. Sessions start from repository layout across mixed package formats — Maven and Gradle beside Docker, Conan for C and C++ toolchains, Debian and RPM for images and generic repositories for vendor SDKs — because the naming convention becomes permanent the moment build scripts encode it. From there the syllabus covers resolution order through virtual repositories, remote caching and offline seeding for estates with no outbound route, permission targets and scoped tokens instead of shared credentials, build-info published from CI so a delivered binary can be traced to its commit and reproduced later, Xray watches and policies phased in without stopping every build in the first week, checksum-based storage with query-driven retention and capacity forecasting, and the availability work — clustering, replication and a restore that has actually been rehearsed.
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 Artifactory that means a trainer who has run it in production — binary repository management for Pune's ER&D deliverables and regulated build 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.
We deliver onsite across Hinjewadi, Hadapsar, Magarpatta, Talawade, Kharadi, Baner and Viman Nagar — you provide the room, a screen and network access to your own repository if we are working against it; we bring trainer, agenda, lab repositories, assessments and certificates. Sessions run 09:30 to 17:30 IST and are usually scheduled between release trains, because a repository migration lab is not something to run in a code-freeze week. For labs each team needs either a JFrog trial instance or a non-production Artifactory the group can break, plus a build tool the attendees already use so the examples are theirs; where the estate is air-gapped we run the same exercises against a locally hosted instance. Invoicing is in INR with GST against your purchase order from the Indian entity, and any travel outside the city is quoted separately from the training fee.
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 Artifactory batchArtifactory is JFrog's binary repository manager, and the most useful way to think about it in engineering-services work is as a boundary. On one side sit the builds your teams run; on the other sit the consumers — another programme, the customer who commissioned the work, a production cluster, an auditor asking what went into a release. Everything the product does is about making that boundary explicit and answerable: what was published, by which build, from which resolved dependencies, with which checksum, and who is entitled to take a copy.
Mechanically it offers three repository shapes and repeats them across every package format it supports. Local repositories hold what you publish. Remote repositories proxy and cache an upstream registry, so a dependency enters the estate once and is served from disk afterwards. Virtual repositories aggregate a set of both behind a single URL, which is what lets you rearrange the estate later without editing every build script in the organisation. The format coverage is what makes this practical for mixed engineering work: Maven and Gradle beside Docker, npm, PyPI, NuGet, Go and Helm, Conan for C and C++ toolchains, Debian and RPM for gateway and appliance images, and generic repositories for the vendor SDKs and cross-compilers that arrive as a zip file with no package manager at all.
Two design decisions carry most of the weight. Storage is checksum-addressed, so a binary is written once under its SHA and repositories hold metadata pointing at it — copying or promoting an artefact is a metadata operation, and ten repositories holding the same JAR still occupy one copy on disk. And build-info, published from the CI job, records the modules produced, the dependencies resolved and the environment that resolved them, which turns "can you reproduce the build we shipped in March" from an archaeology project into a query. Xray reads the same index and applies policy to whatever those repositories now contain.
In Pune the driver is contractual rather than architectural. Engineering-services and ER&D programmes across Hinjewadi, Hadapsar and Talawade deliver software as a commitment, and a customer receiving a build expects a versioned, checksummed binary with a dependency manifest attached — not a folder on a shared drive with a date in its name. That single expectation makes repository ownership part of the build-and-release job here, and it is why local postings name Artifactory beside Jenkins, Gradle and Maven rather than as a separate specialism.
The regulated captives around Kharadi, Yerwada and Magarpatta arrive at the same product from the opposite direction. Nothing in those estates may resolve directly from a public registry, so every dependency has to enter through a remote repository that caches it, records where it came from and lets a scanner have an opinion about it before a release reaches change approval. The work there is proxy configuration, exclusion patterns, offline seeding of new package formats and keeping a vulnerability database current with no outbound route.
Retention is the argument both groups end up having. A programme contractually obliged to keep a delivered build reproducible for several years collides with a storage budget that was set annually, and the resolution is technical: checksum deduplication, cleanup policies driven by query rather than by guesswork, garbage collection that actually reclaims space, and a forecast someone senior is willing to sign. That conversation is the reason most Pune batches get booked in the first place.
What the product is for, before what it does. The repository shapes and how they compose, the separation between database metadata, the binary filestore and application configuration, the deployment shapes teams actually run, and an honest note on where a simpler repository manager would serve the same purpose at a fraction of the cost.
Topics: Local, remote, virtual, federated and distribution repositories · Where database metadata, the filestore and configuration each live · Deployment options: archive, native package, Docker, Kubernetes via Helm · System requirements and honest initial sizing · Licence tiers and which capability each one unlocks · Upgrades, and the rehearsal an upgrade deserves before the real one · When Artifactory is more product than the estate needs
The decision that becomes permanent the moment build scripts encode it. A naming convention that survives new teams and new formats, layout for Maven and Gradle, Docker repositories and tag strategy, npm, PyPI, NuGet, Go and Helm — then the formats that dominate engineering work: Conan for C and C++ toolchains, Debian and RPM for images, and generic repositories for vendor SDKs and cross-compilers.
Topics: Naming conventions, and the real cost of renaming later · Maven and Gradle layouts, snapshot handling and release separation · Docker repositories, tagging strategy and immutable tags · npm, PyPI, NuGet, Go and Helm repositories · Conan repositories for C and C++ dependency management · Debian and RPM repositories for image and appliance builds · Generic repositories for vendor SDKs, cross-compilers and firmware images · Repository layouts and custom module descriptors · Separating development, staging and release repositories cleanly
How a build actually finds a dependency, and what happens when the internet is not an option. Virtual repository ordering and resolution precedence, remote caching and retrieval policies, offline mode, exclusion patterns that stop an internal package resolving from a public mirror, and seeding a brand-new package format into an isolated estate without a shortcut.
Topics: Virtual repositories: member ordering and resolution precedence · Remote repository caching, metadata timeouts and retrieval policies · Offline mode, and failing cleanly rather than silently · Include and exclude patterns; preventing dependency confusion · Seeding a new package format where there is no outbound route · Moving cached content between a connected and a disconnected estate · Diagnosing a resolution failure from the request log alone · Checksum policies and rejecting artefacts that cannot be verified
Where most rollouts quietly stall: getting a hundred developers and an entire CI fleet to resolve through the repository rather than around it. Configuration for each ecosystem, credentials that are not somebody's personal password, and the migration problem of build files that still name a public registry three years after the repository went in.
Topics: Maven settings.xml, mirrors, profiles and distributionManagement · Gradle init scripts and repository declarations · Docker and containerd configuration, login and registry access paths · npm, pip, NuGet and Go client configuration · Conan remotes and profiles · JFrog CLI configuration and the commands worth knowing · Rolling client configuration out across a team without breaking builds · Finding and fixing builds that still resolve straight from a public registry
Who may read, deploy, promote and delete, expressed so it survives an access review rather than an argument. Users, groups and directory integration, permission targets scoped by repository and path pattern, tokens against API keys against passwords, credentials inside pipelines, and the separation that keeps a customer-facing deliverable readable by exactly the right people.
Topics: Authentication realms and directory integration · Users, groups, and the case for assigning permissions to groups only · Permission targets: repositories, include and exclude patterns · Deploy, delete, annotate, manage — what each permission genuinely allows · Access tokens, scopes and expiry versus API keys and passwords · Credentials in CI pipelines, and rotating them without an outage · Anonymous access and the decisions it silently forces · Segregating a customer-facing repository from internal ones · Producing the audit trail an access review will ask for
The capability that separates this from a file server, and the reason most engineering-services teams book the batch. Publishing build-info from CI so artefacts, resolved dependencies and environment are recorded together, promoting a binary rather than rebuilding it, and reconstructing a delivered build long after the pipeline that produced it was rewritten.
Topics: What build-info captures, and how it gets published · JFrog CLI and CI plugin integration for build publication · Build browsing, comparison and dependency diff between two builds · Promotion between staging and release repositories · Properties as promotion state, and property-driven queries · Immutable release tags and preventing an overwrite · Reproducing a build from its recorded dependencies and environment · Attaching a dependency manifest or SBOM to a release · Build retention where a contract obliges you to keep it
Applying policy to what the repositories already contain. Indexing repositories and builds, watches and policies, severity and licence rules, violation triage and ignore rules that expire, choosing the pipeline stage that blocks, and keeping the vulnerability database current in an estate with no route to the internet.
Topics: Xray architecture, and what indexing actually does to a repository · Watches and policies, and assigning them to repositories and builds · Security rules, licence rules and severity thresholds · Fail-build behaviour and choosing which stage blocks · Violation triage, ignore rules and expiry dates · Component analysis and impact paths through a dependency tree · Exporting evidence: reports, SBOM and VEX documents · Offline database updates for a disconnected installation · Introducing scanning without stopping every build in the first week
The recurring argument between a contractual obligation to keep things and a storage budget that will not grow to match. Checksum deduplication and what it does and does not save, filestore configuration against disk or object storage, query-driven discovery of what nobody has downloaded, cleanup policies, garbage collection, and a forecast somebody will actually sign off.
Topics: Checksum-based storage: deduplication, free copies and honest sizing · Filestore configuration: local disk, mounted volume, S3 and other object stores · Migrating a populated filestore without losing an artefact · Artifactory Query Language for storage and usage questions · Finding artefacts never downloaded, and stale container tags · Cleanup policies, scheduled tasks and deletion that is safe to automate · Garbage collection, orphaned binaries and actually reclaiming space · Retention against a contractual obligation to reproduce a delivered build · Capacity forecasting and reporting storage consumption per team
Treating the repository as tier-one infrastructure, because every build in the organisation stops when it is down. Cluster architecture and node roles, load balancer behaviour, rolling upgrades, replication topologies between sites, Edge nodes for release distribution, and a disaster recovery position that has been tested rather than written down.
Topics: High-availability architecture and node roles · Cluster installation, shared storage and load balancer configuration · Rolling upgrades without interrupting builds · Push, pull, event-based and multi-push replication · Choosing a replication topology for more than one site · Bandwidth, scheduling and replicating very large binaries · Edge nodes, distribution repositories and signed release bundles · Federated repositories, and where they fit against replication · Disaster recovery: objective, written procedure, and a real test
Running the platform day to day without clicking through the interface. Configuration as code with system YAML and the REST API, scripted onboarding for a new team, backups and export and import, the logs and metrics worth alerting on, and a structured method for the failures that genuinely happen rather than the ones in the manual.
Topics: System YAML and configuration as code · REST API: repositories, users, permissions and artefacts · JFrog CLI for administration and bulk operations · Terraform provider for repository and permission provisioning · Backups, export and import, and a restore you have rehearsed · Log files, request log analysis and shipping logs to an external stack · Metrics and JMX beans worth alerting on · Diagnosing a slow or unresponsive instance under load · Self-service onboarding for a new team
We rebuild the agenda around the tools you actually run.
Request a custom agendaDesign and build a repository set covering Maven, Docker, npm, Conan, Debian and generic artefacts, publish into each, then prove one build resolves everything through a single virtual repository.
Bring a new package format into an estate with no outbound route: cache what is needed, carry it in, configure resolution and exclusion patterns, and prove a build completes without touching a public registry.
Model developer, release and pipeline identities as permission targets with path patterns, replace a stored credential with a scoped expiring token, and produce the evidence an access review asks for.
Publish build-info, promote a binary into a release repository, then rebuild from the recorded dependencies and environment and account for every difference between the two results.
Use AQL to locate artefacts nobody has downloaded and container tags nobody references, model the reclaimable space, apply a cleanup policy safely and forecast twelve months of growth.
Configure Xray watches and policies, phase enforcement across three repositories, work the first wave of violations with expiring exceptions, and update the vulnerability database with no internet access.
Pune's engineering-services and ER&D organisations ship software as a contractual deliverable, and that single fact decides what Artifactory is for here. When a team in Hinjewadi, Hadapsar or Talawade hands a build to the customer who commissioned it, the customer wants a versioned, checksummed, reproducible binary with a dependency manifest attached — not an archive on a shared drive. Artifactory becomes the handoff boundary, which means Pune engagements are unusually heavy on repository layout across mixed package types in one estate: Maven and Gradle for the tooling, generic and Conan repositories for cross-compilers and vendor SDKs, Debian and RPM for gateway images, and Docker for the build agents themselves.
The regulated captives around Kharadi, Yerwada and Magarpatta want the same product for the opposite reason. Nothing in those estates may pull directly from a public registry, so every dependency arrives through a remote repository that is cached, scanned and attributable, and Xray policy has to fail a build before a release reaches change approval rather than after. Retention is the recurring Pune headache in both groups — ER&D programmes are contractually obliged to keep a delivered build reproducible for years, which collides with storage budgets, so cleanup policy, binary deduplication and storage sizing get real time in the room. Local build-and-release postings name Artifactory beside Jenkins, Gradle and Maven, and repository ownership is treated as part of that role rather than 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
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
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.
| 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.