OCNORA
Enterprise

One control plane. Every tenant governed.

OCNORA was built multi-tenant from the first commit: one deployment serves many tenants, each with its own budgets, secrets, plugins and audit log. Run it on your cloud, in an air-gapped network, on ours, or inside the product you sell.

Deploy anywhere

Same image, five ways to run it.

Every option runs the same container image and the same six process roles. The difference is who operates it and where the data lives.

OptionHow it worksGood for
Docker ComposeOne compose file brings up the API, router, scheduler, worker pools, Redis and MongoDB from a single image.Pilots, single-team installs, developer laptops.
Kubernetes via HelmOne chart with values files for AWS, Azure and GCP. Each process role is its own deployment so worker pools scale independently.Production on your cloud account.
Air-gappedThe same image, activated with an offline Ed25519-signed licence file. No phone-home, no outbound calls the workflows did not ask for.Regulated networks, sovereign hosting.
OCNORA cloudWe run the control plane; you get a tenant with its own budgets, secrets and audit log.Teams that want to start today.
Embedded in your productThe builder and run views mount inside your application via an iframe with JIT SSO. Your customers become tenants on your control plane.SaaS platforms adding automation.
Architecture

Six process roles from one image.

The API never executes a workflow, and workers never talk to the database directly. Steps travel through Redis queues; MongoDB is the system of record; every role reports metrics, structured logs and traces.

RoleResponsibility
api151 REST routes, WebSocket run events, the MCP endpoint
routerAdvances each run step by step, enforces budgets, permissions and HITL
schedulerCron triggers, retry timers, HITL timeout sweeps
worker-genericApp, HTTP, data and code nodes
worker-ai-vendorCalls to hosted model vendors
worker-ai-localvLLM and Ollama inference on your hardware
autofixRepairs one broken node at a time, re-runs pre-flight
healthValidation, pre-flight and dry run on every save and publish

Scale any role on its own: add AI-vendor workers when agent traffic grows, add local workers when you buy GPUs, keep the API small. Per-run locks stop two workers from advancing the same run; the dead-letter queue keeps a step that failed every retry so nothing is lost.

Multi-tenancy

One control plane, N tenants, no shared state between them.

Every query carries the tenant, every secret is scoped to it, and every budget is enforced against it. That is the difference between multi-tenant and multi-instance.

Per-tenant plugins and images

A tenant can carry its own node plugins and its own brand icons. Two tenants on the same control plane can see different catalogs.

Per-tenant budgets

Token and USD budgets per tenant and per provider, with circuit breakers. A noisy tenant cannot spend another tenant’s money.

Tenant-scoped secrets

Connections are encrypted with a per-secret key and can only be read by steps running for the tenant that owns them.

Tenant isolation on every query

Isolation is applied in the data layer, not per route, so a new endpoint cannot forget it.

Access and identity

Who can see and change what.

28-permission RBAC

Owner, admin, editor and viewer roles composed from 28 permissions, enforced on every API route and reflected in the dashboard navigation.

Scoped API keys

Keys carry a permission scope and an expiry, can be revoked at any time, and are attributed in the audit log.

JIT SSO for embedded hosts

When the builder is embedded in your product, your application mints a short-lived tenant-key token and the user is provisioned just in time. No second login.

SAML and OIDC for the dashboard are on the roadmap — ask us about timing. Today, dashboard users sign in with email and password, and embedded users arrive through JIT SSO.
Governance

Prove who did what, and what a run touched.

Audit log

Every mutation and every run step, with actor, tenant, workflow, node and connection. Exportable for the auditor.

Run lineage

A run records its workflow version, the sub-workflows it called, the connections each step used and the human decisions it waited on.

Versions with restore and diff

Every publish is a version. Compare two on the canvas and restore the one that worked.

Sharing with credential stripping

Share a workflow with another workspace and its connections are removed on the way out; the recipient gets a connection request instead of your secret.

Connection and app requests

Editors ask for a connection or a missing app from inside the builder; admins approve with the audit trail attached.

Business reports

Hours saved, money saved, automation share and reliability per workflow — the report a sponsor can forward.

Reliability

What happens when a workflow breaks at 3am.

Most of the time it does not get that far: Workflow Health checks every workflow on save and publish. When something does fail, the engine already knows what to do.

Workflow Health

Static validation, pre-flight against live connections and a dry run on every save and publish. The 0th run.

Auto Fix

A worker repairs one broken node at a time, re-runs pre-flight, and records each repair as a version you can inspect.

Retries and timeouts

Per-node retries with backoff and per-run timeouts, enforced by the router rather than left to each integration.

Error workflows and alerts

A failing run hands its context to an error workflow; alerts go to the channel your on-call already watches.

Ops center

Status and health side by side, an attention tab for workflows that need a person, and a failure drawer with the failing step’s input, output and error.

Insights

KPIs and sparklines per workflow so a slow regression is visible before it is an incident.

Support and commercial

Licensed per deployment, built with design partners.

Licence per deployment

Self-hosted and air-gapped installs are activated with a signed licence file per deployment. Pricing follows executions and AI spend; see pricing.

Design-partner programme

A small number of enterprise teams work directly with the engineers who build OCNORA, shape the roadmap (SAML, secret stores, compliance) and get early access in return.

Direct line to the team

Enterprise customers get a named contact, a shared channel and response commitments in the agreement, not a ticket queue.

Talk to sales

Tell us where you need to run it and how many tenants you expect. We reply within one business day with a deployment recommendation and a quote.

Or write to sales@ocnora.com.

Try it on your own cloud with 1,000+ providers ready to connect.

Start with Docker Compose in an afternoon, move to Helm when the pilot is done. The workflows and audit log come with you.