Private corporate batches delivered onsite across Bangalore, 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 shared production infrastructure: repository naming and layout you can still live with in three years, permission targets and access tokens scoped for CI rather than for people, AQL and cleanup policies that keep storage bounded, replication topologies including Edge and multi-push, and BuildInfo captured through the JFrog CLI so promotion and traceability become queries. Sessions run against a live instance — including the failure paths, from a stalled remote cache to a replication backlog and a filestore migration to object storage.
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 — JFrog Artifactory for Bangalore build platforms — repository layout, permission targets, replication to parent sites, storage control and Xray gating — 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 at your own office. Most Artifactory engagements in Bangalore land at sites in Whitefield, along the Outer Ring Road between Bellandur and Marathahalli, at Manyata Tech Park or Bagmane Tech Park, and we keep one site per day so peak-hour crossings do not eat lab time. You provide the room, a screen and outbound access to your instance or a lab instance; we bring the trainer, agenda, lab repositories and the assessment. Because a repository manager is shared infrastructure, we normally ask for a non-production instance or a licensed trial rather than touching your live server during the session. Sessions run in IST (UTC+5:30), and a 09:30 to 17:00 shape works for teams that hand over to US counterparts later in the day. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement needs one; travel within Bangalore is included in the quote.
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 repository manager, and once it is installed the work stops being about installation and starts being about layout. Every package type resolves through the same three shapes — local repositories for what you publish, remote repositories that proxy and cache an upstream, virtual repositories that present a set of them behind one URL — and the naming convention you choose for those repositories is effectively permanent, because build scripts, Docker daemons and package manager configuration files across the organisation will encode it.
Underneath, Artifactory separates three things that people often assume are one. The database holds metadata. The filestore holds binaries, addressed by checksum, and can be local disk, a mounted volume or object storage configured in binarystore.xml. The application layer holds configuration, permissions and scheduled work. Understanding that separation is what makes backup, restore, migration to object storage and capacity planning tractable rather than terrifying.
Operating it well means learning the parts that do not appear in a quick-start. Permission targets, which grant repository and path patterns to groups rather than to people. AQL, the query language that answers questions like which artifacts have not been downloaded in six months. Cleanup policies and scheduled tasks, without which storage grows until someone escalates. Replication — push, pull, event-based and multi-push — for organisations with more than one site. Access tokens and their scoping, for CI systems that should not hold a human's credentials. And BuildInfo, published by the JFrog CLI or a CI plugin, which is what turns a promotion decision into a query instead of an argument.
Software supply chain expectations changed faster than most build platforms did. Customers, auditors and increasingly regulators now ask which components went into a release, where they came from, what licences they carry and whether the exact binary in production is the one that passed the pipeline. Answering that requires a repository manager that was configured deliberately, not one that grew a repository per team over eight years.
At the same time, build platforms have become genuinely large. A repository manager holding several terabytes across dozens of package types, serving thousands of resolutions an hour, and replicating between sites is a distributed system with its own failure modes — cache misses that stall a release, replication that silently falls behind, a filestore that fills on a Friday.
So the skill in demand is not 'can you upload a JAR'. It is repository layout that survives reorganisation, permission models that survive an audit, storage that stays bounded, replication topologies that behave sensibly when a link drops, and scanning policies that block a genuinely dangerous dependency without blocking everyone's Tuesday. Those are engineering decisions, and they are made once.
What Artifactory actually consists of and why the split matters: database, filestore and application configuration. Deployment shapes from a single node to high availability, licence tiers, and the sizing conversation that precedes any of it.
Topics: Database, filestore and configuration as three separate concerns · binarystore.xml and filestore options including S3 and mounted volumes · Single node, high availability and the node roles · Licence tiers and what each unlocks · System YAML configuration and upgrade path · Sizing: resolutions per hour, storage growth and network
Local, remote and virtual repositories across the package types that actually appear together — Maven, Gradle, Docker, npm, PyPI, NuGet, Go, Helm, Debian, RPM and generic. Then the part teams get wrong: naming conventions, resolution order in a virtual repository and include/exclude patterns.
Topics: Local, remote and virtual repositories and how resolution flows · Naming conventions that encode type, maturity and team · Ordering inside a virtual repository and why order changes results · Include and exclude patterns · Generic and raw repositories for toolchains and large binaries · Repository layouts and custom layouts
Who can read, deploy, delete and annotate what. Users, groups and permission targets over repository and path patterns; then authentication against LDAP or SAML, and access tokens scoped for machines rather than shared API keys borrowed from a person.
Topics: Users, groups and permission targets over path patterns · Deploy, delete, annotate and manage privileges in practice · LDAP, SAML and SSO integration · Access tokens: scope, expiry, refresh and revocation · Anonymous access and what it quietly enables · Auditing who deployed what
The operational work that keeps a repository manager from becoming a disk problem. Checksum-based storage and deduplication, AQL for asking real questions of the estate, retention and cleanup policies, and the scheduled tasks that reclaim space safely.
Topics: Checksum storage, deduplication and what a copy really costs · AQL syntax: domains, criteria and output fields · Finding unused artifacts, oversized repositories and orphaned binaries · Cleanup policies and retention by download date or build · Garbage collection and storage reclamation · Reporting storage growth to whoever approves the budget
Turning a pile of binaries into a traceable release. The JFrog CLI and CI integrations that publish BuildInfo, the dependency and environment data captured with it, build promotion between repositories, and the queries that answer what went into a given image.
Topics: JFrog CLI configuration, build-collect-env and build-publish · BuildInfo contents: modules, dependencies, environment, VCS revision · Promotion between maturity repositories as a metadata operation · Build retention and discarding old builds · Integration with Jenkins, GitHub Actions and GitLab CI · Answering 'which build produced this artifact' as a query
Designing for more than one site. Push, pull, event-based and multi-push replication; Edge nodes for distribution; what replication does not guarantee; and how a build behaves when the far end is unreachable or hours behind.
Topics: Push versus pull replication and when each is correct · Event-based and scheduled replication · Multi-push topologies and conflict behaviour · Edge nodes and distribution · Monitoring replication lag and detecting silent backlog · Failure behaviour: cache misses, timeouts and build impact
Scanning as a control rather than a report. Indexing repositories and builds, vulnerability and licence policies, watches and their scope, the difference between failing a build and warning, and how to introduce gating without stopping everyone's work on day one.
Topics: Indexing repositories, builds and release bundles · Policies: security rules, licence rules and severity thresholds · Watches, scope and assigning policies to what matters · Blocking download versus failing a build · Ignore rules, exceptions and keeping them honest · Producing evidence an auditor accepts
Running it for years. Backup that is provably restorable, upgrade planning across licence tiers, migrating a filestore to object storage, log analysis, and the common failures — full disk, stale remote cache, replication backlog, slow resolution.
Topics: Full and incremental backup, and testing a restore · Upgrade planning and rollback · Filestore migration to S3 or another object store · Request, traffic and access logs · Diagnosing slow resolution and remote repository timeouts · System health, metrics and alerting
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild local, remote and virtual repositories for Maven, npm, Docker and generic toolchains, with a naming convention and resolution order you can defend.
Model permission targets over path patterns for three teams on one Docker repository, then replace a shared CI credential with a scoped access token.
Write AQL to find artifacts nobody has downloaded in six months, implement a retention policy, run cleanup and measure the storage actually returned.
Publish BuildInfo from a pipeline using the JFrog CLI, promote the build between repositories, then answer traceability questions purely from queries.
Configure replication between two instances, load it, measure lag, then sever the link and document precisely what a build sees at the far end.
Index repositories and builds, write licence and severity policies, attach watches to what matters, and roll out enforcement in phases with an exception process.
Artifactory in Bangalore is rarely a greenfield decision. It is usually an instance that a parent organisation in the United States or Europe already owns, with the Bangalore engineering site attached to it as a replicated or Edge node — which is why the questions here are about replication lag, pull versus push topology, resolution order when a virtual repository spans a local cache and a remote parent, and what a build does when the link to the primary site is unavailable at 03:00 UTC. Teams along the Outer Ring Road and in Whitefield that maintain those nodes end up owning storage growth too, because the India site frequently produces the largest share of builds while the storage budget is approved elsewhere.
The second concentration is in silicon, EDA and embedded engineering across Bangalore, where the artifacts are not 40 MB JARs but multi-gigabyte toolchains, board support packages and simulation images. Checksum-based storage, generic and raw repositories, download throttling and cleanup policies matter far more there than package-manager niceties. A third group — the BFSI and healthcare GCCs — arrive with a compliance requirement rather than a build problem: every binary entering the estate must be scanned, licensed and traceable to the build that produced it, which turns Artifactory into an evidence system and puts Xray policies, watches and BuildInfo retention at the top of the agenda. Bangalore job specs for build and release engineers reflect this mix, usually pairing Artifactory with Jenkins or GitHub Actions and one repository-hygiene responsibility nobody wanted.
Two further details are peculiar to running a node from Bangalore. Mobile artifacts are unusually prominent, because the city holds India's largest concentration of Android engineering: AAR libraries, APK and app bundle outputs, and per-branch debug builds accumulate at a rate that surprises teams used to server-side JARs, and retention for them is nobody's job by default. And replication windows are set by somebody else's clock — a nightly sync scheduled for a quiet period at the parent site lands in the middle of the Bangalore working day, so a large pull can compete with the local build peak unless the schedule is renegotiated. Teams here also carry a support burden that does not appear in any architecture diagram: when a developer in Bengaluru cannot resolve a dependency at 10:00, the instance owner in another country is asleep, which is why the practical skill being bought is usually diagnosis — reading request and outbound logs, distinguishing a remote cache miss from an authentication failure, and knowing which of those the local team can actually fix.
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 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.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.