Nexus explainer · companion to One host, many tenants
Nexus is served two ways. The platform runs on two dedicated bare-metal servers that I run from the operating system up: one for production, one for CI and compute. The public side, this website and the live markets site, runs on a small cloud server built from code with Pulumi and Docker. A private WireGuard network joins them, and no service on the production server is open to the public internet. This page covers the hardware, how each machine is built and changed, and the security baseline behind them.
Hardware from each server's setup record, August and September 2026. SSH methods probed from outside each server on 2026-10-30.
The internet reaches one machine, the edge. The production server opens its own connections outward, to the broker, the data vendors and the offsite store, and accepts connections only from inside the private network.
AMD Ryzen 7 7700 · 8 cores, 16 threads 64 GB DDR5 4 × NVMe in software RAID 10 Ubuntu 26.04 LTS · UTC · NTP
Runs the market database, live price capture, trading, the APIs, scheduled jobs and the AI agents' sessions. Every service is a systemd unit in a cgroup slice, so the database and trading keep their share whatever else is running. The APIs listen on loopback only, with nginx in front. One host, many tenants shows how the server is shared.
AMD Ryzen 7 7700 · same model as production 64 GB DDR5 2 × NVMe in software RAID 1 Ubuntu 26.04 LTS · UTC · NTP
Runs self-hosted CI runners, including the heavy numerical test lanes. The processor matches production on purpose: numerical libraries pick their code path from the CPU, so tests that compare results to the bit pass here just as they would in production. It holds no production data by design, so a job pointed at the wrong server fails instead of reading old numbers.
Cloud VPS · built with Pulumi Ubuntu 24.04 LTS nginx · Let's Encrypt · Docker Compose cloud firewall and host firewall
The only machine that answers the public internet. nginx serves this website and the live markets site over HTTPS, and Docker Compose runs the alert hub that relays production's failure alerts to Slack. The server, its cloud firewall and its first-boot script are a Pulumi program in Python.
What a server runs lives in git. The edge is declared in Pulumi. The bare-metal servers are built from scripted runbooks, and their unit files, nginx sites and policies are installed from repositories rather than edited in place.
Infrastructure as codePulumi · Python
The edge server, its cloud firewall rules and its first-boot script are one Python program, kept with the service it hosts. Resizing is a configuration change and a pulumi up; a new region means a rebuild from the same program. The provider token is held encrypted in the stack configuration.
First bootcloud-init
On first boot the server installs Docker, nginx, certbot and Tailscale, turns on its host firewall and creates a separate deploy account, so its packages, firewall and accounts come from code.
ContainersDocker · GHCR · Compose
The alert hub is a multi-stage image. CI tests it, builds it, tags it with its commit and pushes it to GitHub's container registry, and the server then pulls it and restarts it with Compose.
Services on bare metalsystemd · cgroup v2
Every service and scheduled job is a systemd unit. On the production server every first-party system service raises an alert if it fails, and cgroup weights and memory floors keep research away from trading. Nothing sits between the trader and the kernel. Scheduled by systemd has the detail, and Nexus and Kubernetes explains why there is no orchestrator.
New serversprovisioning toolkit
A CI server is stood up by scripts that install prerequisites, register its runners and check the server again after a reboot. The provisioning scripts check a role marker on the machine rather than its name.
Deploysguarded, without sudo
Changes reach the production server through a deploy tool that runs the tests first and refuses an unsafe deploy. The AI agents' account has no sudo: it drops a request file, and a root service carries out the deploy from an allow-list. Test, merge, ship covers the pipeline.
Moving hardwareplanned cutover
In August 2026 the whole production estate moved to new hardware in three planned cuts, with the old server kept frozen as a rollback until it was retired in September.
One small server takes all public traffic, so the production server doesn't have to.
A React and TypeScript app built with Vite and served as static files by nginx. HTTPS only, with Let's Encrypt certificates. Staging and live are separate sites with separate roots. Hashed assets are cached for a year, pages are checked again on every visit, and the build fails if a page shows a registered figure that is out of date.
The live markets site is served from the edge, which reads a short allow-list of read-only endpoints from production over the private network. Paths must match exactly, responses are cached at the edge and requests are rate-limited, so production sees a trickle of cache refreshes rather than visitor traffic.
Production's failure alerts go to an alert hub on the edge. It accepts each one at once and delivers it to Slack from a database outbox. It runs in Docker Compose with its own Postgres, which is backed up nightly into production's backup set over the private network. The alert path follows one message through.
The estate's security policy is structured on the NIST Cybersecurity Framework 2.0 and assessed against the SBAI's control set for smaller managers, the proportionate benchmark at this scale. Below is what each of the framework's six functions looks like on these servers. This is a self-assessment against the framework, not a certification. The scores, low ones included, are on the Assurance page.
| Govern | A written information security policy, with change, incident and patching policies alongside it. Three technology due-diligence reviews against prop-desk standards, scored on a fixed scale so they can be compared. |
|---|---|
| Identify | A setup record for every bare-metal server: hardware, disk health, RAID layout and role. A roster of every AI agent seat. The sensitive assets are named: broker credentials, vendor keys and database passwords. |
| Protect | Administration of the bare-metal servers only over a private WireGuard network. No public services on the production server. SSH keys only, with password login not offered. Role-named accounts, and service accounts that cannot log in. Service secrets kept in owner-only files outside git, and the one secret in the edge's code is encrypted. Secret scanning and dependency audits run in CI. Security updates install automatically. |
| Detect | On the production server: a failure alert on every first-party system service, delivered to Slack; a weekly check that the patching policy is still in force; system logs kept for 30 days. Host and service monitoring with its own registry of checks. |
| Respond | Trading halts and holds rather than trading through a fault, with an automatic halt and a kill switch. Containment is written down: stop the service, halt trading, revoke keys, remove the device from the network. |
| Recover | Nightly database dumps, with the trade record and the live price capture backed up every 15 minutes. A daily offsite copy in another country, checksummed when it lands and checked again as it ages. Restore drills on a schedule. Production has already moved to new hardware once, in planned cuts with a rollback held ready. |
A trading server can't take updates the way a laptop does. A reboot drops live price capture, and a package update can restart services by itself. This is how the production server is patched.
Sources: each server's setup record and the provisioning runbooks in the engineering handbook (August and September 2026); the edge's Pulumi program, Compose file and deploy workflow, and this site's nginx configuration, on their main branches; the information security, patching and continuity policies; the technology due-diligence review of 9 September 2026; the design record for public read-only access; SSH authentication methods probed from outside each server on 30 October 2026.