Ankit Jangir Infrastructure & Security

Ankit Jangir

New Delhi, India

I build and operate cloud infrastructure. Currently at Dhwani RIS, where I lead the DevOps practice across a SaaS product line and the custom platforms we build for clients — enterprise, NGO and government, mostly on AWS. AWS Certified DevOps Engineer – Professional and Security – Specialty.

Selected Work

What I have built

Designed, built and still operated by me. Client names and findings withheld; the engineering described in full.

AI Agent Orchestrator

Solo build · Python · 19K lines · runs in CI
Case study

One orchestrator running specialist agents across three surfaces — code and application security, cloud posture and cost, and deployment. Each agent owns its domain and reports back through a single scored channel.

Orchestrator Code audit· Live pen-test· Cloud posture· Cost watch· Deploy agent
  • The deploy agent shipped ~250 same-day releases in a month across roughly 20 project teams — a fixed seven-step path: validate, review, snapshot, migrate, sync, rebuild, verify. Non-production only; production is never touched by an agent.
  • The cloud agent patrols every AWS account for internet-exposed hosts, open database ports, obsolete TLS, end-of-life software and publicly readable files — then checks account policy and posts a daily cost report naming the specific optimisations worth making.
  • The security agents swept 264 repositories for a supply-chain advisory in one afternoon, parsing lockfiles so transitive pins were caught and not just declared dependencies.
  • Rule-based detection, model-based judgement. Scanners are deterministic so findings stay reproducible between runs; the model only triages, remediates and summarises.
  • Backup before every write, health check after — the reason a month at that deploy volume produced no production incidents.
Read the deep-dive →
PythonPlaywrightOSV.devGitHub Actions

AI-Assisted Delivery Protocol

Plugin system · phase-gated · in use on live projects
Case study

A protocol for building software end to end with AI. Three plugins — Account Manager, Architect, Builder — each carrying its own skills, tools and commands, handing work down a gated chain from discovery through solutioning to build and test. The process cannot be skipped, because the tooling refuses.

Account Manager sign-off Architect sign-off Builder review gate
  • Gates enforced in the tooling, not the wiki. The Architect's commands stay locked until a signed charter exists; the Builder's until the solution document is approved. Process drift becomes impossible rather than discouraged.
  • Sub-personas inside the build loop — QA writes failing tests from the acceptance criteria before any implementation exists, Dev writes the minimum that passes, docs ship in the same PR, and a reviewer gates the merge.
  • Five specialist reviewers run in parallel on every change: permissions, SQL injection, PII leakage, endpoint exposure, and translation coverage. Critical findings block the merge.
  • Scope drift is surfaced, not absorbed — a weekly sweep compares live work against the locked charter and drafts the change request.
  • A versioned central skill library behind the plugins, semver'd and eval-gated, so a change to shared behaviour is a release rather than a surprise.
Read the deep-dive →
Plugin architecturePhase gatesTDD enforcementAutomated review

ISO 27001 ISMS, built from zero

Authored and maintained · in production use
Case study

The security programme our platforms are assessed against. I wrote it, I keep it current, and I am the person who sits opposite the assessors when a bank asks to see it.

Policy Control Register Evidence Assessment
  • 34 numbered policies — access control, incident response, secure development, third-party risk, cloud security, PAM, data classification and localization.
  • 16 operational registers that make the policies falsifiable: asset inventory, incident log, access recertification, DR-drill records, VAPT findings tracker.
  • Carried through the vendor security review of banks, insurers and a Big-Four assessor — each a full controls-to-evidence exercise.
Read the deep-dive →
ISO 27001SOC 2 / 3VAPTCycloneDX SBOMDPDP

Production Kubernetes Platform

AWS · EKS · multi-AZ · autoscaling
Case study

The platform our SaaS products run on. Designed for the two things that are expensive to retrofit: horizontal headroom, and an audit trail that satisfies an enterprise security review.

Users WAF CloudFront ALB EKS · Karpenter RDS Multi-AZ· Redis
  • Karpenter for node autoscaling rather than fixed groups — capacity follows demand instead of peak provisioning sitting idle overnight.
  • Security plane across the account: GuardDuty, Security Hub, Inspector, Config, KMS and ACM, with bastion access behind MFA only.
  • Observability from day one — Prometheus, Grafana and Loki internally, Site24x7 checking from outside the perimeter.
Read the deep-dive →
EKSKarpenterTerraformHelmPrometheus

Also Built

Other systems in production

Shorter form. Happy to go deeper on any of these in conversation.

Multi-Account AWS Landing Zone

AWS Organizations
Billing · security · governance separation
Payer· Security· Workload accounts
  • Dedicated security account aggregating Security Hub, GuardDuty, Config and CloudTrail across the estate.
  • SCPs and cross-account roles, so access is federated rather than per-account credentials.
  • 500+ resources in Terraform with remote state — environments are reproducible, not artisanal.

Three-Tier Platform on Azure

Azure · IaC
Delivered under Big-Four assessment
DDoS Public LB Web Internal LB App MongoDB 1P/2S
  • Whole environment as code — Terraform provisioned, released through Azure DevOps.
  • Veracode and Black Duck as blocking gates, so a release cannot ship past an unresolved finding.
  • Segmented Web/App/DB subnets with Key Vault holding every secret.

Lakehouse Data Pipeline

Airflow
Ingest → transform → serve → BI
FTP MinIO DuckDB ClickHouse Superset
  • Airflow orchestrating every stage, so a failed load is visible and re-runnable rather than silent.
  • DuckDB for transform — enough for the data volume, without a cluster to operate.
  • ClickHouse as the serving store behind analyst-facing dashboards.

Embedded Self-Service Analytics

Trino
BI over live operational data
Angular app Trino coordinator Workers 0…n MongoDB Atlas
  • Distributed SQL directly over MongoDB — no nightly ETL copy to keep in sync.
  • Superset dashboards embedded behind the product's own login.
  • VPC peering to Atlas, so query traffic never crosses the public internet.

Approach

How I work

Four things that show up in everything above.

PRINCIPLE01

Reproducible over clever

Environments as code, findings that don't change between runs, state you can rebuild. Clever is a liability at 3 a.m.

PRINCIPLE02

Evidence is a deliverable

A control nobody can demonstrate isn't a control. I build the register alongside the policy, because the assessor will ask.

PRINCIPLE03

I hold the pager

I operate what I design. It is the fastest correction mechanism there is for a bad architecture decision.

PRINCIPLE04

Cost is a design constraint

Rightsizing, reserved planning and spot automation belong in the first diagram, not in a panic after the bill.

Day to day
AWSAzureKubernetes · EKSTerraformHelm GitHub ActionsAzure DevOpsPrometheusGrafanaLoki PythonBashPostgreSQL · MySQL · MongoDB

What I’m looking for

Open to my next role

Four and a half years as the primary owner of cloud infrastructure — across a SaaS product line and a custom-delivery practice, for enterprise, NGO and government users.

What I want next is depth. Fewer platforms, owned longer, where I stay around for the second-order consequences of my own architecture decisions. Open to platform, DevSecOps, cloud architecture and SRE roles — remote or hybrid, based in New Delhi.

If you are hiring for infrastructure that has to be fast, stay up, and survive a bank’s security review — that combination is what I have spent four years doing.