Where "How It Works" explained what the platform is and why you are not locked in, this document explains the machine room: what is actually running, where it runs, and how a change becomes live. Written for the people who will operate the platform — no supplier jargon, no internal references.
The entire Guinness suite — a front-door shell plus ten applications and an in-house data engine — runs on one dedicated server that Guinness owns. On that server, an open-source control panel (Coolify) builds each app from an on-box code vault (Gitea) and runs it in its own container; a single routing layer (Traefik) terminates HTTPS and routes each Guinness web address to the right app. There is no external dependency at runtime — code, build and serving all live on this one machine — which is exactly what makes a clean handover to Guinness possible.
One Hetzner Cloud server in Germany runs the whole suite. Nothing on it is proprietary to the supplier: a stock Linux operating system running standard containers. On it, Coolify — an open-source, self-hosted platform-as-a-service — orchestrates everything via Docker: it builds each app from the on-box code vault and runs it as a container, managing settings, domains, and TLS. Coolify is to this deployment what a cloud platform is to a cloud-hosted app — but self-hosted, so it belongs to Guinness.
All application source code and history lives on a self-hosted code vault (Gitea) running on the box — the blueprints, kept on-site. The model is two lines per app: a supplier line (a read-only mirror of what the supplier ships) and a Guinness line (what actually deploys). Supplier updates arrive on the mirror for visibility and are applied to the Guinness line deliberately — a conscious decision, not an automatic event.
guinnessgi.x-trillion.com is the front door — an Orion shell presenting a sidebar of apps, each loaded independently from its own Guinness web address. Eleven app containers run on the box, each deployed with its own address and certificate, so rebuilding or restarting one never affects any of the others or the shell itself.
| App | What it is |
|---|---|
| Orion (shell) | The front door — the sidebar interface that hosts all apps. |
| Athena | Portfolio cockpit — NAV, yield, duration, holdings, P&L, and compliance checks. |
| Lexa | Sovereign credit research — deep country reports, served via API. |
| Iris | Interactive investment guide — the GGI AI Hub for staff and clients. |
| Jess | Narrated video briefings — market and fund commentary, with its own access control. |
| Jules | Compliance and brand audit — deck and factsheet review, slide generation. |
| Maia | Execution airlock — the bridge between Athena and order execution. |
| Iona | Wealthy Nations Bond Fund voice briefings — audio-first fund commentary. |
| Georgia | Sovereign ESG Scorer — live World Bank data, password-gated. |
| Brian | The in-shell help agent — context-aware guidance across all apps. |
| Data engine | Guinness's in-house data engine — sovereign data, Haver feeds, and the path to full in-house analytics (see §5). |
The first genuinely Guinness-owned service — a lean engine that sits between the apps and their data. It serves sovereign fundamentals natively from licence-free public data (World Bank), and Guinness's own Haver subscription — a feed Guinness funds directly. For anything it cannot yet serve, it falls transparently to the interim engine, stamping every answer with its source. This is the independence model in motion: two data circuits already in-house, the rest available to bring across on Guinness's own timeline.
Access is layered by audience. Staff and clients reach the apps through a single email one-time-code login — no per-app passwords to remember. Operators (Tom & Will) access the control panel and code vault through their own authenticated dashboards. The server itself is locked to authorised keys only — no password login, no guessable entry point.
| Who | Where | What they can do |
|---|---|---|
| All staff | Front door — guinnessgi.x-trillion.com | The apps — one email one-time-code sign-in; all most users ever need. |
| Ops (Tom & Will) | Control panel — your Guinness control panel address | App status, logs, restart, redeploy, environment settings. |
| Developers (Will) | Code vault — your Guinness code vault address | Source code, history, branch management, and when new versions go live. |
| Machines only | In-house data engine | No login — apps call it directly over the internal network; not exposed to browsers. |
The platform was built with handover as a design goal, not an afterthought. The steps are credential actions, not migrations: nothing moves, nothing is rebuilt — access and control shift. What Guinness already owns is concrete and running today.
What runs in production is, by construction, exactly the Guinness line in the code vault — no hidden build artefact, no supplier-side dependency.