Architecture map
The shape of the
Nexus Mods stack.
Where the apps live, how a file gets from an upload to the user's machine, which cloud owns which box, and how a commit turns into a running pod.
01 · Why any of this exists
The mission
Every consolidation, retirement, and rewrite in this map traces back to our Nexus Mods' strategy
We are building the OS for UGC across gaming.
Give gamers the freedom to shape their experience, empower creators to share their vision and get rewarded, starting with modding. The bar: Spotify ease for aspiring modders
The flywheel: network effects, one loop
Five habits that turn the mission into engineering decisions
02 · What runs
Applications in the stack
The web stack lives in the flamework monorepo under apps/*. Filter, then click through to the app directories.
03 · How files are served
Upload → storage → browser
Click a step for what actually happens there.
04 · Edge & caching
CDN configuration
Three caching layers between a browser and an origin pod, and three open architectural questions.
Open questions
Three things worth watching here
Two caching layers that don't automatically agree with each other.
05 · Where it's hosted
Cloudflare · DigitalOcean · Krystal · Datapacket · Elastic Cloud · CloudAMQP
Six providers. Click a panel to expand it.
06 · The part underneath everything
Kubernetes itself
Five Rancher-managed k3s clusters with the Flux Operator layered on top. Namespaces split by concern, and a handful of operators do most of the heavy lifting.
production everything else is infrastructure with its own namespace, including flux-system, cert-manager, external-secrets, dragonfly-operator-system, dapr-system, datadog, keda, nginx-gateway, reloader, temporal, monitoring (Prometheus/Grafana), logging (Loki/Alloy), and clickstack-otel-collector. platform-uk1 is different: it only runs arc-systems/arc-runners for CI plus the shared operators. staging-uk1 holds one namespace per review stack.
07 · Under the hood
Redis, RabbitMQ & Galera, operationally
Redis is two topologies. RabbitMQ is the cross-service event backbone. Galera is the multi-master MySQL cluster taking live writes, hosted at Krystal.
08 · Ship it
Linear, GitHub, Flux
The pipeline every change travels through, from issue to running pod.
Kustomize ships apps. Helm is infra-only.
Every app deploys through a Flux Kustomization. Each app's manifests arrive as an OCI artifact that CI pushes to GHCR (ghcr.io/nexus-mods/<app>-manifests). Images pull through Harbor's Docker Hub proxy. Helm is reserved for shared infrastructure: cert-manager, KEDA, the Datadog Operator, Loki, Unleash, pgcat and friends.
Gateway API.
Every app routes through Gateway API (NGINX Gateway Fabric) across all 5 clusters; HTTPRoutes hit the pods directly. Deploys are Flux image-automation rolling updates. Shipping to one production cluster first is a manual pause of that cluster's Kustomization plus a Cloudflare LB weight change.
Nexus-Mods/devops-fluxcd ↗/deploy on a PR and a Flux ResourceSet on staging-uk1 materialises a per-branch namespace with the full stack (rabbit, redis, postgres, mysql, ES, mailhog, all eight apps at :latest, the PR's app pinned to its SHA). SteamDB's Millhaven stack is included for its own PRs. Closing the PR prunes it. The directory lives at cluster.nexdev.uk ↗, behind Cloudflare Access with a WARP profile for staff.
09 · Where the numbers come from
Analytics & BI
A layer that sits outside every provider in section 05.
10 · Confidence
The daily E2E run
A nightly rebuild, a Playwright matrix, and a known fixture-fragility problem.