open-meridian/meridian-core

The runtime of Open Meridian, the open-source
OEMS, in Rust. It is what runs in your own environment, beside your own
database: the message bus, the stores, the conductor, the dashboard people
sign in to, and one sidecar per plugin. Traders build their own tools on it
with AI agents, and developers write their bots and analytics against it.
## Start here
The documentation is at open-meridian.dev.
Install the command line, then follow INSTALL.md, which walks
the whole path from registering a deployment on the platform to signing in:
sh
curl -fsSL https://raw.githubusercontent.com/open-meridian/meridian-cli/main/install.sh | sh
meridian doctor
meridian up --id DEP-… # with the enrolment code from open-meridian.com
meridian connect
A laptop cluster is enough to try it (Rancher Desktop, k3s, kind or Docker
Desktop). meridian up installs the chart,
oci://ghcr.io/open-meridian/charts/meridian-runtime;
deploy/chart/README.md says what each of its values
does, for the files meridian up -f takes.
To write a plugin, meridian plugin new starts one from the Python SDK's
reference plugin (meridian-python).
On a deployment installed with meridian up --development, meridian plugin
dev runs it as you write it, each save running in about a second; the
plugin's AGENTS.md teaches any coding agent that loop. See
meridian-cli.
## What runs
dashboard -- the one address a firm's staff use. It signs people in
through the firm's directory (OpenID Connect or LDAP) or through accounts it
holds itself, runs the first-run wizard, Settings (where a deployment admin
authors accounts, groups and permissions and manages each plugin) and a
lost-password reset with a code from the platform, and serves each plugin's
page on its own name, .plugins. , with the plugin UI kit
(meridian-ui) at
/.meridian/ui/ / on every host. A browser's session is held in
memory; a terminal's (meridian connect) in the database, so it survives a
restart or an upgrade.
conductor -- the only component holding the deployment's key, and so the
only one that reaches the platform. It also holds the configuration store:
accounts, who may reach what, and plugin settings, as a deployment admin
authors them. There is one conductor; redundancy means a standby, not a
second one.
instrument store -- what this deployment knows about instruments, and the
answer to every instrument question, locally. For identity it holds a copy of
what the platform publishes, so a deployment keeps working through an outage
of the platform it pulls from.
street store -- what custodians say is held: statements, holdings,
custodial positions. The one store whose contents nothing can rebuild.
sidecar -- one per plugin, bound to loopback, holding that plugin's broker
credential and enforcing its grants. A plugin reaches its sidecar and
nothing else.
launcher and registry -- the deployment's own catalogue of plugin
versions, and what runs an approved one.
broker -- NATS, carrying the bus, with permissions generated from the
grants rather than written by hand.
Setting a deployment up also runs the first-run job, which holds the
narrow rights the wizard's answers need, and the key and migrate jobs.
The key is generated by the conductor and never leaves it; the platform holds