Why one program
The front door, mediation and routing, a durable queue with retry and dead-letter, the message journal and the management UI run in one program. Your identity provider, your reverse proxy and your storage stay where they are.
What you stop running
An assembled integration tier
- API gateway
- Integration runtime
- Message broker
- Log store
- Admin console
Each one installed, patched and upgraded on its own.
NexusFabric
- Front door
- Mediation and routing
- Durable queue
- Message journal
- Management UI
One program to install and patch.
- Your identity provider
- Your reverse proxy
- Your storage
The pieces in one program
- Front doorChecked before the body is read. Closed by default.
- Mediation and routingTransforms compiled at publication; routing runs exactly one arm.
- Durable queueRetry and dead-letter, on its own write-ahead log: an accepted message survives a crash.
- Message journalOne receipt and exactly one verdict per delivery.
- Management UIPages that answer each role exactly as the role table says.
Your identity provider
Stays yours, outside the program.
Written in Rust.
Four ways in, one set of delivery rules
A message can arrive over HTTP, through the queue, on a schedule or over gRPC. All four enter the same delivery path, where deduplication, correlation and response memoisation are decided in one place, not rewritten per door.
More engines, no cluster to manage
Start the same program again over the same state directory. File locks are all that coordinates the copies: no orchestrator, no consensus, no node registry.
What stays yours
- Your identity provider.
- Your reverse proxy. It terminates TLS in front of the platform, as it does for your other services.
- Your storage. More engines read and write one state directory there.