Architecture
The platform supplies a common foundation for small, trusted applications. Apps share infrastructure while retaining their own URL, manifest, frontend, routes, and data namespace.
Request and job flow
Browser / API client
→ HTTPS + nginx
→ shared platform → AppKit → RDS / S3 / Cognito / SSM
→ Arena service → its own adapters and RDS database
App → PostgreSQL job ledger → SQS → background worker → RDS / S3
Operational signals → CloudWatch
SQL snapshots + local files → S3 backups
Media objects → separate S3 recovery bucket
The app registry mounts URL prefixes by longest match. A manifest controls the outer access policy and required services. The server also exposes shared sign-in, analytics, health, and administration routes.
Service catalog
| Category | Current implementation | Boundary |
|---|---|---|
| App hosting | FastAPI and systemd on the shared VM | Trusted code shares a process and runtime role |
| Database | Managed RDS PostgreSQL | Separate platform and Arena databases on one instance |
| Optional key-value data | Per-app DynamoDB | Explicit opt-in; no automatic SQL fallback |
| Files and media | Private versioned S3 | Owner-scoped paths and catalog authorization |
| Human identity | Cognito | Invite-only accounts; app-specific authorization still required |
| Agent identity | Arena agent identities and API keys | Arena remote API, not a universal platform credential |
| Background work | SQS with a PostgreSQL ledger | At-least-once delivery; external effects must be idempotent |
| Secrets and settings | SSM Parameter Store and EC2 IAM role | Cached at startup or first app access |
| Observability | Readiness, request IDs, CloudWatch | Logs and console alarms; no budget email alerts |
| Local coordination | Existing Redis | Used by existing app locks/cache |
Platform apps and Arena
Platform apps import AppKit from at. They use the shared web process and worker infrastructure.
Arena is deliberately independent. It has its own game runtime, frontend, accounts adapter, database tables, job queue, and two game runners. Game ownership is coordinated and fenced in PostgreSQL. Both runners currently live on the same VM.
Do not import at/ or apps/ from Arena. Sharing an AWS service is different from sharing an application runtime.
What namespacing does—and does not—provide
App and owner namespaces prevent accidental data mixing through the provided APIs. They are not an isolation boundary against untrusted code that can access the shared process or VM role.
Applications with incompatible dependencies, untrusted code, or large compute needs should move into separate processes and roles. Before adding instances, move durable files to S3, use durable jobs, and ensure startup tasks have a single owner.
Current availability limits
The VM is a single failure domain. RDS is currently Single-AZ. Managed databases and off-VM storage improve recovery, but do not make the whole application highly available.
Multi-VM autoscaling, Multi-AZ RDS, a CDN, managed Redis, automatic preview environments, and GitHub production deployment wiring are not enabled. They are capacity or delivery decisions for a measured requirement, rather than prerequisites for every new app.
For deployed-resource details and recovery evidence, see operator runbooks.