Production since 2019, not a lab
Linux, Plesk, cPanel, AWS, and DigitalOcean at real scale. Migrations, patching, backups, DNS, and web stacks at DigitalOcean, One.com, and ServerGuy, with SLAs attached.
Open to full-time roles and AI integration projects
DevOps · SRE · AI Infrastructure
I keep production online.
Models included.
gyan@prod ~ $ whoami
- I design, deploy, and maintain production infrastructure
- Seven-plus years of cloud servers, on call since February 2019
- Now I design with AI in the loop, so the architectures come out more robust
- I integrated AI instead of ignoring it: less manual work, fewer avoidable mistakes, more shipped
- I built PAKAD.AI, which turns your infrastructure into context and returns a real RCA with steps you can act on
Delhi NCR, IndiaRemote, hybrid, or on-siteIn production since 19 Feb 20197 certifications
gyan@prod: ~live
Gyanaranjan Pradhan
AI Infrastructure Engineer · DevOps & SRE
Delhi NCR, India
gyan@prod ~ $ infra status --models
modelwhere
- qwen 3.6AlibabaOllama · vLLMself-hosted
- gemma 4GoogleOllama · LM Studioself-hosted
- mistralMistral AIBedrockapi
- claudeAnthropicBedrockapi
- novaAmazonBedrockapi
- deepseekDeepSeekBedrockapi
- ocr stackTesseract · docTRself-hostedself-hosted
99.99%
uptime
<10 min
MTTR
7+ yrs
in production
Production I have carried
DigitalOceanSenior Cloud Engineer II
One.comDevOps Engineer III
ServerGuySenior Linux Server Engineer
// what I am good at
Four things I do well, and can prove.
I serve the open models myself
Qwen 3.6 and Gemma 4 on Ollama, vLLM, and LM Studio, exposed through Open WebUI and AnythingLLM. Sizing the GPU, picking the quantization, watching VRAM headroom, keeping throughput steady when the queue fills up.
I route to Bedrock when it earns it
Claude, Amazon Nova, DeepSeek, and Mistral through one Bedrock gateway, chosen per task on cost, latency, and where the data is allowed to go. Fallbacks and timeouts on every call.
When it breaks at 3am, it is mine
Live triage across the application, hosting, and platform layers, then the RCA that keeps it from repeating, then the runbook so the next engineer does not need me. Same on the security side: VAPT and incident response inside the SOC.
// the model fleet
What I run, and what each one is for.
Some of these live on hardware I manage, the rest are API calls I pay for. Each one is here because it does a job better or cheaper than the alternative, not because it was in the news.
qwen 3.6Alibaba
Bulk log and config analysis on data that is not allowed to leave the network
Ollama · vLLMself-hosted
gemma 4Google
Fast on-box drafting and summaries during triage, no egress, no per-token bill
Ollama · LM Studioself-hosted
mistralMistral AI
Structured extraction and classification over ticket and alert text
Bedrockapi
claudeAnthropic
Root-cause writeups, runbooks, and config review where the output quality matters most
Bedrockapi
novaAmazon
AWS-native workloads that have to stay inside the account and its IAM boundary
Bedrockapi
deepseekDeepSeek
Long reasoning passes over incident timelines where token cost decides the design
Bedrockapi
ocr stackTesseract · docTR
Scanned documents, screenshots, and console captures turned into text I can query
self-hostedself-hosted
// self-hosting stack
The rig I run open models on.
Self-hosting a model is not one tool, it is a stack. This is mine, from the thing that loads the weights up to the thing a human actually types into.
- 01serving
- Ollama
- vLLM
- LM Studio
- llama.cpp
Ollama for quick local pulls, vLLM when throughput matters and requests need batching, LM Studio for trying a new quant before it earns a slot.
- 02interface
- Open WebUI
- AnythingLLM
Open WebUI is the chat front end my team touches. AnythingLLM holds the workspaces where runbooks and docs get retrieved instead of pasted.
- 03gateway
- Bedrock
- OpenAI-compatible API
One compatible endpoint in front of everything, so swapping a local model for a Bedrock one is a config change and not a rewrite.
- 04hardware
- GPU sizing
- Quantization
- VRAM headroom
Picking the quant that fits the card, leaving headroom for context, and knowing what falls over when the queue gets deep.
// decision rules
How I decide which model gets the job
Model choice is a capacity and risk decision, same as picking an instance type. These are the rules I actually apply.
Every generated output gets a human review before it touches production. That has not changed and will not.
if
The data cannot leave the network
then
Self-hosted open weights. No API call ever gets the chance to make that decision for me.
if
The volume is high and the task is routine
then
Open model on my own GPU. Once you are past a certain request rate, owning the hardware wins on cost.
if
The reasoning is hard and the output is customer-facing
then
A frontier model on Bedrock. I would rather pay per token than ship a confidently wrong RCA.
if
The workload is locked to AWS
then
Bedrock end to end, Nova included, so the data path and the IAM story stay inside one account.
if
Anything is in the critical path
then
Timeouts, a fallback model, and a plain non-AI path underneath. A model outage should degrade the feature, not the platform.
// selected work
Two things I built and still maintain.
AI wired into the support pipeline
Autonomous Ticket Resolution
Tickets that used to wait on an L1 engineer now get diagnosed, fixed, and verified without one. The hard ones reach L3 with the work already done.
- the problem
- Support queues fill with L1 and L2 tickets that already have known fixes, and every one still costs an engineer a context switch. The tickets that genuinely need an L3 sit in the queue behind them.
- what I built
- The models sit inside the ticketing platform. A CMDB lookup maps the customer report to the real resource and its dependencies, then read-only MCP servers hand over the logs, metrics, and parameters the models ask for. Three open models each run their own RAG pass over that evidence, and a fourth model judges all three outputs and returns a single verdict. L1 and L2 fixes get applied and then verified. L3 and critical tickets escalate to a human with the diagnosis attached.
- L1 and L2 tickets close without an engineer opening them
- Every automatic fix is verified before the ticket is allowed to close
- L3 and critical arrive with the diagnosis and the actionable steps already written
- Three models cross-check each other, so one confident wrong answer does not become the fix
- Access stays read-only, so a model can never change the thing it is diagnosing
- MCP
- CMDB
- RAG
- Qwen 3.6
- Gemma 4
- Mistral
- Judge model
resolution pipeline
01ticket in
A customer issue lands in the support platform
02cmdb lookup
Map the report to the actual resource, its owner, and everything downstream of it
03read-only mcpread only
Serves the logs, metrics, and parameters the models ask for. There is no write path to give away.
04 · three models, three independent answers
qwen 3.6
rag pass
gemma 4
rag pass
mistral
rag pass
05judge model
Reads all three answers, weighs them against the evidence, and returns the one verdict worth acting on
L1 · L2
Fixed automatically, then verified before the ticket is allowed to close
L3 · critical
Escalated to an engineer with the diagnosis and the steps already written
$ ticket #8842 resolve --auto
- cmdb
- web-prod-04 · nginx
- evidence
- logs, metrics, params
- triage
- 3 models agreed
- verdict
- worker pool exhausted
- action
- applied, verified
My own SaaS, shipped
PAKADpakad.ai
An AI infrastructure engineer that watches servers live and turns an incident into a plain-English root cause.
- the problem
- Hosting providers and MSPs find out about incidents late, and their senior engineers keep hand-writing the same root-cause analysis every week.
- what I built
- A lightweight Go agent streams telemetry while agentless checks watch every site. A reasoning layer correlates the signals and writes the root cause and the fix on request. Multi-tenant, with a live dashboard, an NOC wall, and an API. Nothing acts on production without a person approving it.
- Manual RCA writing drops to near zero
- Incidents surface live instead of after a customer calls
- Senior-engineer diagnosis becomes a workflow anyone on the team can run
- Go
- Node.js
- PostgreSQL
- VictoriaMetrics
- Claude
rca --explain incident-4471
- detected
- mysql connections saturated
- cause
- runaway cron, no connection cap
- fix
- cap pool, add cron lock
- reviewed_by
- human, before apply
illustrative output
Multi-region security platform
Managed Wazuh SOC
A security operations center built so that losing one region does not mean losing visibility.
- the problem
- Hosting spread across regions meant logs sat in a dozen places and nobody could investigate a threat end to end.
- what I built
- HA Wazuh managers with a two-node indexer, an nginx edge doing L4 forwarding and TLS, WireGuard tunnels between regions, controlled agent enrollment, and health checks. OpenVAS runs continuous scanning alongside it, and I run the VAPT engagements and lead incident response on what those findings turn up. Every workflow written up as a runbook an on-call engineer can follow half asleep.
- One place to detect and investigate across every region
- No single point of failure left in the SOC itself
- Findings move from scan to VAPT to a closed remediation, not into a spreadsheet
- Incident response became a documented procedure instead of tribal knowledge
- Wazuh
- nginx
- WireGuard
- OpenVAS
- VAPT
- TLS
soc health --all-regions
- managers
- 2/2 healthy
- indexer
- 2 nodes, green
- tunnels
- wireguard up
- scan
- openvas nightly
illustrative output
SOC Operations Panel
Endpoint and security telemetry with vulnerability scanning and validation steps, so an investigation starts with evidence instead of guesswork.
- Wazuh
- OpenVAS
- Kali
Infrastructure Monitoring Panel
Health, availability, and service visibility across the estate, tuned for catching capacity problems before they become incidents.
- Prometheus
- Zabbix
- Grafana
// daily workflow
Where the models sit in my day
These are the jobs I have handed to a model, and the ones I have not.
delegated to a model
- $ rca draftclaude
First pass at a root cause from the incident signals. I rewrite it, I sign it.
- $ runbook genqwen 3.6
Turn a fix I just performed into a runbook while the details are fresh.
- $ log siftgemma 4
Pull the interesting lines out of a few hundred megabytes of logs, locally.
- $ config reviewclaude
Second opinion on nginx, systemd, and Terraform before a rollout.
- $ ticket triagemistral
Classify and route inbound alerts and tickets by what they actually are.
- $ docs askanythingllm
Ask the runbook and doc workspace a question instead of grepping a wiki.
- $ doc extractocr stack
Read scanned docs and console screenshots into text I can grep.
never delegated
- Approving a change in production
- Deciding whether to fail over
- Anything touching customer data without a review
A model can draft the answer. It does not get to press the button.
// building with models
Infra people vibe code better.
Getting a model to produce code is the easy part. The skill is knowing whether what came back will survive contact with production, and that is an infrastructure question, not a prompting one.
01
I can see what will not hold
Generated code that works on one box and falls over on a restart, a second replica, or a slow disk. I have debugged those failures for years, so I catch them in review instead of at 3am.
02
I catch the defaults that are quietly wrong
Open ports, permissive IAM, secrets in the wrong place, a database listening where it should not. Models produce these constantly because they look correct.
03
When it breaks I debug the system, not the prompt
Most of the time the generated code was fine and the network, DNS, or a firewall rule was not. Knowing which layer to suspect is most of the work.
04
I know when to stop generating
Some things are faster to write by hand than to explain twice. Recognising which is which saves more time than any prompt trick.
// track record
Where I have kept the lights on.
AI Solutions Consultant, DevOps & SOC
currentIndependent Consulting · Remote · Apr 2026 to Present
- Wired models into support and ticketing platforms so L1 and L2 issues resolve and self-verify, with L3 and critical escalating to engineers with the diagnosis attached.
- Advise teams on putting models into their platforms and operations without loosening their security posture.
- Run VAPT engagements and lead incident response inside the SOC.
- Design the automation that removes the recurring manual work engineers resent doing.
DevOps Engineer III
Group.one (One.com) · Remote, Denmark · Apr 2025 to Jan 2026
- Ran scalable, secure infrastructure for large hosting and cloud platforms, Plesk included.
- Rebuilt monitoring and alerting so problems surfaced before customers noticed them.
- Resolved critical production incidents end to end, from triage through RCA and cross-team follow-up.
Senior Cloud Engineer II
DigitalOcean · Remote, US · Mar 2023 to Jan 2025
- L3 support for premium partners across the application, hosting, and platform layers.
- Delivered migrations plus performance and security fixes on live customer workloads.
- Wrote the RCA notes and KB articles that let L1 and L2 close repeat issues without escalating.
Senior Linux Server Engineer, Support & Ops Manager
ServerGuy · New Delhi, India · Feb 2019 to Mar 2023
- Managed Linux and Windows hosting across WordPress, Magento, cPanel, and Plesk.
- Led patching, scaling, backups, migrations, and the automation that replaced the repetitive parts.
- Mentored engineers and kept delivery inside SLA.
// the stack
Tools I reach for without looking them up.
Model serving
- Ollama
- vLLM
- LM Studio
- llama.cpp
- Quantization
- GPU sizing
AI integration
- MCP servers
- RAG pipelines
- Open WebUI
- AnythingLLM
- CMDB mapping
- Vibe coding
Models
- Qwen 3.6
- Gemma 4
- Mistral
- Claude
- Amazon Nova
- DeepSeek
- OCR
Cloud & hosting
- AWS
- Bedrock
- DigitalOcean
- Plesk
- cPanel
- Proxmox
- KVM/XEN
Observability
- Prometheus
- Grafana
- Zabbix
- VictoriaMetrics
Security & SOC
- VAPT
- Incident Response
- Wazuh
- OpenVAS
- WireGuard
- TLS
- Hardening
Platform
- Linux
- Docker
- CI/CD
- Go
- Node.js
- PostgreSQL
- Bash
Certifications
- AWS SysOps Administrator
- AWS Cloud Practitioner
- Red Hat RHCSA
- Plesk Obsidian Professional
- CompTIA Network+
- CompTIA A+ / ITF
- Ethical Hacking Expert
Education
B.Sc. Information Technology
Centurion University of Technology & Management · 2014 to 2017
CHNA, Computer Hardware & Network Administrator
IANT · 2017 to 2019
Languages
- English
- Hindi
- Odia
- Russian
Available now
Two ways to put me to work.
I run production infrastructure and I build the AI layer that sits on top of it. Either one is on the table.
Full-time role
Hire me onto the team
DevOps, SRE, platform, or AI infrastructure. I want a team running real production that is putting models into it, and I bring the on-call habits that keep both standing.
- DevOps Engineer
- Site Reliability Engineer
- Platform Engineer
- Cloud Operations
- AI Infrastructure Engineer
AI integration
Bring me in for the AI work
Project work for teams adding AI to a platform or product. I take on the parts that break once real traffic arrives, not the demo that works on a laptop.
- Self-hosted model serving on hardware you own
- MCP servers and RAG pipelines wired into real systems
- Multi-model routing with fallbacks and cost control
- The read-only security boundary around all of it
Gyanaranjan Pradhan
AI Infrastructure Engineer · DevOps & SRE
Delhi NCR, India · Remote, hybrid, or on-site
I reply to every message, usually the same day.