One tenancy model across every platform
A tenant is a tenant whether it is an API gateway, a message broker or a Kafka cluster — same request, same approval, same lifecycle.
- NGINX
- Kong
- RabbitMQ
- Apache Kafka
Live now
IntegrationHub
Who said enterprise integration has to be expensive and complex? IntegrationHub is your end-to-end, AI-powered enterprise integration platform: API gateways (NGINX, Kong), message brokers (RabbitMQ, with AMQP and MQTT), and event streaming (Apache Kafka) — governed and self-service on Kubernetes, ready for your AI agents from day one. Provision a tenant without filing a ticket, then run it: scale, restart, inspect logs and events, peek and publish messages, federate brokers by selection, and decommission cleanly. And B2B is another plane on the same platform: model a partner integration — X12 and EDIFACT document types, source-to-target maps, reusable rules, flows and transport profiles — then run it, with documents arriving over SFTP, validated, split or aggregated, transformed and routed, and 997 or CONTRL acknowledgements returned over the transport you configure. Every destructive action previews what it will destroy before you confirm it, subscriptions carry their own expiry and authorization, and a metric we have never measured is reported as exactly that — never as zero.
Many planes, one control surface
Gateways, brokers and streaming are usually three separate tools and three separate teams. Here they are provisioned, governed and operated the same way.
Self-service, without the ticket queue
Teams provision what they need directly. Subscriptions carry their own expiry and per-subscription authorization, so access lapses on its own rather than lingering.
Partner integration, modelled and run the same way
B2B and EDI usually mean a separate integration suite. Here it is another plane on the same platform — designed, versioned, governed and run like the rest.
Model B2B and EDI integrations — then run them
Design the whole partner integration in one console — X12 and EDIFACT document types, source-to-target data maps, reusable rules, the flows that connect them, and the trading partners and transport endpoints behind them — then run it: documents arrive over SFTP, are validated, split or aggregated, transformed and routed by rule, and 997 or CONTRL acknowledgements go back over the transport you configure. Proven on a live tenant, end to end.
- X12
- EDIFACT
- Open standards
Day-2 operations, not just Day-1 provisioning
Standing something up is the easy part. Running it is where platform teams actually spend their week.
Operate from the same console
Scale, restart, start and stop. Inspect logs, events and live status without reaching for kubectl.
Work with the messages themselves
Peek at a queue and publish a test message from the console when you are diagnosing a stuck consumer.
Federate brokers by selection
Pick a source and a target; the connection URIs are derived and the resulting link health is surfaced. No hand-built federation config.
Governance built into the destructive paths
See what a teardown destroys — before you confirm
Every delete names what blocks it and previews exactly what will be removed. Decommissioning carries a cool-off rather than taking effect instantly.
Unmeasured is not zero
A metric we have never measured is reported as never measured — not as zero traffic. A dashboard that quietly reads nothing as "fine" is worse than no dashboard.
Open source underneath, Kubernetes native
The platforms are the ones your team already knows, running on your cluster. No proprietary broker, no lock-in at the protocol layer.
The flagship
Self-service gateway provisioning
Governed provisioning on KubernetesRequest an API gateway, message queue, or event stream — it is reviewed, then provisioned to Kubernetes as a governed workflow.
IntegrationHub turns integration-infrastructure provisioning into a self-service, governed workflow. A team requests a managed gateway; the request is reviewed and approved, then provisioned to Kubernetes automatically — with automated Day-2 operations (scale, reconfigure, decommission) once it is live. One control plane spans API gateways, message queues and event streaming.
- Self-service — request a gateway, no manual infra tickets
- Multi-protocol — API gateways, message queues, event streaming
- Reviewed before provisioning — governed, not ad-hoc
- Automated Day-2 operations on Kubernetes
Hover any step for details. Each step runs deterministically or as an AI agent.
How it works
From a request to a managed gateway on Kubernetes
- 1
Request
Ask for a managed gateway — an API gateway, message queue, or event stream — as a self-service request.
- 2
Review & provision
The request is reviewed and approved, then provisioned to Kubernetes automatically.
- 3
Operate
Automated Day-2 operations keep it scaled, reconfigured, and healthy — no manual infra tickets.
One plane, many protocols
Gateways you can provision
The same governed provisioning workflow spans every protocol — request, review, provision to Kubernetes, then operate. Each gateway type is provisioned and managed the same way.
API gateway (Kong)
Provision a managed API gateway tenant on Kubernetes, ready to publish and secure APIs.
- API gateway
- Kong
- Kubernetes
A person approves the request; the gateway is then provisioned automatically.
Message queue (RabbitMQ)
Provision a managed RabbitMQ cluster for reliable messaging between services.
- Message queue
- RabbitMQ
- Kubernetes
Event streaming (Kafka)
Provision a managed Kafka cluster for high-throughput event streaming.
- Event streaming
- Kafka
- Kubernetes
Day-2 operations
Scale or reconfigure a running tenant — reviewed, then applied to Kubernetes with no downtime tickets.
- Scale
- Reconfigure
- Day-2
Operational changes are reviewed, then applied to Kubernetes automatically.
Answers, not a brochure
Questions people ask about IntegrationHub
How gateways, brokers and streaming get provisioned and operated: requesting a tenant, running it day to day, publishing APIs and topics, and decommissioning cleanly.
IntegrationHub provisions and operates integration infrastructure on Kubernetes as a self-service product: API gateways, message brokers, event streaming and B2B/EDI gateways, from one control surface.
These are normally three separate tools owned by three separate teams. Here they share one provisioning path, one operations model and one audit trail — which is the point, because the cost of integration is rarely the software. It is the three teams, and the handoffs between them.
Each tenant is isolated and named deterministically, with its own allocated port.
- API gateways
- NGINX and Kong — for publishing and protecting APIs.
- Message brokers
- RabbitMQ, reachable over AMQP and MQTT, with virtual-host isolation per tenant.
- Event streaming
- Apache Kafka — topics, partitions and consumer offsets.
- B2B / EDI gateway
- A per-tenant runtime that receives partner documents over SFTP, transforms and routes them, and returns 997/CONTRL acknowledgements — X12 and EDIFACT.
No — you request one, and the request runs as a governed workflow rather than a script someone runs on your behalf.
Namespaces are generated into a form Kubernetes will accept, every time, without a human sanitising the customer name by hand. Ports are allocated inside a transaction, so two tenants requested in the same second cannot be handed the same port. Concurrent provisions are bounded, and a request that cannot get a slot in the give-up window fails fast with a clear message rather than queueing invisibly.
The tenant lands in a failed state with the reason attached. It does not report success and leave you to discover otherwise.
This is the behaviour we would defend hardest, because the alternative is so common. A pipeline that dispatches a job and reports "submitted" as "done" is right most of the time and catastrophic the rest. Provisioning polls the real job to a terminal state and reports what actually happened — including matching the specific run it dispatched, so it cannot report on somebody else's job that happened to be in flight.
Standing something up is the easy part; running it is where the week goes. Day-2 operations are first-class here, not bolted on later.
- Lifecycle
- Start, stop, restart, scale, and put a tenant into maintenance.
- Observability
- Live status, logs, Kubernetes events, and a history of every operation performed.
- Message operations
- Peek, publish, purge, move to a dead-letter queue and reset consumer offsets — on the same surface, with the same audit trail.
- Federation
- Connect brokers by selecting a source and a target, rather than hand-writing federation config and hoping the two ends agree.
It does B2B and EDI as another plane on the same platform. You model the whole partner integration in the console — X12 and EDIFACT document types, source-to-target data maps, reusable routing rules, the flows that connect them, and the trading partners and transport endpoints behind them — then a per-tenant gateway runs it.
At runtime a document arrives over SFTP, is validated, split or aggregated, transformed and routed by rule, and a 997 (X12) or CONTRL (EDIFACT) acknowledgement goes back over the transport you configure. This has been proven end to end on a live tenant, and our AS2 sending has been checked against an independent AS2 implementation, both trust directions.
Two things we say plainly: today a partner delivers to us over SFTP — inbound AS2 termination is not built yet — and the AS2 interop is proven against an independent implementation, not yet against a specific named partner. And it is built on open standards without a commercial licence: EDIFACT from the free UNECE directories, a scoped X12 subset from public structure.
It is applied live to the running gateway or broker — not written to a file someone has to deploy later. No pod restart, no pipeline run.
Brokers are reconciled against the full intended definition rather than patched, which has a consequence worth naming: deleting something in the control plane actually removes it from the broker. Patch-only integrations tend to create things reliably and delete them never, and the orphans accumulate until someone audits by hand.
A subscription carries its own authorization and its own expiry, so access that should end does end, without a person remembering to revoke it.
The paths that can lose data carry the most guarding.
- Preview before destroy
- Every destructive action shows exactly what it will destroy before you confirm. Deleting a tenant tells you what goes with it.
- Honest metrics
- A metric that has never been measured is reported as exactly that — never as zero. A zero and an absence mean very different things to whoever is on call.
- Clean decommission
- Decommissioning removes the tenant and its objects rather than orphaning them.