Sedan sist: spelplattform, infra hardening och 358 AWS-resurser


Senaste portföljinlägget publicerades den 21 mars. Det här är därför inte en hel månadsrapport, utan en uppföljning tolv dagar senare, den 3 april.

Det som hänt sedan sist är inte bara att fler projekt rör sig, utan att de gör det på bättre räls: en ny spelplattform med tio brädspel, fler appar i aktiv utveckling och ett tydligare mönster för hur AWS-infrastruktur ska delas upp, låsas ner och deployas utan att GitHub Actions får makt över IAM.

Siffrorna

MätvärdeMars 2026April 2026Förändring
Commits (exkl. Paperclip)1 4021 675+273
GitHub Actions-körningar2 1762 816+640
Merges till main171226+55
AWS-resurser274358+84

Exklusive Paperclip har portföljen vuxit med 273 commits sedan mars. Det är inte en explosionsartad kurva i antal commits, men det är ett tydligt steg upp i mognad: fler projekt delar samma infrastrukturmönster, fler deployflöden är härdade och fler miljöer går att hantera utan specialfall.

84 nya AWS-resurser: 4 nya S3-buckets, 27 Lambda-funktioner, 8 DynamoDB-tabeller, 2 CloudFront-distributioner, 8 IAM-policies och 15 IAM-roller. Allt i Terraform.

Det intressanta i den här uppföljningen är därför inte bara hur mycket som byggts, utan att mer av det nu vilar på samma grund: TypeScript i spelmotorer och frontend, Terraform för infrastrukturen, OIDC för deploy, och tydligare gränser mellan lokal IAM-hantering och app-resurser som får deployas via CI.

Nytt: Games — tio brädspel, en plattform

Det helt nya projektet den här perioden. En spelplattform med delad infrastruktur och tio spel:

  • Checkers (dam)
  • Connect Four (fyra i rad)
  • Go
  • Gomoku (fem i rad)
  • Kalah (mancala)
  • Othello
  • Tic-tac-toe (tre i rad)
  • Battleship (sänka skepp)
  • Uno
  • Crazy Eights (vändåtta)

Spelportalen — alla tio spel i lobbyn

Varje spel har en egen engine med typer och tester — samma mönster: engine.ts, types.ts, engine.test.ts. En delad plattform hanterar lobby, broadcast och DynamoDB-lagring. Frontend i React 19 + Vite, backend i Lambda.

Othello — klassiskt strategispel med svarta och vita brickor

Kalah — urgammalt strategispel med stenar och gropar

Go — tusenårigt strategispel på 9x9-bräde

Chess — schack med tidskontroll

23 commits och 13 751 rader på nio dagar. Det är inte bara fart för fartens skull, utan ett kvitto på att mönstret fungerar: när varje spel följer samma struktur med engine.ts, types.ts och engine.test.ts, och när plattformen redan har lobby, broadcast och DynamoDB-lagring, går nya spel från idé till deploy utan att varje gång börja om från noll.

Det är också här perioden sedan 21 mars känns annorlunda. Games är inte ett enskilt experiment, utan ett exempel på vad som händer när arkitektur, CI/CD och innehållsarbete börjar dra åt samma håll.

Infra hardening: mindre magi, mer kontroll

En stor del av arbetet sedan senaste inlägget har handlat om att göra infrastrukturen svårare att missbruka och lättare att återanvända.

Mönstret är enkelt i teorin men viktigt i praktiken:

  • infra/iam deployas lokalt och aldrig via GitHub Actions
  • infra/app deployas via GitHub Actions, men får bara röra app-resurser
  • GitHub Actions autentiserar med OIDC-roller som är bundna till rätt repo, branch och miljö
  • roller och policies scopes till ${project}-${stage}-* så att appar inte kan kliva in i varandras resurser

Det betyder i praktiken att deployflödet får göra sitt jobb, men inte ändra sina egna rättigheter. GitHub Actions kan deploya Lambda, DynamoDB, S3 och CloudFront för rätt projekt, men aldrig skapa eller ändra IAM-roller, aldrig skriva DNS och aldrig börja öppna upp kontot bredare “för att få det att fungera”.

Det här är exakt den typ av räls jag vill ha när flera projekt lever samtidigt: mindre implicit kunskap, färre specialfall och tydligare säkerhetsgränser.

Från enstaka lösningar till standard

Det mest värdefulla i infra-arbetet är egentligen inte en enskild policy, utan att det blivit en standard.

Hardening-playbooken bygger på samma upplägg för alla appar:

  • separat state för iam/ och app/
  • en OIDC-roll per miljö
  • least privilege som utgångspunkt
  • kommenterade wildcard-undantag där AWS verkligen kräver *
  • test via assume-role och terraform plan tills varje AccessDenied är löst med minsta möjliga rättighet

Det gör att nya projekt kan få en säkrare start och gamla projekt kan migreras mot samma form. I den här uppföljningen finns nu både appar som är fullt härdade och appar som har migrerats till splittrad iam/ och app/-struktur men fortfarande har lite städning kvar.

Det kanske inte låter lika publikvänligt som ett nytt spel, men det är precis den sortens arbete som gör att portföljen kan växa utan att infrastrukturen blir ett lapptäcke.

Andra projekt som rört sig

RepoCommits (30d)Vad som hänt
familyeconomy64Rust-pipeline, fortsatt utveckling
nockeby-scout55Ledarportalen, InfoMentor-integration
umlDesigner43Publikt UML-verktyg med React Flow, realtidskollaboration, MCP och projektgruppering
planning-app37Planeringsappen, kontinuerligt underhåll
kalah15Mancala-spel, separat repo
chess10Schack med tidskontroll

Utöver Games är det särskilt tydligt i nockeby-scout, planning-app och flera mindre appar att samma deploy- och infra-mönster går att återanvända. Det gör att varje nytt projekt inte behöver uppfinna sin egen säkerhetsmodell.

Ett tydligt sidospår sedan 21 mars är också det publika verktyget umlDesigner. Det skapades 24 mars och gick snabbt från scaffold till en interaktiv UML-editor med React Flow, realtidskollaboration via Yjs/WebSocket, MCP-stöd, markdown-dokumentation per diagram och projektgruppering med sammanslagen export. Det är ett bra exempel på hur samma arbetssätt går att använda även för publika verktyg, inte bara interna eller kundnära projekt.

Infrastrukturen i siffror

AWS-resursMarsApril
S3-buckets4447
Lambda-funktioner5799
DynamoDB-tabeller4762
CloudFront-distributioner1920
IAM-policies2932
IAM-roller7898

Lambda-funktioner har gått från 57 till 99. DynamoDB-tabeller från 47 till 62. Det är Games-plattformen, familyeconomy och nockeby-scout som driver mycket av ökningen, men siffrorna säger också något annat: fler resurser kräver bättre isolering, bättre namnstandard och tydligare deploygränser. Det är där infra hardening-arbetet blir skillnaden mellan tillväxt och röra.

Vad som förändrats sedan sist

Tre saker sticker ut:

  1. Spelplattformen visar mönstrets styrka. Tio spel på nio dagar fungerar för att varje spel följer samma arkitektur: engine, typer, tester, Lambda, DynamoDB. Infrastrukturen är en template, inte ett hinder.

  2. Infra har blivit ett eget leveransspår. Att dela upp iam/ och app/, låsa GitHub Actions till OIDC-roller och dokumentera varje wildcard är inte sidouppgifter. Det är produktionsarbete som gör resten av portföljen snabbare och säkrare.

  3. Portföljen har substans. 358 AWS-resurser, gemensam infrastruktur, härdade deployflöden och flera projekt i aktiv drift gör att det här inte längre är en samling experiment. Det är en portfölj med processer, säkerhetsgränser och daglig förvaltning.

Skripten körs varje natt igen (efter en veckas uppehåll — en bugg i radräkningen fixades). Nästa uppföljning i maj.


Statistik genererad 2026-04-03 via nattliga launchd-skript.