Gokul Upadhyay Guragaingocools

DevOps and MLOps Engineer

Gokul Upadhyay Guragain

I build the delivery paths that get software into production and keep it there. Cloud infrastructure as code, pipelines that fail loudly, and observability that answers questions before anyone thinks to ask them.

Gokul Upadhyay Guragain profile portrait

Real profile media is served from R2.

At a glance

Positions, interests, and the work between them

Full profile

Positions

  1. Trainee DevOps EngineeracAIberryMar 2026 — Apr 2026
  2. Fellow AI/MLOps EngineerFusemachinesMay 2025 — Dec 2025
  3. Apprentice Solutions ArchitectAdex InternationalNov 2024 — Feb 2025

Interests

  • Cloud architecture
  • Infrastructure as code
  • Delivery systems
  • MLOps
  • Observability
  • Teaching and community

Grounded in the projects, skills, and community work published here.

Current focus

Building ARCH, an architecture-as-code control hub that turns a drawn cloud topology into reviewable Terraform. Reading about eBPF-based network observability. Preparing the next AWS Student Builder session at LBEF.

Read the latest

What I build

Three things, repeatedly

The work divides cleanly. Everything else I do is in service of one of these.

  1. Infrastructure that is described, not assembled

    Terraform as the primary artefact rather than documentation written afterwards. Composable modules, remote state with locking, and availability decided per failure domain with the cost written down.

    Cloud notes
  2. Delivery paths that fail loudly

    Pipelines that produce evidence as well as artefacts, deployments identified by image digest rather than a mutable tag, and a production gate that can actually say no.

    DevOps notes
  3. Model serving treated as production

    An inference service is a production service with one extra failure mode: it can be healthy, fast and wrong. Pipeline-driven training, metric-gated registration, and monitoring that pairs request metrics with prediction distribution.

    MLOps notes

What I work with

Grouped by what the tool is for. Core means I have run it under real load and know how it fails.

Cloud

  • AWS
  • AWS SageMaker
  • Microsoft Azure
  • Cloudflare

Containers and orchestration

  • Docker
  • Kubernetes
  • K3s
  • Helm
  • kind and minikube

Infrastructure as code

  • Terraform
  • Ansible

CI/CD and GitOps

  • GitHub Actions
  • GitLab CI
  • Argo CD
  • Git and GitHub

Experience

Where the work happened

Full record
  1. Mar 2026 — Apr 2026

    Trainee DevOps EngineeracAIberry

    Delivery and MLOps work on a healthcare platform operating under HITRUST, where the pipeline is an audited control rather than convenience tooling.

  2. May 2025 — Dec 2025

    Fellow AI/MLOps EngineerFusemachines

    Containerised ML pipelines and K3s-hosted inference, instrumented so that a model service is treated as a production service with an extra failure mode.

  3. Nov 2024 — Feb 2025

    Apprentice Solutions ArchitectAdex International

    AWS architecture work where availability, cost and blast radius were treated as one conversation, and Terraform was the primary artefact rather than an afterthought.

  4. Jun 2024 — Oct 2024

    Cloud Engineering TraineeMentor Me Collective

    Structured cloud engineering training built around practical tasks rather than lecture material.

Writing

Recent articles

All writing

Now

Building ARCH, an architecture-as-code control hub that turns a drawn cloud topology into reviewable Terraform. Reading about eBPF-based network observability. Preparing the next AWS Student Builder session at LBEF.

Contact

If any of this is close to a problem you are trying to solve, I would like to hear about it.