Raghav Dakshkeeps infrastructure boring, on purpose.

Context

Solo DevOps hire at an early-stage gaming startup running backend, frontend, and CI/CD off a single self-managed VM.

Problem

The VM was a single point of failure and a manual scaling bottleneck — every deploy, patch, and resource change was a manual, unversioned operation.

Decision

Move backend and frontend to Cloud Run and GCS (serverless), keep Jenkins on a small VM strictly as the CI/CD control plane.

What I built

GitHub-triggered Jenkins pipelines deploying to Cloud Run with health checks, a versioned GCS backup pipeline with automatic retention, and Zoho Cliq integration for deploy visibility.

Outcome

Deploys went from manual, undocumented steps to a single push-to-deploy flow with automatic rollback-relevant backups.

Retrospective

Write infrastructure as code from day one instead of console-first — a discipline carried straight into the personal project below.

Context

Personal project, in progress — a 6×5 cluster-pays cascade slot on Stake Engine, a proprietary iGaming RGS platform, independent of the Vyantra day job.

Problem

Seven bet modes — base, a high-volatility base, two ante modes, two bonus buys and a binary activation mode — each had to land on exactly 96.70% RTP while staying inside the platform's volatility bands and payout-distribution rules for its star rating.

Decision

Build on the SDK's flood-fill cluster evaluation (5+ connected symbols), layer cascades and multiplier symbols on top, and let the SDK optimizer solve each mode against fixed RTP and hit-rate targets instead of hand-tuning weights.

What I built

The math for all 7 modes; regression tests for tumble events, config invariants and the published library; and a content-drift check that fails when published game info disagrees with the live math. Wired the math config and sample round books into the team's Svelte 5 + PixiJS frontend.

Outcome

Worked through the platform's QA review: pulled one mode's volatility back inside its rating band, filled empty payout tiers, fixed a multiplier-formula bug, and capped max win at 50,000× across every mode for a 2-star rating.

Retrospective

Published numbers went stale twice and QA caught it before I did. Anything that lives in two places now gets an automated check, not a promise to remember.

Link

Proprietary platform, source not public — full write-up available on request.

workspace/
├── math-sdk/     vendor · origin: my fork · upstream: StakeEngine
├── web-sdk/      vendor · tracks upstream
├── <studio>/
│   ├── <game>/            its own repo (math)
│   └── <game>-frontend/   its own repo, sibling — never nested
└── math-sdk/games/<game> → ../../<studio>/<game>   symlink only

Context

Game math started life inside a fork of the platform's math SDK, mixed in with its stock demo games.

Problem

The SDK could no longer be updated cleanly from upstream, and every game's history was tangled with vendor code — and with every other game.

Decision

Keep both vendor SDKs as clean, upstream-tracked copies. Give each game its own repo under a studio folder, attached to the SDK only by symlink, with its frontend as a sibling repo.

Outcome

Simulation, tests and publishing run unchanged; an SDK update is a fetch and merge; each game has its own clean history and its own collaborator access.

Retrospective

Local bug fixes had already landed in the vendor core before the split — diff before resetting a "vendor" copy to upstream.