Run it where you need it. Evaluate it the way you buy.
OCNORA runs on our cloud, on yours with Docker Compose or Helm, or inside the product you sell. This page covers where it runs, how people sign in, how secrets are encrypted, who can act, the support you get, and the steps from first call to quote.
Our cloud, your cloud, or inside your product.
Every option runs the same container image and the same process roles. The difference is who operates it and where the data lives.
| Option | How it works | Good for |
|---|---|---|
| OCNORA Cloud | We run the control plane; your workspace gets its own budgets, secrets and audit log. | Teams that want to start without running infrastructure. |
| Your cloud: Docker Compose | The Docker Compose file brings up the API, router, scheduler, worker pools, Redis and MongoDB on one host. | Pilots and single-team installs. |
| Your cloud: Helm | The Helm chart runs each process role as its own deployment, including Workflow Health, Auto Fix and the task orchestrator, so each can scale on its own. | Production on your own Kubernetes cluster. |
| Embedded in your product | The builder and run views mount inside your application by iframe with JIT SSO. Your customers become tenants on your control plane. | SaaS platforms adding automation for their customers. |
Docker Compose and Helm are the two manifests we ship. On your cloud, the cluster, Redis, MongoDB and their backups are yours to run. Self-hosted and embedded installs are activated with a signed licence file verified locally, with no phone-home.
Claim deploymentOptions · unverified · checked 2026-09-28; Claim hostedCloud · unverified · checked 2026-09-27; Claim composeAndHelm · unverified · checked 2026-09-27; Claim embedJitSso · unverified · checked 2026-09-27; Claim offlineLicence · unverified · checked 2026-09-27.
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.
- Dashboard (21 locales)
- REST API + API keys
- Embedded builder (JIT SSO)
- MCP clients
- api
- router
- scheduler
- task orchestrator
- step queues per worker pool
- worker registry + heartbeats
- per-run locks
- retry queue
- approval timeout queue
- dead-letter
- worker-generic
- worker-ai-vendor
- worker-ai-local
- autofix
- health
- tenants, users, roles
- workflows + versions
- runs, steps, traces
- connections (encrypted)
- audit log
- AI ledger + budgets
- Prometheus metrics
- structured logs
- tracing
| Role | Responsibility |
|---|---|
| api | The REST API, WebSocket run events, the MCP endpoint |
| router | Advances each run step by step, enforces budgets, permissions and human approvals |
| scheduler | Cron triggers, retry timers, approval timeout sweeps |
| worker-generic | App, HTTP, data and code nodes |
| worker-ai-vendor | Calls to hosted model vendors |
| worker-ai-local | Calls to any OpenAI-compatible inference server you host (vLLM, Ollama, LM Studio, llama.cpp) |
| autofix | Repairs one broken node at a time, re-runs pre-flight |
| health | Validation and pre-flight on every save and publish |
| task orchestrator | Hands Task Runs to your development runner and tracks what comes back |
With Helm, 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. The task orchestrator only matters if you use Task Runs.
Claim deploymentOptions · unverified · checked 2026-09-28; Claim localModels · implemented · checked 2026-10-20; Claim taskRuns · unverified · checked 2026-09-28.
Email and password, MFA, or single sign-on over OIDC or SAML 2.0.
Both single sign-on protocols depend on an identity provider configured for the installation, and SCIM 2.0 keeps the user list in step with it. We confirm the protocol and the provisioning flow against your provider in the architecture review, before you plan a pilot around them.
Email and password
Dashboard users sign in with an email address and a password.
Multi-factor authentication
A second factor on top of the password for dashboard sign-in.
OIDC single sign-on
Users authenticate through your identity provider where the installation has OIDC configured. We confirm it against yours during the architecture review.
SAML 2.0 single sign-on
SP-initiated SAML 2.0 against your identity provider, with the service-provider metadata served per tenant. Sign-in starts from OCNORA: an IdP-initiated response is refused by design.
SCIM 2.0 provisioning
Your identity provider creates, updates, suspends and removes users and groups through the SCIM 2.0 endpoints. A suspended or removed user loses their sessions and API keys at once. New users arrive as viewers; roles are assigned in the app.
JIT SSO for embedded hosts
When the builder is embedded in your product, your application hands the user over and they are provisioned just in time. No second login.
Claim dashboardSso · implemented · checked 2026-10-20; Claim scimProvisioning · implemented · checked 2026-10-20; Claim embedJitSso · unverified · checked 2026-09-27.
Connection secrets, envelope-encrypted under a key you choose.
Each connection secret is encrypted with its own data key, and that data key is wrapped by one of three backends. Azure Key Vault and HashiCorp Vault are not offered.
Local master key
The data keys are wrapped by a master key held by the installation. The simplest option for a pilot.
Google Cloud KMS
The data keys are wrapped by a key held in Google Cloud KMS.
AWS KMS
The data keys are wrapped by a key held in AWS KMS.
Claim encryptionBackends · unverified · checked 2026-09-27.
Owner, admin, editor and viewer.
Each role is composed from individual permissions, and every API route checks the one it needs, so the dashboard, the API and MCP clients follow the same rules. Custom roles are not claimed.
Claim rbacPermissions · unverified · checked 2026-09-27.
Approvals, checks, a record of every run, and budgets on AI.
The same controls run on every option above. Each is covered with its limits on the controls page.
Human approvals
A human.prompt step holds a run until a person answers or its timeout lapses, and the decision stays with the run.
Claim humanApprovals · unverified · checked 2026-09-28.
Workflow Health and Auto Fix
Each workflow is validated and its connections pre-flighted on save and publish; Auto Fix repairs one broken node at a time, and the rest goes to a person.
Claim workflowHealth · unverified · checked 2026-09-28.
Run record and audit log
Every run keeps its steps with input, output and the connection used; the audit log records who changed what, and exports.
Claim runAudit · unverified · checked 2026-09-28.
AI budgets
Every model call on a ledger in tokens and USD, against monthly budgets per workspace and provider, and per tenant on Embedded.
Claim aiBudgetUsage · unverified · checked 2026-09-28.
A direct line to the people who build it.
Email support
On every deployment option.
Claim emailSupport · unverified · checked 2026-09-27.
Partner support channel
For teams embedding OCNORA in their own product.
Claim partnerSupport · unverified · checked 2026-09-27.
Named contact and the engineers
Enterprise customers work with a named contact and the people who build OCNORA over a shared channel. Support terms are written into your agreement, not published here.
Claim supportEngagement · unverified · checked 2026-09-28.
Design-partner access
A small number of enterprise teams work directly with the engineering team on what comes next, by agreement.
Claim designPartner · unverified · checked 2026-09-27.
From first call to quote.
OCNORA does not hold a third-party security attestation and this page does not claim one. What an evaluator gets instead is below; the evaluation guide turns it into a pilot scope, success criteria and a timeline you can print.
Security questionnaire
Send us your questionnaire. We answer it from the documented controls on the security page, and share the design notes behind them under NDA.
Claim securityReview · unverified · checked 2026-09-27.
Architecture review
A session with the engineers on your deployment option, network, identity provider, key backend and the process roles you will run.
Claim procurementPath · unverified · checked 2026-09-28.
Pilot plan
A written plan: which workflows, which deployment, the success criteria you set and who signs off. Docker Compose is usually enough for a pilot.
Claim procurementPath · unverified · checked 2026-09-28.
Quote
Licensed per deployment; self-hosted and embedded installs are activated with a signed licence file. Pricing follows executions and AI spend; see pricing.
Claim offlineLicence · unverified · checked 2026-09-27.
Talk to sales
Tell us where you need to run it, how your people sign in and which key backend you use. We come back with a deployment recommendation, the next evaluation step and a quote.
Or write to sales@kxntech.com.
Try it on your own cloud with 1,000+ cataloged providers ready to connect.
Start a pilot with Docker Compose and move to Helm for production. The workflows and audit log come with you.