Your interfaces live in your git — reviewed, tested, reversible
With MessageFoundry, your integration logic isn't buried in an engine's database. It's ordinary code in your own version-controlled repository — so every change is a reviewable diff, every change is tested by CI against the real engine before it ships, and rolling back is one git command. That's what makes a small team's interfaces dependable.
These practices are in place today — but the project itself is young. MessageFoundry started in May 2026 and is in Early Access. See where it stands →
Where interface logic usually lives
On most legacy engines, a channel's filters and transforms live inside the engine's own database. That has consequences teams feel for years.
Hard to review
Logic in a database blob is hard to diff, peer-review, or reason about. Changes land without the author, history, and review that other code gets.
Drifts between environments
"Someone changed it in the Prod GUI, and now Staging ≠ Prod." Without one source of truth, environments quietly diverge.
Risky to change
No commit-time gate means a broken route or a bad transform is often found in production — and rollback means restoring a database, not reverting a commit.
Your interfaces, in a repository you own
Connections, Routers, and Handlers are plain Python in your private git repo — scaffolded by messagefoundry init. The engine itself is a pinned, signed dependency your team installs but never edits.
One reviewed commit of that repo deploys to every environment; only a small per-environment values file differs, so Test can't drift from Prod. Git is the source of truth — and it carries no secrets and no PHI (those come from environment variables, never the repo).
- Every change is a diff — reviewed, attributed, and kept in full history like any other code.
- Rollback is one command — revert the commit (or pin the engine back); no database surgery.
- One source of truth — the same modules run unchanged in dev, staging, and prod.
- A breach can't rewrite logic — routing/transform code reaches production only through a reviewed pipeline, never the data store.
Nothing merges until it passes — against the real engine
messagefoundry init scaffolds a ready-made CI workflow in your repo. It runs on every pull request and every push to main, and the same gate runs in the VS Code editor and an optional pre-commit hook — so a green CI means a green desk.
Validate
Every config module imports and every inbound → router → handler reference resolves. A router named but never defined, a dangling binding, or an import error fails the build.
Dry-run — the one that matters
Synthetic messages route through the engine's real routing core — the same function production runs — with no store, network, or connectors. Green in CI means it routes identically in production; there's no separate test path to drift from reality.
Posture
Catches the environment / security-posture foot-gun that would make the engine refuse to start — at commit time, not at 2 a.m. on the Prod box.
Supply-chain verify
Before install, CI verifies the pinned engine wheel's build provenance (SLSA / Sigstore). A swapped or relabelled wheel fails the build instead of shipping silently.
Branch protection
Make the gate a merge requirement on main: no interface change lands unless validate and dry-run are green and reviewed.
One gate, three places
The exact same check runs in the editor as you work, in your pre-commit hook, and in CI on the PR — so problems surface early and consistently.
Reliability you can see — and prove
Reviewed before it ships
Interface logic gets the same rigor as application code: branch, pull request, review, merge — with CI exercising your routes on representative traffic first.
Reversible by design
Every change has an author and a history; reverting is a git operation. Engine upgrades are a deliberate, pinned, one-line bump you can roll back.
No surprise drift
Promotion is "merge to main, deploy that commit everywhere." Environments stay in lock-step because they run the same reviewed code.
Dependable under load, too. Reliability isn't only review and rollback — it's holding up at peak. On anonymized, representative message traffic a single interface sustains about 50 messages/second with headroom — roughly 180,000 in a peak hour — every message committed to the durable store and delivered strict per-interface, first-in first-out. A busy hospital's full ADT feed is a few percent of that, so traffic doesn't back up; when you need more, you add interfaces. Measured figures, not promises: real throughput depends on your transforms, storage, and hardware. How throughput really works →
What the gate proves — and what's still on you
The CI gate proves your config loads, wires, and routes representative traffic without error, using the production routing logic. It does not by itself prove that a transform's output matches a downstream system byte-for-byte — a transform can produce valid-but-wrong HL7 and still pass.
Output parity is a separate discipline, and MessageFoundry gives you the tools for it: a synthetic test corpus you build with messagefoundry generate, the standalone test harness (disposition coverage and fault injection), and a reconciliation window (golden in/out pairs, sent-vs-delivered) before and after cutover. We say this plainly because reliability you can trust is reliability stated honestly.
Adopt interfaces you can review, test, and roll back
Scaffold a config repo with the CI gate already wired in, and run your first message in minutes.
Frequently asked questions
Is message delivery reliable?
Yes. MessageFoundry persists every message to a durable store before it is acknowledged, then routes from that store — so messages survive engine restarts and failures rather than being lost in flight.
How does MessageFoundry handle failover?
It runs active/passive: a standby instance takes over if the primary fails, coordinated by an application-level leader lease so only one instance is active at a time. Failover typically completes in about 30 seconds.
Are my interfaces version-controlled and tested?
Yes. Your interfaces live in your own git repository as plain Python, reviewed and tested by CI against the real engine — so changes are diffable, reversible, and gated before they ship.
Is a Python engine fast enough for production HL7?
Yes. Each interface sustains a measured ~50 messages per second on commodity hardware — roughly 180,000 in a peak hour — which is well above a hospital's real HL7 load, where a typical ADT feed runs on the order of a couple of messages per second. Real throughput depends on your transforms, storage, and hardware, and these figures are measured on anonymized, representative message traffic. Speed never comes at the cost of safety: every message is committed to a durable store before it's acknowledged and delivered in order, at-least-once, so a busy interface keeps up with headroom and messages aren't silently dropped.