Early Access · beta. Help test and shape the 1.0 release. Where the project stands →

MessageFoundry™
Self-hosted

Run the interface engine in your environment

MessageFoundry runs on your servers or in your private cloud. You manage the message store, encryption keys, network, and destinations your interfaces connect to.

Get started Security & PHI →

What self-hosting means in practice

You control the message store and destinations

You install and operate the engine in your environment.

  • No vendor-hosted message processor is required. You choose the destinations your interfaces connect to.
  • The engine does not send message contents as telemetry.
  • You hold the keys — message bodies are encrypted at rest with AES-256-GCM in your store.

Runs where your data lives

Run the engine in a data center, virtual machine, or private cloud account.

  • Installs from PyPI — pip install messagefoundry, on Python 3.14+.
  • Zero-config on SQLite, scaling to PostgreSQL or SQL Server for production.
  • Runs headless, including as a long-lived Windows service; one config repo drives every environment.

Secure by default

  • TLS enabled by default (TLS 1.2+, incl. MLLP-over-TLS); plaintext is supported for endpoints that can't do TLS, within your secure network perimeter.
  • Authenticated & audited — local accounts, MFA, Active Directory, RBAC, and a tamper-evident audit trail.
  • Built to recognized standards — NIST SSDF, the HIPAA Security Rule (800-66), and an OWASP ASVS Level 3 self-assessment. See the evidence →

No lock-in, no per-interface fees

  • Open source under AGPL-3.0 — read every line, run as many interfaces as you like.
  • No cloud subscription and no per-interface licensing — your interfaces are plain Python in your own repo.
  • A low-cost commercial license is available from MessageFoundry, LLC when copyleft terms don't fit. Licensing →

Deployment topologies at a glance

Four pictures show which processes run on which host, and which network hops are encrypted. A dashed arrow is a network hop. A frame is one host, except in the TLS picture, where each frame is one case.

Single node

The engine, its API, and the web console run in one process on one server. The message store is a local SQLite file.

Deployment topology: single node One engine host runs the engine as a Windows service. The API and web console live in the same process and listen on 127.0.0.1 port 8765, with sign-in required. The operator browser on that host reaches the console over HTTPS and WSS on loopback. The message store is a local SQLite file, with no network hop. A sending system and a receiving system connect over MLLP, shown with tls = true set on each Connection. The engine forwards its log to a collector on another host by syslog over TLS. ENGINE HOST same process HTTPS and WSS on loopback Sending system MLLP with tls = true Receiving system MLLP with tls = true Engine messagefoundry serve, as a Windows service API and web console 127.0.0.1 port 8765 sign-in required Message store SQLite file no network hop Operator browser web console at /ui Log collector syslog over TLS

Message store on a remote database

The engine connects to SQL Server or PostgreSQL on another host. A deployment uses one of them, not both.

Deployment topology: message store on a remote server database The engine runs on the engine host. The message store is a SQL Server or PostgreSQL database on a separate database host. The engine opens the connection. By default the hop is encrypted and the server certificate is verified. ENGINE HOST DATABASE HOST encrypted by default, server certificate verified Engine messagefoundry serve Message store SQL Server or PostgreSQL

Who terminates TLS for the API

By default the engine serves TLS itself. Behind a declared reverse proxy, the last hop is plaintext unless you also set a certificate. The engine starts only after you acknowledge a plaintext hop.

Deployment topology: who terminates TLS for the API Two cases. By default, a browser or API client connects over HTTPS and WSS to the engine API. The engine serves TLS itself, with an operator certificate or with a self-signed pair it creates on first run. With a declared reverse proxy, the client connects over HTTPS and WSS to the proxy, which terminates TLS. The hop from the proxy to the engine API is HTTP and WS, plaintext by design, and the site secures it. That hop is HTTPS instead when the operator also sets a certificate. In that case the engine creates no certificate and trusts forwarded headers only from the listed proxies. DEFAULT: THE ENGINE SERVES TLS DECLARED REVERSE PROXY HTTPS and WSS HTTPS and WSS HTTP and WS, plaintext by design your site secures this hop Browser or API client Engine API operator certificate, or a self-signed pair created on first run Browser or API client Reverse proxy terminates TLS Engine API creates no certificate, trusts forwarded headers only from listed proxies

Web console from another machine

An operator opens the console in a browser, with no client to install. Remote access is off by default and needs an operator certificate.

Deployment topology: web console from another machine A browser on an operator PC connects over HTTPS and WSS to the API and web console on the engine host. The API listens on a non-loopback address, port 8765, with an operator certificate and sign-in required. The API and the engine are the same process. OPERATOR PC ENGINE HOST HTTPS and WSS, operator certificate same process Browser no client to install API and web console at /ui non-loopback listen address, port 8765 operator certificate, sign-in required Engine messagefoundry serve

The partner systems connect over MLLP with tls = true, which you set on each Connection in the engine. The deployment and network exposure guide in the engine repository has the settings and the startup checks for each picture.

Your team manages the host, network, access, keys, backups, and recovery. Review the security responsibilities →

Get started HL7 interface guide View on GitHub ↗
Keep reading

Related guides

HL7 interface guide

Migrating off a legacy engine

All guides & tutorials
FAQ

Frequently asked questions

Is MessageFoundry self-hosted?

Yes. Install the engine on your servers or in your private cloud. It starts with SQLite and also supports PostgreSQL and SQL Server. You control its network connections and message destinations.

What does PHI-safe mean?

You operate the engine and message store on your infrastructure, and control its destinations. Message bodies are encrypted at rest with AES-256-GCM. The engine does not send message contents as telemetry.

Can I run MessageFoundry on-premises or in my own private cloud?

Yes. Run it in a data center, virtual machine, or private cloud account. It can run as a long-lived Windows service. One configuration repository can serve test, production, and other environments.

Does MessageFoundry support a HIPAA-compliant deployment?

MessageFoundry supports your deployment with TLS defaults, encrypted message bodies, authenticated access, and audit records. Controls map to the HIPAA Security Rule through NIST 800-66. Your organization remains responsible for its environment and compliance program. Plaintext transport exceptions require a secure network perimeter.