Own projectInfrastructure2026

Aim Duel platform

A real-time service, built and operated end to end on Kubernetes

Role
Sole developer: I did the design, implementation, testing and documentation
Status
Own project · live, single replica
Stack
Node.js · Socket.IO · React · Kubernetes · Argo CD · GitHub Actions · Kustomize · cert-manager · Prometheus · Grafana
Fig. 05 · Aim Duel platform, schematic. Build → Pin → Sync → Serve → Observe

00 · Summary

A real-time multiplayer game chosen deliberately as an awkward workload for Kubernetes, with long-lived WebSockets and in-memory match state. It is deployed and operated on a self-managed cluster through GitOps.

01 · The problem

Request/response apps hide most deployment mistakes. Persistent WebSocket connections, live timers and in-memory state do not: readiness, graceful shutdown and replica strategy all have visible consequences for players mid-match.

02 · The idea

Build the workload and the platform together, and write down trade-offs instead of hiding them, including why it runs as a single replica until match state moves to a shared store.

03 · How it works

  1. 01

    Build

    GitHub Actions builds an OCI image and pushes it to GHCR, tagged with the commit SHA.

  2. 02

    Pin

    CI bumps the Kustomize image tag in Git. It holds no cluster credentials.

  3. 03

    Sync

    Argo CD applies the change automatically, prunes and self-heals drift.

  4. 04

    Serve

    ingress-nginx with cert-manager TLS for HTTPS and WSS.

  5. 05

    Observe

    Private Prometheus metrics, scraped via ServiceMonitor, with a Grafana dashboard as code.

04 · The hard part

Shutting down cleanly, and saying what it costs

Separate readiness and liveness probes, with readiness that understands draining. On SIGTERM the server drains in two phases, with a hard bound inside the pod’s grace period. With one replica, a deploy still ends matches in progress, and the documentation says so. The scaling path (Redis-backed state, rolling updates, a PodDisruptionBudget, HPA) is written down rather than faked.

05 · What I built

  • Node.js, Express and Socket.IO backend serving a React client from one container
  • Hardened pod: non-root, read-only root filesystem, all capabilities dropped, seccomp RuntimeDefault
  • Commit-pinned GitOps delivery with Argo CD auto-sync and self-heal
  • Prometheus metrics on a port the ingress never routes, and a Grafana dashboard shipped as a ConfigMap

06 · Results

  • Live publicly reachable over HTTPS and WSS at a.aminelg.com.
  • GitOps the same commit-to-cluster pipeline currently deploys aminelg.com.

07 · Why it matters

Delivery and operations are where software either earns trust or loses it. This is the same pipeline and hardening I would set up for a client workload, AI services included.

Need something like this built?

Describe it in your own words; no specification needed. I read every message myself and reply within two working days, often sooner.