There is a full 3D RPG running in the browser at packetfall.io. Three character classes, ten provinces, fifty-three dungeons, a ranked PvP arena, and boss fights where the boss is a broken router configuration you have to fix in a live CLI. Every enemy encounter is a real certification exam question. Answer correctly and you strike. Answer fast and you hit harder.
It takes real payments through Stripe and carries real uptime expectations. I designed, built, and operate the entire thing alone.
This post is not about the game. It is about the part a fellow engineer would actually want to inspect: the architecture that lets one person run a production SaaS, with authentication, billing, cloud saves, live multiplayer presence, and transactional email, for roughly the cost of a streaming subscription.
What Packetfall Is
Packetfall turns two certification blueprints, Cisco CCNA 200-301 and CompTIA Network+ N10-009, into a fantasy RPG. The study material is the combat system. Over 1,200 exam-style questions power the encounters, and the hardest bosses drop you into a command-line lab where you troubleshoot a live configuration under pressure, exactly the skill both exams are trying to measure.
The first province of each track is permanently free. A subscription unlocks everything else. There is a team plan with a manager dashboard for schools and training programs. It is a real business with a real pricing page, not a portfolio demo.
I built it because I hold the CCNP and passed these exams the traditional way, with flashcards and PDFs and willpower. I kept thinking the material deserved a better delivery mechanism. Then I decided to stop thinking about it and ship it.
The Architecture
The client is vanilla TypeScript with Three.js for the 3D world. No framework. The game state is local-first: your campaign lives in localStorage and syncs to a cloud save when you log in. That one decision removed an enormous amount of backend surface area, because the server does not need to track gameplay in real time. It needs to store saves, verify subscriptions, and relay presence.
Everything server-side is AWS, and all of it is serverless:
Hosting S3 + CloudFront + Route53
Auth Cognito, verification email via SES
Compute Lambda (Node 20) microservices:
subs · Stripe checkout, webhooks, cloud saves, teams
presence · WebSocket relay (position, chat, duels)
names · unique display names
analytics · funnel counters
APIs API Gateway HTTP APIs + one WebSocket API
Data DynamoDB (saves, subscriptions, teams, analytics)
Billing Stripe hosted checkout, secrets in SSM Parameter Store
IaC Terraform for every resource
CI/CD GitHub Actions with OIDC · no long-lived AWS keys
push to dev → isolated staging environment
push to main → terraform apply → test → build → deploy
There are no servers to patch, no instances idling overnight, and no capacity planning. Lambda scales to zero when nobody is playing and scales up without my involvement when people are. DynamoDB does the same. The static world assets are cached at CloudFront edge locations, so the heaviest part of the product, the 3D game itself, barely touches the origin.
The whole system costs about $10 a month to operate.
Cost is an architecture decision, not an accounting detail. Every choice in this stack was made by asking what the requirement actually was, not what the impressive answer would be. A WebSocket relay on Lambda sounds less exciting than a fleet of game servers. It is also two orders of magnitude cheaper, and for this workload it is the correct call. Knowing when the boring answer is the right answer is most of what cloud architecture is.
What Operating It Taught Me
Webhooks are where billing systems live or die. Stripe checkout is easy. The hard part is the webhook that flips a subscription status in DynamoDB, because it has to be idempotent, verified, and correct even when events arrive late or twice. Getting that flow production-grade taught me more about distributed state than any tutorial could.
Email is infrastructure. Cognito verification codes go out through SES, with an automatic fallback provider if SES fails, because a signup email that never arrives is indistinguishable from a broken product. Inbound support mail flows through SES to S3 to a Lambda that forwards it to me with the sender preserved in Reply-To. Nobody notices email infrastructure until it fails, which is exactly why it deserves design attention.
GitOps with OIDC eliminates a whole class of risk. The deploy pipeline authenticates to AWS through GitHub's OIDC provider. There are no access keys stored anywhere, nothing to rotate and nothing to leak. Every push to main runs Terraform, the test suite, a TypeScript gate, and an end-to-end browser pass before anything reaches production. The promotion from dev to main includes a zero-drift check so the environments cannot silently diverge.
One person can operate a real system if the system is designed to be operated by one person. That constraint shaped everything: serverless over servers, managed services over self-hosted, local-first state over session infrastructure, a daily automated ops report instead of a dashboard I would have to remember to check. Operability was a requirement from day one, not a retrofit.
Why This Is on My Portfolio
My background is enterprise networking. My certifications are the CCNP and the AWS Solutions Architect Associate. Packetfall is where both sides of that resume converge: the content is networking, taught at certification depth, and the delivery is a cloud architecture I designed against real constraints of cost, scale, and single-operator maintenance.
Labs prove you can build something once. A product proves you can keep something alive: through billing edge cases, email deliverability, dependency updates, and the unglamorous work of operating what you shipped. That second skill is the one production teams actually need.
The first province of each certification track is free, forever. See what a serverless production game feels like, or study for your CCNA while you are at it.
Play Packetfall