Platform architecture · 23 Aug 2026
One codebase, two products, and one installation per broker. The drawings below show what talks to what, which way each conversation starts, and where a broker's data is and is not allowed to go.
Provisioning is a single pass through one screen — brokerage name, the components they bought, the term — and it returns the licence, the install key and the exact command their engineer pastes onto a clean machine. A pass that cannot be completed writes nothing at all, so there is no half-provisioned broker who is unable to install.
Two things this path used to get wrong, now closed. The installer carried constant credentials that the setup guide published — every installation opened with the same admin password. Nothing constant ships now: the secrets are generated on the broker's own machine, written to a file created private before a byte lands in it, and printed once.
And a fresh installation used to answer with invented prices from a mock backend until someone remembered to switch it. It now refuses to serve clients until a real trading backend actually answers — configured is not the same as connected — while the operator surface stays up, because that is where it gets fixed. A demo installation is still possible, but it announces itself on screen rather than hiding in a config file.
Everything we ship a broker lands inside their own installation: the installer, the plugin packages, the mobile builds, and the whole documentation set — setup and plugin guides, operations manual, API reference, release notes for the version they are actually running, and a document per component they licensed.
It travels the same path as any build: published by 360, checked against its signature and digest before it touches disk, then served from the Hub's own door. A broker whose network cannot reach us still has their documentation, and anything not yet delivered is named with an offer to fetch it — never a link to somewhere else.
| Stays on the broker's own machines | Crosses to 360 |
|---|---|
| Client accounts, balances, positions, orders and history · quotes · KYC documents · support conversations · the CRM record of every client | Which components this installation is licensed to run · the signed licence itself · which builds were delivered · health and version of the installation |
That split is what lets a broker keep their regulator's answer simple: nothing about their clients or their book is held by us. It is also why the licence is a signed document rather than a permission call — the platform has to keep working through an outage on our side, and it does, on the dates inside the document.
| Repository | Ships | Runs where |
|---|---|---|
HonorProCore |
Terminal (web and mobile), gateway, MT5 plugin bridge, copy engine, admin shell, brand layer | Nowhere on its own — vendored into both products at a pinned version |
HonorPro360 |
Licence authority, component catalogue, tenant registry, build publishing, provider console | Our infrastructure, alongside our own brokerage |
HonorProHub |
Installation console, agent, delivery, licence client, bundled CRM, branding | Each broker's own machine, one installation per broker |