What's in the box
MessageFoundry isn't one program — it's a small toolkit arranged around the engine and its localhost API. Each tool is its own process you run on its own, and every UI is just a client of that one API. Here's the whole set.
One engine, one API, many tools
The engine is the only long-running service — and the only thing that touches the store. Everything else talks to it over the one localhost API; the tee relay sits in front.
How you run it, and what it's for
Engine service
messagefoundry serveThe headless runtime: it owns the store, runs your Connections, Routers, and Handlers through the staged queue, and exposes the localhost HTTP/WebSocket API. Everything else talks to this. Runs as a Windows service via NSSM.
Command-line tool
messagefoundry <cmd>One binary, many jobs: serve, init (scaffold a config repo), validate / dryrun / check (the commit/CI gate), connection (edit connections.toml), and generate (synthetic HL7), plus key & audit ops. The introspection commands touch no network — git hooks and the VS Code extension shell them.
Admin & monitoring console
open http://127.0.0.1:8765/uiThe operator GUI, in your browser: a connection dashboard, a message browser with each message's disposition, delivery/audit trail, and one-click replay, an HL7 parse-tree viewer, a dead-letter page, an alert-rules view, and user and session management. A pure API client — it never touches the database. Tour the console →
VS Code extension
open in VS Code → F5The authoring surface: HL7 autocomplete and validate-on-save, a New Route Wizard, a Test Bench that dry-runs .hl7 files with before/after diffs and step-through debugging, Stage → Promote to a running engine, and an optional @messagefoundry AI chat. Full tour of the editor →
Test harness
python -m harnessExercises a running engine with synthetic, PHI-free traffic: Send / Receive / File / Compose / Monitor tabs (inject ACK faults, malformed messages, delivery failures), headless CI scenarios that assert dispositions, and a separate load-testing engine with tunable profiles (warmup → ramp → soak) and an SLO report. Ships as its own distribution, released in lockstep with the engine — pip install messagefoundry-harness; it isn't part of the engine wheel.
Tee relay
python -m teeA migration de-risking tool: sit it in front of a legacy engine and a shadow MessageFoundry, ACK on receipt, and forward the same bytes to both — so you can compare output before cutover (rollback is just stopping the relay). Test and synthetic data only; not PHI-hardened. Run it from a source checkout of the engine repository — unlike the harness, it isn't published as a package.
One contract, many clients. The engine is the only long-running service — and the only thing that touches the store. The console, the extension, and the harness are separate processes that drive or observe it over that one localhost API; the tee relay sits in front. And because that one API is the only door in — the console can't import the engine or reach the store directly — authentication, RBAC, and audit sit at a single choke point rather than spread across every tool. That's the architecture, made concrete.