Reactive at the core.
Runtime is being developed as a Java reactive integration engine. The aim: make asynchronous work and the boundaries between systems explicit.
INDEPENDENTLY BUILT. INTENTIONALLY CONNECTED.THE INTEGRATION FOUNDATION / 001
Connect everything.Build intelligently.
Great integrations start with a clear foundation. We're building a reactive engine for connected systems—and the tools to help you understand them.
Runtime in development · Wider product family planned
{ }Business APIsREQUEST / EVENT
≋Data sourcesREAD / TRANSFORM
ZERNOVARuntime IN DEVELOPMENT
⌘ApplicationsBUSINESS LOGIC
↗ServicesDELIVER / RESPOND
ONE CONNECTED FOUNDATION
DESIGN → EXECUTE → UNDERSTAND
BUILT AROUND THE INTEGRATIONLess guesswork.
Less guesswork.
More understanding.
Connecting an API is only the beginning. Our direction is a coherent foundation for how data moves, how flows behave, and how teams build with confidence.
Your architecture, your choice.
Cloud-neutrality is a design goal. Keep integration logic separate from the infrastructure that hosts it, with provider-specific concerns at the edge.
Designed to be understood.
Testing and observability are part of the product vision. Flows should be understandable before deployment and explainable when something goes wrong.
ONE FOUNDATION. A BROADER VISION.
View the roadmap Meet the product family.
01THE EXECUTION FOUNDATIONRuntime
An independently owned Java reactive integration engine, with early milestones under active development.
In development02StudioA future low-code visual environment for designing, understanding, and testing integration flows.
Planned03PlatformA future management and control plane for integration environments and their lifecycle.
Planned04AIPlanned MCP interfaces and Developer Skills to help AI tools work with integration context.
Planned05CloudA planned cloud-neutral hosted iPaaS, with Ethio telecom TeleCloud as the first intended hosting environment.
PlannedFOR THE PEOPLE WHO BUILDStart with the concepts.
Start with the concepts.
Follow the foundation.
Explore flow boundaries, connector design, and the questions behind a reliable integration. Our docs make the difference between current work and future intent clear.
Developer resourcesANATOMY OF AN INTEGRATIONCONCEPTUAL
01Receive a request or event
02Validate and transform the data
03Connect, respond, and observe
A design model, not an executable flow definition.
THE NEXT CHAPTER IS BEING BUILT
See the product direction