Server Survival: a browser tower defense game that teaches cloud architecture

The problem Server Survival solves for engineers learning cloud architecture

Reading about circuit breakers and cold starts does not build intuition for when they matter. Server Survival compresses those trade-offs into a 3D tower defense loop: you place infrastructure nodes, traffic arrives in colored streams, and you survive as long as possible while managing Budget ($), Reputation (%), and Service Health. The README frames the player as a Cloud Architect whose mission is to handle increasing traffic loads while fighting off DDoS attacks. It is aimed at developers, DevOps engineers and students who already know what a load balancer is but have never watched a fleet scale out under pressure. The teaching is mechanical rather than textual: a Monitoring node unlocks a live metrics dashboard (RPS, error rate, latency sparklines), and the README states that Level 15 makes you fly blind without it first. That is a design choice worth noting. Observability is not a checkbox you tick for compliance; in this game it is the thing that tells you which node is dropping requests, and the failure-reason badges on each dropped request say why (no route, capacity, read-only replica, search-only index).

How the simulation models auto-scaling, circuit breaking and GPU batching

The simulation runs on a small set of interacting rules. Compute fleets scale out at 70% utilization and back in at 30%, but new instances need warmup time, and the README notes Containers even more so. That single constraint is the source of most difficulty: traffic arrives faster than capacity warms. Queue-fed fleets scale on queue pressure rather than CPU, so a backlog triggers scale-out even when processors look idle. Overloaded downstreams trip a circuit breaker at a 50% error rate over a rolling window, traffic is retried with backoff, and single points of failure get flagged. Multi-region failover is modeled through GeoDNS, which splits traffic across independent regional stacks; region-outage events exist to show why one region is never enough. The AI layer adds a different cost model. The GPU Cluster batches INFERENCE requests (up to 8, 12 or 16 by tier) into one job that amortizes a fixed per-batch cost, so profit depends on utilization: a full batch prints money, a half-fed GPU bleeds its $60/min upkeep. A GPU loads its model for 12, 20 or 30 seconds before serving anything, and every tier upgrade reloads it. Bigger models answer better, with bad-answer risk falling from 10% to 4% to 1%, and each bad answer costs 0.5 reputation. The Inference Gateway buffers for warming or busy GPUs but expires anything older than its 6s deadline, so a stale generation is failed honestly rather than served. Power is a separate ceiling: the grid carries 8 kW, every GPU draws 6, and a Substation adds 6, so the fleet's limit is bought in watts before it is bought in dollars.

Playing Server Survival: no build step, just a browser

The game has no build step. According to package.json, it is served raw from the repository by GitHub Pages, and everything in that file is optional contributor tooling for linting, tests and CI. The README's primary call to action is a PLAY NOW badge pointing at the hosted URL. Open it in a browser and the game starts; there is nothing to install for players. The README lists the hosted URL as https://pshenok.github.io/server-survival/, and the repository root contains index.html, game.js, style.css and the src/ directory, so the game files can also be served from a local checkout.

If you want to run the contributor checks locally, clone the repository and use the npm scripts defined in package.json. The package is marked private, so it is not published to a registry.

git clone https://github.com/pshenok/server-survival.git
cd server-survival
npm install
npm run check

The check script runs eslint followed by vitest, and the devDependencies list eslint, vitest, happy-dom, globals and @eslint/js, with a vitest.config.mjs at the repository root. For a first real session, start in Sandbox rather than Survival. The README describes Sandbox as a free-play lab with any budget, any traffic mix and no game over, and all 26 services are available. Place a Firewall, a Load Balancer and a Compute node, then watch the metrics dashboard once you add a Monitoring node. That sequence shows the cold-start delay before you have to survive an escalating traffic curve.

Where Server Survival breaks down as a teaching tool

The numbers are game balance values, not measurements from a real cloud. A Compute node costs $60 with capacity 4 and $12/min upkeep; a GPU Cluster costs $300 with $60/min upkeep. Those ratios exist to make the game tense, not to predict your AWS bill. Anyone who walks away thinking a GPU costs sixty dollars a minute in production has learned the wrong lesson. The README also does not document rollback or a versioned upgrade path for the game itself. Releases exist (v3.0.0 is labeled The Education Release), but the README does not explain how to pin an older version or what changed between them, so a classroom cannot easily freeze a known-good build. The simulation is also deliberately narrow. It covers front door, compute, data and AI serving concepts, but the README does not mention Kubernetes, Terraform, CI/CD pipelines or IAM policy, which are large parts of day-to-day cloud work. If your goal is to learn a specific vendor's console or a specific IaC tool, this game will not get you there. And if you want a Minecraft survival server, this is the wrong project entirely; the name collides with a very different search intent.

Server Survival versus Datacenter Survival: logical layer and physical layer

The README points to a sister game, Datacenter Survival, by the same author. The split is explicit: Server Survival teaches the logical layer of the cloud, while Datacenter Survival teaches the physical layer it runs on, including power chains, heat, cooling and PUE. That is a real difference in approach rather than a reskin. In Server Survival, power appears as one constraint (the 8 kW grid, 6 kW per GPU, Substations adding 6), but the focus is on traffic routing, scaling policy and service health. In Datacenter Survival, the physical infrastructure is the subject. If you are teaching application architects, the logical layer is the right starting point. If you are teaching facilities or capacity engineers, the sister game covers ground this one does not. The two are complementary, and the README presents them that way.

Licence, maintenance and the cost of keeping a fork current

Server Survival is MIT licensed, which permits reuse, modification and redistribution with the licence and copyright notice preserved. That is permissive enough for classroom use and for forking into a custom exercise. The repository is not archived, and the last push was on 2026-09-21, one day before this writing, so the project is being touched. The release history shows v3.0.0 on 2026-07-28, labeled The Education Release, which suggests the teaching content was expanded at that point. Upgrade cost is low for players because there is nothing to install; the hosted URL always serves the current main branch. For contributors, the toolchain is small: eslint, vitest, happy-dom and globals. There is no build step to break and no transpiler to keep in sync. The main maintenance risk is that the game is served raw from main, so a breaking change lands for everyone at once. A fork that pins a commit is the only way to freeze behaviour, and the README does not describe that workflow. This is general information about the licence, not legal advice.

Editorial conclusion

Adopt Server Survival if you want a hands-on way to feel why auto-scaling needs warmup time, why a half-fed GPU bleeds $60/min, or why a queue-fed fleet scales on queue depth rather than CPU. Do not adopt it as a capacity-planning tool: the numbers are game balance values, not vendor benchmarks, and the README does not document rollback or a versioned upgrade path. Before you rely on it in a classroom, open the Campaign chapter that matches your syllabus and check the debrief text for the concepts you intend to assess. The game itself has no build step; the npm scripts are contributor tooling only.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. pshenok/server-survival on GitHub
4. README
5. Releases