Documentation / Trust & Maturity

Platform Maturity & Release Cadence

An honest account of where Nexus is as a product — a versioned release line, a regular cadence, two live production tenants including Azure Government, and a real recurring production workload.

This page is for an evaluator who has read the capability documentation and now wants the honest answer to a different question: is this real, and how far along is it? We will not oversell. Nexus is not a decade-old iPaaS with thousands of logos, and this page will not pretend otherwise. It is an established, focused platform with a versioned release line, a working deployment in commercial and government Azure clouds, and a recurring production workload doing real work today. Below is the evidence for each of those claims, stated plainly.

The one-paragraph summary

Nexus ships on the 2.1.x server line, versioned and released on a regular cadence. It runs in production in two live tenants — a commercial Azure tenant and an Azure Government (GCC-High) tenant — and the government deployment proved out a cross-cloud image pull (a commercial-cloud registry serving a government-cloud tenant), which is the hard part of getting into GCC-High. One of those tenants carries a real recurring production workload: a nightly ERP (NetSuite) synchronization that runs unattended against live financial data. The server carries ~1,300+ automated tests across 128 test files that run on every release. That is the honest maturity picture: focused, versioned, in production, in two clouds, doing real work — not a demo.

A versioned, released product

Nexus is not a perpetually-unstable internal tool exposed to customers. It is a versioned product:

Semantic version line. The server is on the 2.1.x line. Versions are bare semver tags on the published container image; there is no ambiguity about what a tenant is running.
Version-pinned components. The desktop app, the baked web UI, and the image-baked system skills are each pinned to a specific version, so there is no skew between the server a tenant runs and the client surfaces it presents. Your /openapi.json always matches your running image.
Regular cadence. Patch releases roll on a steady cadence as fixes and features land; the release-notes page tracks the connector and platform changes per version. See Release Notes.
Reproducible, attested artifacts. Release images are built in CI (not on a developer's laptop), and adapter bundles ship signed and attested. Local builds of security-critical artifacts are refused by policy. The supply-chain story is detailed under Security & Compliance.

The practical consequence: when you deploy a specific version, you get a known, reproducible artifact, and you can tell exactly what is in it.

Two live production tenants

Maturity is easy to assert and hard to prove. The proof that matters most is that Nexus runs in production in more than one place, including the hardest place to run:

Commercial tenant (stingraytest). The reference commercial deployment. New platform capabilities and security fixes land here first and are exercised against the full connector and pipeline surface before they roll further.
Government tenant (Delva, Azure Government / GCC-High). A live deployment in the US government cloud. Getting into GCC-High is not a configuration flag — it requires the managed application to deploy into a government subscription and pull its container image across cloud boundaries from the publisher's commercial registry. Nexus proved that cross-cloud image pull in production. That is the concrete evidence behind the claim that a path to government-cloud deployment exists: it is not theoretical, it is running.

Both tenants deploy the same architecture — a per-tenant Container App, per-tenant PostgreSQL Flexible Server (managed-identity auth, DB passwords disabled), per-tenant Key Vault, per-tenant VNet with NSG egress control — inside the customer's own subscription. There is no shared Stingray data plane behind either one. See Architecture and Tenant Isolation & Data Custody.

Why the government deployment is the strongest signal

An evaluator should weight the GCC-High deployment heavily, because it is a forcing function for maturity. A government-cloud managed application has to satisfy a stricter identity model (a separate government Entra tenant, government login endpoints), stricter network posture, and the cross-cloud supply-chain path — all of which have to actually work before anything runs. A product that can stand up cleanly in Azure Government has necessarily done the unglamorous work of getting deployment, identity, secrets, and networking correct. Nexus has done that work in production.

A real production workload

Test suites prove code paths; a production workload proves the platform survives contact with reality. Nexus runs a nightly NetSuite synchronization in production: a scheduled pipeline reads from NetSuite on a two-tier pattern (a scheduled pipeline lands data into the internal workspace, and workspace-backed reports serve it), unattended, against live financial data, on the cron scheduler with exactly-once firing. This is not a canary that runs once — it is a recurring job that has to be correct every night, which means the scheduler, the run queue, the NetSuite adapter, the internal workspace, timeouts, and audit all have to hold up in the real world, not just in a test. The reliability primitives documented in Reliability & Operations are the ones this workload exercises.

How to read this honestly

We would rather you deploy with accurate expectations than be surprised, so here is the candid framing:

What Nexus is: a versioned, in-production platform, running in commercial and government Azure, with a real recurring workload and a substantial automated test suite. Focused and deep on the "govern your data and automation inside your own Azure tenant" problem.
What Nexus is not (yet): a mature iPaaS with hundreds of native connectors and a decade of operational history across thousands of customers. The connector catalog is deliberately curated (with generic HTTP/REST and JDBC substrates as the escape hatch for anything not natively covered), and some reliability primitives are honestly marked as roadmap rather than shipped.
Where the gaps are documented, not hidden: the Shipped vs. Roadmap page is a candid line-by-line table of what is GA, what is rolling out, and what is roadmap. Read it before drawing conclusions about any specific capability.

What we do not claim

In keeping with the rest of this documentation, this page publishes no uptime percentage, no latency or throughput number, and no SLA or RPO/RTO figure. Those numbers are not substantiated by a measurement program we would stand behind publicly, so we do not print them. What we do say is verifiable: the version line, the two tenants, the cross-cloud pull, the production workload, and the test count. Because Nexus runs on Azure services inside your own subscription, its availability posture is an extension of the Azure services you already operate and measure — you set and observe your own targets. See Backup & Disaster Recovery.