The short version
I’m a Cloud and DevOps engineer based in India. I build, deploy, and operate real production systems on AWS — not as a textbook exercise, but as the actual day job. Four services live at srjahir.in, tools.srjahir.in, cloudai.srjahir.in, and stocks.srjahir.in, all of which I set up, configured, and maintain end-to-end. Domain, DNS, HTTPS, deployment, monitoring — the whole thing.
SRJahir Tech is where I share what I’ve actually built, broken, and fixed. Nothing on this site is theoretical. If you read something here, it’s because I figured it out the hard way and wanted to save you the trouble.
How I got here
I didn’t start in tech. I ran a business first — and that’s probably the most important detail to understand about how I write. Running a business teaches you that nothing works because you said it should. Systems break. People miscommunicate. Costs spiral. The only thing that saves you is ownership — actually caring about the outcome, end to end.
When I transitioned into cloud engineering, that mindset came with me. I treat every server like it’s my own money on the line — because on my personal infrastructure, it literally is. Every pipeline I build assumes things will break at 2 AM. Every architectural choice asks “what does this cost me when it scales?”
What I work with
The day-to-day stack — these aren’t tools I’ve read about. They’re tools I’ve used to ship things that are running right now:
Live projects you can actually visit
Everything below runs on infrastructure I personally set up. No managed magic — I configured the servers, the networking, the deployments.
Open-source work on GitHub
Beyond the live services, I publish everything I learn as portfolio projects on GitHub. Each one has a real README, works end-to-end, and is built to be studied or extended:
docker-compose up and 7 alert rules.Full portfolio at github.com/Srj0210.
Why I write
Three reasons, honestly.
One: writing forces me to actually understand things. If I can’t explain Kubernetes networking in plain English, I don’t really know it. The writing is half for you, half for me.
Two: when I was starting out, every tutorial either dumbed things down so much I learned nothing, or buried me in jargon to sound smart. Neither helped. I write the version I would have wanted.
Three: ads and free tools pay the hosting bills. So the more people who read and share, the longer this site stays alive. That’s the model. No paywalls. No premium tier. No “subscribe to read more”.
What this site isn’t
It’s not a course-selling business. I’m not running affiliate funnels. I’m not building an email list to spam you later. If you ever see me pivot in that direction, please call me out.
It’s also not a complete reference for any of these topics. The AWS docs are more complete. The K8s docs are more authoritative. What this site offers is structure, opinion, and the perspective of someone who actually uses this stuff every day. That’s the gap I’m trying to fill.