Available for the next problem
I build the platform application teams deploy onto themselves, so shipping a service stops being a ticket.
Right now that means taking a Windows monolith apart into services a team can deploy itself, and running the multi-GPU inference behind it. I came up through hardware, hypervisors and Windows before containers were in my job description, which is why when a deployment fails I know which layer to open.
In infrastructure since January 2025, spent going up the stack rather than along it.
Nothing above works
if the layer below it is wrong
What I do
Reading an existing Windows application, finding the service boundaries, and making each piece build and run as a container. As much comprehension as configuration: you cannot containerise what you have not read.
Multi-GPU, multi-model vLLM serving Gemma, Qwen Coder and small instruct models behind production applications, sized against real GPU memory rather than a default.
On-premise to OCI through DRG gateways and site-to-site IPSec. VCN topology, NSGs, segmentation, and port-level control to cut the exposed surface to what is actually used.
A developer cannot accidentally delete production: OCI IAM and RBAC scoped per group, deletion protection on the resources that matter, and object-storage policy down to who may read which bucket. The platform prevents the mistake rather than documenting it.
A secret scan, asset validity, typecheck, lint, build and a gzipped JavaScript budget measured against a served instance, as one command that fails cheapest first. Accessibility and contrast are measured on the deployed URL every release. The budget gate caught a 462 KB regression against a 200 KB limit; the contrast gate caught hero text stuck at 30% opacity. A gate that has never failed is a comment.
Prometheus, Grafana, Alertmanager and Blackbox across cloud and on-premise, with Agent mode where one scrape node does not scale. Alerts route to whoever can act on them.
In production now
Multi-GPU, multi-model vLLM containers behind the company’s applications. Each model its own container, sharing a tensor-parallel GPU pool with an explicit memory fraction rather than a default that works right up until two models are resident.
One of these was blocked outright by RHEL 9 dependency conflicts. Rebuilding it on a custom Ubuntu base made it execute consistently everywhere instead of on one machine somebody had hand-fixed, which is the difference between a demo and a deployment.
Why me
Hardware, hypervisor, Windows and Linux, applications, then containers, in that order, on the job. Most failures happen BETWEEN two layers rather than inside one, and I have worked both sides of nearly every boundary in that list.
Claude Code and Codex daily: reading unfamiliar codebases, producing deployable artefacts, and writing the checks that prove them. The tooling removes the typing and the research, not the verification. That is why the turnaround is short and still tested.
Most delivery problems are handover problems. I work with the engineers writing a service and the people who have to run it, and translate in both directions.
Environments are rebuilt from source, not reconstructed from memory, and decisions are recorded with the alternatives that were rejected. A configuration without its reasoning is nearly useless six months later.
Selected work
Working through an established Windows application: reading the code, identifying service boundaries, and making each piece build, ship and run as a container so it can scale independently instead of as one deployable unit. The target is a platform the application team can deploy onto themselves.
Built and deployed multi-GPU, multi-model vLLM inference containers to serve the AI workloads the company's applications depend on. One of them was blocked outright by RHEL 9 dependency conflicts; rebuilding it on a custom Ubuntu base made it execute consistently everywhere instead of on one hand-fixed machine.
Contributed to a multi-terabyte data-centre migration into Oracle Cloud Infrastructure: compute, VCN topology, Security Lists, NSGs and site-to-site IPSec through DRG gateways, provisioned as Terraform. Followed by IAM and RBAC policy, deletion protection so a production resource cannot be terminated by accident, and object-storage rules that say who may read which bucket and how.
Built a self-hosted, multi-region platform on Prometheus, Grafana, Alertmanager, Blackbox Exporter and nginx with TLS, spanning cloud and on-premise sites, and retired the licence entirely. Prometheus runs in Agent mode per environment so it scales past a single scrape node.
Built independently
The production platform serving this page
A single-server, internet-facing platform: nginx terminating TLS as the only public entry point, Prometheus and Grafana behind it, browser-based remote desktops, and nightly encrypted off-site backups verified by an automated restore test. Ingress is restricted to Cloudflare's published ranges at both the cloud firewall and the host firewall chain. Architectural decisions are recorded with the alternatives that were rejected.
A UDP transport protocol for long, lossy links
TCP throughput collapses on a link with 1% packet loss and 100 ms of latency, however much bandwidth is available, because the congestion window never opens. UDPix moves the window logic, the acknowledgement scheme and the retransmit policy into userspace where they can be tuned for the link. Eight Rust crates: NAT traversal (STUN, TURN, ICE, hole punching), a control plane with auth and session management, selective acknowledgement, and a zero-copy IO path.
Cloud spend and right-sizing, as a scheduled PDF
Finance asks where the budget went and which resources can be trimmed. The options were an hour of clicking through the console or a third-party platform we needed ten per cent of. This collects compute, storage and cost data across compartments, runs utilisation, right-sizing and anomaly checks against a catalogue of real OCI shapes, and emails a PDF per compartment on a schedule. The analytics and delivery paths are unit-tested, because the numbers are the product.
Oracle's request signing, implemented by hand
Retries a launch request on a rate-limit-safe schedule until Oracle actually has free ARM capacity, then takes the instance, notifies, and disables its own timer. Written in bash, openssl and curl: it implements Oracle's REST request-signing scheme directly, so there is no SDK, no Python, no root and no third-party code in the hot path. Implementing a signature by hand means understanding it.
A golden path for a development machine
The onboarding problem, solved once. A reproducible Ubuntu environment in Docker carrying a pinned toolchain of Terraform, Ansible, kubectl, cloud CLIs and shell configuration, so a new machine is productive from one clone instead of a day of hand-installing and a week of discovering what was missed. The same artefact every time, for anyone, which is the whole point of a paved road.
Also public: CyberSentinel (web vulnerability scanner, Python) and Proxmox on a laptop over Wi-Fi (a write-up). All repositories →
Experience
Oct 2025 – present
Gandhinagar
Infrastructure and systems engineering across a multi–data-centre cloud and on-premise environment.
Jan 2025 – Oct 2025
Vadodara
Server administration, virtualisation, and network and endpoint security.
Jun 2024 – Jan 2025
Vadodara
Client operations support for US real-estate professionals, covering lead management and CRM administration.
Certifications
Education
Questions
The things people want to know before sending a first message.
Check them rather than believe them. The page is built so you can. Every case study states whether I owned it, led it or contributed to it, because a page that is vague about that on its strongest claims is a page rounding up. The platform serving this page is mine end to end and open source, including its decision log and the incidents I caused, so you can read what broke and what I changed afterwards. The honest summary is that the ground covered is unusual for the time and the seniority is not: I have gone up the stack rather than along it, and I would rather you judge that from the record than from an adjective.
Daily, and as an engineering tool rather than a novelty. Claude Code and Codex are how I read a codebase I have not seen before, turn an undocumented application into something with a working Dockerfile, and generate the tests and validation steps that prove a change before it ships. It compresses the typing and the research; it does not remove the reviewing, and the turnaround is short because verification is part of the task rather than a later phase.
The ones where the technology is new enough that nobody has written the runbook yet. Getting open-weight models into production was that a year ago and is close to routine now. The next one is probably the platform underneath it: making AI-assisted teams able to ship without waiting on a person, which is a harder problem than the models are. I would rather be early to a layer and on the infrastructure side of it, where being wrong shows up as a broken deployment instead of a slide.
That I did the layers in order. Physical hardware and hypervisors, then Windows and Linux administration, then applications, then containers and orchestration, each one on the job rather than from a course. It matters because most production failures are not inside a layer, they are between two, and diagnosing those needs somebody who has worked on both sides.
Yes, and that combination is less common than it should be. Active Directory, Group Policy and PowerShell on one side; systemd, containers and Bash on the other. A large part of the automation work has been making one managed fleet out of both, instead of two separate ones with a person in the middle.
Gandhinagar, Gujarat, India. The current work is already spread across data centres and time zones, so remote is normal rather than an adjustment. For a role outside India I would need visa sponsorship.
The platform serving this page is open source, including its decision log, the incidents and the fixes for them. Client work is not public, which is why the case studies above describe outcomes and architecture rather than internals.
Where this is going
AI will equip one engineer with the output of a team.
What decides whether any of it reaches a user is the layer underneath.
The bottleneck is moving. Writing the service stops being the hard part when a model can draft it, review it and test it. The hard part becomes everything that has always been hard: where it runs, what it talks to, who is allowed to reach it, what happens at three in the morning when it stops.
That layer does not get easier because the layer above it got faster. It gets busier. More services, deployed more often, by people who did not build the platform underneath them and should not have to.
So this is the work I want: building the floor that AI-accelerated teams stand on, and running the inference that makes them faster in the first place. I came up through hardware, hypervisors and operating systems to get here, which is the reason I know what the floor is made of.
Get in touch
I work on the layer between an application and the infrastructure it runs on: turning a service into something a team can deploy for themselves, and servers into something nobody has to log into by hand. If that is the problem in front of you, email is the fastest way to reach me.
This page is served by a platform I designed, built and operate end to end. TLS, routing, monitoring and alerting on a single free-tier ARM instance. Two cores, and most of the work is making them behave like more.