Healthy
0/0 stages
METRICS
CPU0%
MEM0%
NODES0
LOGS
→ Health checks passing
→ Traffic routing enabled
→ Observability active

about / abhichandra

I keep systems
boring.

SRE / Platform Engineer. I take Kubernetes workloads from works-on-my-laptop to hardened, monitored, and shipping safely to production — available for scoped, fixed-price infrastructure work.

Available for scoped work
Bengaluru, IST
Updated 2026.10
abhichandra@platform:~● online

01 / about

Infrastructure
with intent.

I work at the seam between software and operations — the place where a good design decision quietly becomes someone else’s uneventful Tuesday.

That means designing platforms teams actually trust, shrinking the blast radius of change until deploys stop being events, and turning hard-won incident lessons into defaults nobody has to remember. My day-to-day lives in Kubernetes, Go, and Terraform — and, more than any of them, in the feedback loops wrapped around the three.

Abhichandra
AbhichandraSRE / Platform · Bengaluru
  1. 01

    Boring is the goal, not the byproduct.

    A platform that never surprises anyone is the hardest thing to build and the easiest thing to undervalue. I optimise for the shift where nothing happens.

  2. 02

    Blast radius before velocity.

    Shipping fast is a consequence of being able to fail small. Progressive rollouts, real health signals, and a rollback that someone has actually rehearsed.

  3. 03

    Every incident is a design review.

    The postmortem is where architecture tells you the truth. The lesson only counts once it has become a default, a guardrail, or a deleted footgun.

toolchain

The path a change
takes to production.

Ordered by where each tool sits in that path rather than by how much I like it. The goal at every stage is the same: make the next deploy safer than the last.

  1. write01
    GoPythonTypeScript

    Small services with failure modes you can name out loud.

  2. package02
    DockerTerraform

    The image and the infrastructure both arrive as reviewable diffs.

  3. ship03
    GitHub ActionsArgoCD

    Canary first, and a rollback someone has actually rehearsed.

  4. run04
    KubernetesAWSLinux

    Workloads that scale sideways and restart without an audience.

  5. watch05
    PrometheusGrafana

    Signals tied to what users feel, not to what CPUs are doing.

02 / architecture

System
topology.

The shape most of my work takes: traffic in at the edge, one control plane, workloads that scale sideways, and state kept boring. Select a tier to see what it carries.

service-map/6 nodes
INGRESSUSERedge · tlsCONTROLPLATFORMapi · authzWORKLOADSERVICESk8s · autoscaledWORKLOADPIPELINESci/cd · gitopsSTATEDATABASEprimary + 2TELEMETRYOBSERVABILITYmetrics · logs
click a node to filter projects by dependency·shift+click to add·esc to clear

03 / operations

Production
observability.

Real-time system health, metrics, and incident response. The calm before and after.

production/operational
servicep9930duptime
ingress38ms99.95%
api62ms100.00%
workers140ms99.91%
database9ms100.00%
monitoring21ms100.00%
error budget · 99.95% target96.8% left
latency63ms
traffic1.00k/m
errors0.04%
saturation52%
recent changes · no active incident
14:02ingress v2.31 · canary → 100%
11:20postgres 16.4 minor upgrade
09:07worker pool +2 replicas · autoscaler
-1dalert rule: p99 window 5m → 2m
-2dterraform: drop unused nat gateway

04 / selected work

Systems that
hold up.

A few problems I have helped make smaller, safer, and easier to operate. Commit data comes straight from the repositories.

repository data fetched at build··a push to any linked repo triggers a rebuild
case 01Go

Hardened delivery pipeline

CI/CD case study

Took a Go service from manual deploys and a root-running ~1GB image to an ~8MB non-root distroless image shipped by a tested, Trivy-scanned pipeline. Build → scan → push → deploy, with the vulnerability scan gating the release.

abhichandra-v/orders-api-pipeline
cd72f41Initial commit: orders-api-pipeline
committed
lang Gostars 0pushed
DEPLOYMENTBuild → scan → push → deploy
DATAdistroless / non-root
GoDockerGitHub ActionsTrivy
case 02Kubernetes

Kubernetes container hardening

Security case study

Hardened a workload carrying the misconfigurations found in most un-reviewed clusters — root, privileged, Docker socket mounted, secrets in plaintext — down to zero critical findings. Verified: kube-score 9 criticals → 0, checkov 22 failures → 1.

abhichandra-v/k8s-hardening-case-study
034e97bInitial commit: k8s-hardening-case-study
committed
lang Shellstars 0pushed
DEPLOYMENTkube-score + checkov verified
DATA9 criticals → 0
Kuberneteskube-scorecheckovPod Security

05 / field notes

Notes from
the pager.

Short records of things that broke, what they taught me, and the defaults I changed after.

5 notes indexed2 published3 in draft
container security

5 things I'd harden in a popular Nextcloud-on-Kubernetes manifest

A widely-forked homelab manifest, scanned: 6 kube-score criticals and 16 checkov failures, and the five-line-each fixes that take it to zero.

4 min2026-10-06
container security

The one line I'd never ship: an API key in plaintext in a k8s manifest

A real cloudflare-ddns deployment with a live credential inlined in env — why it leaks, and the least-privilege rewrite around it.

4 min2026-10-06
distributed systemsdraft

etcd split-brain, from symptom to quorum

The path from a cluster that looks healthy to the quorum arithmetic that says otherwise.

8 min
service meshdraft

When Envoy eats the heap

Tracing sidecar memory growth to its real cause instead of raising the limit again.

6 min
kubernetesdraft

The affordable staging cluster

Cost controls that shrink the bill without quietly removing the feedback staging exists to give.

5 min

06 / contact

Have a hard systems problem?
Let's talk.

Available for scoped, fixed-price infrastructure work — container-security reviews, CI/CD pipelines, and GitOps rollouts. Also up for the conversations that start with “this is probably a bad idea, but…”

Available for scoped workBengaluru--:-- IST