Private corporate batches, live online cohorts and 1-on-1 mentoring in the icon library in production — SVG versus webfont delivery, the v4 to v6 migration, self-hosting, subsetting and accessibility — 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 Font Awesome as a delivery and performance problem rather than as a list of class names: how the webfont and SVG methods actually render, what each costs on first paint, and why the SVG path is the default recommendation for anything new. Sessions cover the material teams get wrong in production — Kit versus CDN versus self-hosted npm delivery, subsetting and tree-shaking so a project ships only the icons it references, preloading and font-display so icons never cause a layout shift, and the accessibility semantics that decide whether an icon is announced or correctly ignored. The version 4 to version 6 migration is worked through end to end, including the prefix and naming changes, the shim, and how to audit a large codebase for icons that no longer exist.
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 Font Awesome that means a trainer who has run it in production — the icon library in production — SVG versus webfont delivery, the v4 to v6 migration, self-hosting, subsetting and accessibility — 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 Font Awesome batchFont Awesome is an icon library used to place scalable vector icons into web and application interfaces without commissioning artwork for each one. It ships thousands of icons covering interface actions, brands, files, media, transport, medical and many other domains, and every icon can be sized, coloured, rotated, stacked and animated with ordinary CSS because it is vector rather than raster.
The part that matters technically is that Font Awesome has two entirely different delivery mechanisms and the choice between them has consequences. The webfont method packages icons as glyphs in a font file and renders them through CSS pseudo-elements — one request, broad browser support, but every icon in the family downloads whether you use four of them or four hundred, and icons inherit all the quirks of text rendering. The SVG method injects or references real SVG elements, which gives per-icon control, better accessibility semantics, multi-colour and layered rendering, and the ability to ship only the icons a project actually references. Modern projects overwhelmingly use SVG, either through the framework components for React, Vue and Angular or through a build step.
The third consideration is how the library reaches the browser at all. A hosted Kit is a single script tag with automatic subsetting and version pinning; a CDN link is a static stylesheet; self-hosting from npm puts the assets under your own control, your own caching policy and your own content security policy. Each option trades convenience against control, and the version story — the naming and prefix changes across version 4, version 5 and version 6 — is what turns an upgrade into a project rather than a dependency bump.
Icons are not decoration in a modern interface; they carry meaning, and they sit on the critical rendering path. A badly delivered icon set blocks first paint, shifts layout after it, downloads several hundred kilobytes for a handful of glyphs, and presents screen reader users with either silence or a meaningless character code. Those are measurable defects against Core Web Vitals and accessibility audits, and they are usually caused by copying a snippet from documentation and never revisiting it.
The second driver is migration debt. A large number of production applications still carry Font Awesome 4 markup, where every class name, several icon names and the entire style prefix system have since changed. That upgrade is not automatic, and teams postpone it until a security or dependency review forces the issue, at which point somebody has to understand both the old and new naming systems well enough to migrate hundreds of templates safely.
Third, governance. Icon usage spreads across a codebase faster than any design system can document it, licensing differs between the free icons, the font files and the code, and Pro features introduce a token that must not end up in a public repository. Teams benefit from someone who has thought about all three.
The problem before the library. How interfaces have delivered icons over time — image sprites, icon fonts, SVG sprites, inline SVG and component libraries — and what each costs in requests, bytes, control and accessibility. Then Font Awesome specifically: what it provides, what the free tier includes, and the alternatives worth knowing about.
Topics: Raster sprites, icon fonts, SVG sprites and inline SVG compared · Why icon fonts became popular and why they lost ground · What Font Awesome provides and how the catalogue is organised · Free versus Pro: icon counts, styles and features · Icon families and styles: solid, regular, light, thin, duotone, sharp, brands · Font Awesome compared with Material Symbols, Feather, Heroicons and Bootstrap Icons · Reading the icon catalogue, search and Unicode values · Licensing: icons, fonts and code are licensed separately
Every delivery method, built and measured. A hosted Kit with its automatic subsetting and version pinning; the CDN stylesheet; self-hosting from npm with your own build; and the framework component packages. Then the operational questions each raises: content security policy, subresource integrity, caching headers and version locking.
Topics: Kits: setup, configuration, version pinning and auto-subsetting · The CDN stylesheet and subresource integrity · Self-hosting from npm: package layout and asset copying · The webfont CSS method and pseudo-element rendering · The SVG with JavaScript method and DOM injection · SVG sprites and the use element · React, Vue and Angular component packages · Content security policy implications of each method · Caching, cache-busting and version locking · Offline and air-gapped environments
Everything you can do to an icon once it is on the page. Class structure and style prefixes, sizing scales and fixed-width alignment, lists and bordered icons, rotation and flipping, animation, then the composition features — stacking, layers, layered text and counters, and power transforms — that let you build an icon the catalogue does not contain.
Topics: Class structure: family prefix, style and icon name · Sizing: relative scale, literal sizes and matching text · Fixed width icons and vertical alignment · Lists, bordered and pulled icons · Rotating, flipping and mirroring · Animation: spin, pulse, beat, fade, bounce and shake · Stacking icons · Layers, layered text and layered counters · Power transforms: grow, shrink, rotate, translate · Duotone icons and per-layer opacity and colour · Styling with CSS: colour, gradients, shadows, hover states · Custom icon uploads in a Kit
The module that exists because most real work on Font Awesome is upgrade work. What changed at each major version — the version 4 to 5 prefix and naming overhaul, the version 5 to 6 family and style restructuring — how the compatibility shim works and why it is a bridge rather than a destination, and how to audit and migrate a large codebase without breaking pages nobody tests.
Topics: Version 4, 5 and 6: what actually changed and why · The prefix system: fa, fas, far, fab and the fa-solid style names · Renamed, merged and removed icons · The version 4 and version 5 compatibility shims and their cost · Auditing a codebase for icon usage across templates and components · Scripted migration and where automation is unsafe · Handling icons that moved between free and Pro · Testing a migration: visual regression and manual sweeps · Version pinning, upgrade cadence and dependency policy · Migrating from a different icon library entirely
Icons are read by more than eyes. The fundamental distinction between decorative and meaningful icons and how each should be marked up, accessible names for icon-only controls, why webfont icons can be announced as garbage by screen readers, focus and target sizing, and how icons behave under high contrast mode, forced colours and zoom.
Topics: Decorative versus meaningful icons, and marking each correctly · aria-hidden, role and the title element in SVG · Accessible names for icon-only buttons and links · Why pseudo-element icons can be read aloud as junk · Colour contrast requirements for icons that carry meaning · Touch target size and spacing · Focus visibility on icon controls · Windows high contrast mode and forced-colors · Icons under zoom and with text-only settings · Testing with a screen reader and with automated tooling · Icons that convey state, and why they need text too
The engineering half. Why the full webfont family is almost always the wrong thing to ship, how subsetting and tree-shaking work with each delivery method, building an explicit icon library so a bundler can drop the rest, preloading and font-display to stop icons blocking or shifting, and measuring all of it rather than assuming.
Topics: Measuring icon cost: bytes, requests, blocking time and layout shift · Why the whole family downloads with the naive webfont setup · Kit auto-subsetting and how it decides · Tree-shaking with the JavaScript API and an explicit icon library · Building a custom SVG sprite for a fixed icon set · Preloading font files and the crossorigin trap · font-display and the flash of invisible icons · Reserving space to prevent cumulative layout shift · HTTP caching, immutable assets and long-lived versions · Lazy-loading icons for below-the-fold content · Bundle analysis and catching icon bloat in CI · Server-side rendering and hydration considerations
Keeping icon usage consistent as a codebase and a team grow. The React, Vue and Angular component packages and their icon library pattern; wrapping Font Awesome behind your own design system component so the library can be swapped; licensing obligations for free and Pro; Kit token handling; and the review practices that stop icon sprawl.
Topics: The React component package: FontAwesomeIcon, library and props · Vue and Angular component packages · Wrapping icons in a design system component · Typed icon names and catching bad names at build time · Icon naming conventions and semantic aliases · Storybook or equivalent documentation for available icons · Licensing obligations: CC BY for icons, SIL OFL for fonts, MIT for code · Attribution requirements and where they apply · Pro Kit tokens, secrets handling and keeping them out of repositories · Uploading and managing custom icons alongside the catalogue · Review checklist for icon changes · Planning an icon library swap without touching every component
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall the same icon set as a Kit, a CDN stylesheet, self-hosted webfonts and tree-shaken SVG, then compare bytes, requests, blocking time and layout shift side by side.
Use stacking, layers, layered counters and power transforms to compose five interface icons that do not exist as single glyphs, and keep them accessible.
Audit a legacy codebase for every icon reference, migrate the prefixes and renamed icons, remove the compatibility shim, and prove nothing regressed visually.
Take an interface where icons carry meaning but nothing is announced, correct the semantics for decorative and meaningful icons, and verify with a real screen reader.
Cut an icon payload by an order of magnitude using an explicit icon library and tree-shaking, then add a CI budget check that fails on regression.
Deliver a wrapped icon component with typed names, documentation, a performance budget, accessibility rules and licence notes that a whole team can build against.
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
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
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.
| 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.