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
We are moving from differing services to consolidate into a monolith (flamework). Filter, then click through to the active repos.
03 · How files are served
Upload → storage → browser
Click a step for what actually happens there.
04 · Where it's hosted
Cloudflare · DigitalOcean · Krystal · Datapacket
Four providers doing very different jobs, Krystal runs VMs and Datapacket runs physical machines. Click a panel to expand it.
05 · The part underneath everything
Kubernetes itself
Five Rancher-managed clusters with the Flux Operator layered on top. Namespaces split by concern, not by team, 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, kyverno, keda, nginx-gateway, reloader, temporal, varnish-operator, monitoring, and clickstack-otel-collector.
06 · 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, never a HelmRelease. Only nexus-api's manifests are pulled from an OCI artifact registry; every other app's Kustomization points straight at a GitRepository for its own repo. Helm is reserved entirely for shared infrastructure: cert-manager, KEDA, the Datadog Operator, and friends.
Nexus-Mods/auto-devops ↗Ingress is retired. Canary was tried and stopped.
Every app now routes through Gateway API (NGINX Gateway Fabric) across all 5 clusters; the old ingress-nginx controllers are gone. Progressive delivery via Flagger was piloted on the e2e cluster only and isn't referenced by any cluster today. Deploys are plain Flux image-automation rolling updates everywhere.
Nexus-Mods/devops-fluxcd ↗07 · Under the hood
Redis, RabbitMQ & Galera, operationally
Redis isn't one thing here, it's two topologies solving two different problems. RabbitMQ is the cross-service event backbone, not a job queue. Galera is the multi-master MySQL cluster still taking live writes, at a different provider entirely.
08 · Edge & caching
CDN configuration
Four caching layers between a browser and an origin pod, and three open architectural questions.
Open questions
Three things worth watching here
Running a second, self-managed edge tier on top of Cloudflare buys rate-limiting control, but it also means three caching layers that don't automatically agree with each other.
09 · Where the numbers come from
Analytics & BI
A layer that sits outside every provider in section 04, separate from Datadog, which is operational monitoring, not analytics.
10 · Confidence
The daily E2E run
A nightly rebuild, a Playwright matrix, and a known fixture-fragility problem.