Selected engineering work / Case study

Cloud infrastructure · AWS architecture

ArenaOps

An AWS backend that wakes on demand, reports readiness and returns to idle.

Built around one constraint: a multiplayer backend should not run all month just to stay clickable. ECS/Fargate slept at desired count zero, woke through a public control path, reported readiness to the visitor, ran its WebSocket workload, and returned to zero after the demo window. Terraform, IAM/OIDC and GitHub Actions made every change reviewable.

The source repository and Git history are private and preserved; this page carries the architecture, screenshots and cost evidence.

ArenaOps status screen reporting the backend online, the scheduled auto-stop time, and the display-name and join-code controls for creating or joining a room.
What the visitor saw. Readiness and the shutdown window come first; room controls follow.
Idle state
ECS desired count 0
Runtime
ECS/Fargate + ALB
Delivery
Terraform + GitHub Actions + IAM/OIDC
Status
Retired · evidence preserved
July 2026 cost
≈$24/month, ended at retirement

Project summary

What it is
A browser multiplayer demo whose AWS backend idled at ECS desired count zero, woke on demand and reported its state to the visitor.
What I built
The service lifecycle, the public wake and status path, Terraform-provisioned ECS/Fargate behind a load balancer, and GitHub Actions delivery through ECR.
Key engineering
Scale-to-zero with visible readiness: compute cost stopped between demos and the visitor always knew the backend’s state.
Evidence here
Screenshots, architecture and a July 2026 cost record (the ≈$24 monthly load-balancer baseline). The source is private and the stack was retired in August 2026, so no live endpoint remains.

01 · The operating problemA sleeping demo can look exactly like a broken one.

Keeping a portfolio backend online 24/7 wastes compute. Switching it off without product feedback creates a dead link and asks the visitor to diagnose infrastructure they cannot see.

The answer was not to hide the cold start. ArenaOps turned asleep, starting, online and shutdown into explicit user-facing states, and only enabled room controls after health checks passed.

02 · Service lifecycleOne operating loop, four legible states.

The historical lifecycle is the product demonstration. Each state had an infrastructure condition, a visitor-facing message and a clear transition rule.

  1. Asleep

    Zero tasks running

    ECS desired count was 0. Game actions remained unavailable and the interface explained why.

    desiredCount: 0
  2. Starting

    Wake accepted

    The Worker started ECS. The frontend polled status while the ALB waited for a healthy target.

    pending → health
  3. Online

    Room controls unlock

    Health passed and the browser established the WSS session with the FastAPI backend.

    healthOk: true
  4. Shutdown

    Return to zero

    EventBridge Scheduler stopped the service after the demo window and cost returned to idle.

    desiredCount: 0

03 · ArchitectureRuntime control and delivery stay separate.

A visitor needed low-latency lifecycle control. A deployment needed a reviewable image and infrastructure path. ArenaOps gave each concern its own lane.

Lane A

Visitor and runtime path

  1. 01Cloudflare PagesReact + Phaser frontend
  2. 02Cloudflare WorkerWake and status API
  3. 03Application Load BalancerHTTPS / WSS and health
  4. 04ECS / FargateFastAPI WebSocket service
  5. 05EventBridgeScheduled return to zero
Lane B

Build and deployment path

  1. 01GitHub ActionsOIDC-authenticated workflow
  2. 02Amazon ECRVersioned backend image
  3. 03ECS deploymentTask and service update
  4. 04CloudWatchWake, health, traffic, shutdown
Foundation

Terraform · IAM · remote state · security boundaries · health checks · operational logs

04 · Working evidenceThe operating loop is visible in the interface.

These captured live-demo screens are not a fabricated dashboard. They preserve the state before access, shown above, and the realtime room once the backend was ready.

Realtime session
ArenaOps connected multiplayer room with operator controls and the active arena view.
After target health passes, the browser exchanges room and arena events with the backend over WSS.
Why this matters

Room controls stayed disabled until the status check reported online. By the time this screen was reachable, the wake, the health check and the WSS handshake had all succeeded in order.

05 · Engineering ownershipWhat I designed and implemented.

  1. Lifecycle contract

    Defined the asleep, starting, online and shutdown states and made them part of the frontend experience.

  2. Public control boundary

    Separated visitor-triggered wake and status control from the slower deployment workflow.

  3. Cloud delivery

    Provisioned infrastructure with Terraform, authenticated GitHub Actions to AWS through IAM/OIDC, and delivered backend images through ECR to ECS.

  4. Failure-aware operations

    Worked through IAM scope, CORS, ALB target health, Scheduler payloads, WebSockets, logs and remote state.

06 · Retirement decisionStop paying when the lesson is already proven.

Scale-to-zero eliminated idle Fargate compute, but July 2026 still produced about $24.25 in ArenaOps-only baseline charges, almost all of it the load balancer and its public addresses.

The AWS stack was removed through its reviewed Terraform state boundary. The application source, infrastructure definitions, workflows, Git history, documentation and working screenshots were preserved, so the project keeps its portfolio value without recurring runtime cost.

07 · BoundariesA focused cloud demo, not a production-scale platform.

  • Cold-start delay was deliberate and communicated.
  • HTTP 503 while asleep was expected behavior.
  • No high-availability or production-traffic claim is made.
Technical index

React · TypeScript · Phaser · FastAPI · WebSockets · Docker · ECS/Fargate · ALB · ECR · IAM · EventBridge Scheduler · CloudWatch · Terraform · S3 remote state · GitHub Actions · Cloudflare Pages · Cloudflare Workers

Next: Food Checker, a label scanner with a full delivery path.