What Is Nexus

Nexus by Stingray is an Azure-native, tenant-owned data-access and automation layer — a governed way to query, sync, and act across your ERPs, databases, and SaaS systems, with a built-in MCP surface for AI agents, running entirely inside your own Azure subscription.

Nexus by Stingray is an Azure-native data-access and automation layer that deploys as a Marketplace managed application into your own Microsoft Azure subscription. It connects to your ERPs, databases, and SaaS systems and gives your people, your applications, and your AI agents one governed way to query, move, and act on that data — without your records, your credentials, or your query results ever leaving your tenant.

This page is for technical evaluators, data and platform engineers, security reviewers, and IT leaders deciding how to give teams (and increasingly, AI agents) safe access to systems that today sit behind a patchwork of exports, service accounts, and one-off integrations. It explains what Nexus is, who it's for, the trust model that makes it different, and — just as importantly — what Nexus is not.

The problem Nexus solves

Most organizations run business-critical data across many disconnected systems: an ERP like NetSuite, one or more SQL databases, work-tracking tools like Monday, and a long tail of SaaS APIs. Answering a question across those systems usually means manual exports, brittle scripts, or copying everything into a warehouse you then have to secure all over again.

Two failure modes follow from that:

• Silos. There is no single, consistent way to read across systems, so every integration is bespoke, undocumented, and fragile.
• Ungoverned access. Credentials get shared into scripts and spreadsheets, copies of sensitive data sprawl across laptops and BI tools, and no one can answer "who read what, when, and under whose authority."

Both problems are getting sharper as teams point AI assistants at internal data. An agent that can "just query the ERP" is only safe if that access is identity-bound, permission-checked, and audited the same way a human's would be.

Nexus addresses this by inserting one governed access layer between callers and sources. It gives you consistent querying, real role-based access control, per-run audit, and secrets custody — while leaving each source system as the system of record. Nothing is copied into a Stingray-operated store, because there isn't one.

What Nexus is

Nexus is a per-tenant server you deploy from the Azure Marketplace as a managed application. Everything that touches your data runs inside your subscription: the application container, a dedicated PostgreSQL database for its own state, a Key Vault for secrets, a virtual network with egress controls, and file storage for pipeline state and version history. Stingray publishes and updates the software through the managed-application contract and operates a small shared control plane for updates, the connector catalog, and licensing — but Stingray never holds your data plane. See Architecture for the full component and data-flow picture.

Functionally, Nexus is three layers that share one governance model:

1. A data-access layer. Signed connectors (adapters) read and write to your sources through a uniform contract, and UQL — a unified query model — lets you read across them with consistent semantics, schema discovery, and predictable pushdown behavior. See UQL Introduction.
2. An automation runtime. Pipelines are real Python modules (async def run(ctx)) that run under a sandbox, on a durable queue, with cron scheduling, timeouts, per-run limits, and full run history. See Pipelines Overview.
3. An agent surface. A built-in Model Context Protocol (MCP) server exposes the same capabilities to AI assistants, bound to the connecting identity and checked by the same RBAC and audit. See MCP Server.

On top of these you author reports (saved, parameterized queries), Sites (internal pages backed by live Nexus data), and skills (playbooks agents can pull). Every authored artifact is version-controlled in a per-tenant git repository. The vocabulary is defined precisely in Core Concepts.

The trust model: your data stays in your tenant

The headline differentiator is not a feature — it's where Nexus runs and who holds the keys.

Nexus is single-tenant and tenant-owned. Every component that reads your data, holds your secrets, or executes your automation lives inside your Azure subscription, under your identity, your network policy, and your logs:

• Per-tenant PostgreSQL Flexible Server, reached with managed-identity tokens — database password authentication is disabled.
• Per-tenant Key Vault holds every source credential. Stingray has no path to it.
• Per-tenant Container App runs the server under a managed identity with no standing passwords.
• Per-tenant VNet with an NSG egress allowlist and a private endpoint to the database, so Nexus can only reach what you permit.

Stingray's shared control plane receives operational metadata only — an update check, a license lease, a connector-catalog lookup. It never sees your business records, your query results, or your credentials. There is no Stingray-hosted data plane to breach, subpoena, or accidentally log. For security reviewers, this collapses a large class of third-party-processor risk: the vendor is not in your data path. The isolation model is detailed in Architecture and the security section.

This is also what makes Nexus a credible fit for regulated and government workloads: one of the two live tenants runs on Azure Government (GCC-High), deployed from the same managed-application contract, with a confirmed cross-cloud image pull.

Who Nexus is for

• Data and platform engineers who need one governed way to read and write across systems, instead of maintaining a drawer of service accounts and cron scripts.
• Security and compliance teams who need source credentials in a vault, access bound to identity, and a per-run audit trail — with the vendor kept out of the data path.
• Operations and finance teams who run recurring cross-system work (reconciliations, syncs, reporting) and want it scheduled, observable, and re-runnable rather than living in someone's notebook.
• Teams adopting AI who want assistants to query and act on internal data safely — within a real permission and audit boundary, not through a shared service account.

What Nexus is not

Being honest about scope is part of earning a platform team's trust:

• Nexus is not a hundreds-of-connectors iPaaS. It ships a focused set of production-grade, cryptographically signed connectors (SQL databases, NetSuite, QuickBooks Online, Monday), not a marketplace of thousands of shallow ones. The reach comes from generic escape hatches: a first-class generic HTTP/REST connector for any REST API (you author build_request/parse_response scripts with OAuth2/auth resolution and SSRF-checked egress) and a generic JDBC connector for any database with a JDBC driver. Where you need a deep native adapter, Stingray can build one, and teams with developers can build connectors on the same adapter contract. See the Connectors Overview and Capability Matrix.
• Nexus is not a data warehouse or lake. It does not copy your systems into a central analytical store. Sources stay the system of record; the built-in workspace is a per-tenant Postgres scratch DB for staging and joining intermediate results, not a warehouse.
• Nexus is not a low-code visual workflow tool. Automation is real Python you can read, diff, and debug — not boxes and arrows or an opaque expression engine.
• Nexus is not a SaaS that runs your data. You run the software; Stingray ships and licenses it. Updates apply when you choose to apply them.

Governance, in one place

Every read and write passes through Nexus, which enforces:

• Identity via Microsoft Entra ID — users sign in with OAuth2 + PKCE; automation uses scoped app tokens or API keys; the desktop client stores tokens in the OS keyring.
• RBAC — built-in tenant roles (Reader and Admin) plus custom roles and per-resource scoped grants over pipelines, reports, bridges, files, Sites, and tools, for both users and application principals. Execution roles let you pin a curated role to a pipeline or report without granting anyone standing elevation. See Roles & RBAC.
• Secrets custody — source credentials live in your Key Vault and are resolved server-side for the authenticated identity only. There is no request parameter by which a caller can borrow another identity's credentials.
• Audit — run history, structured logs, the complete failure traceback, and before/after snapshots are persisted per run. See Audit & Telemetry.

The same model governs the MCP surface, so an AI agent acts strictly within the connecting identity's permissions — never more.

Maturity you can check

Nexus is production software on a 2.1.x release line, not a prototype:

• Two live tenants — a commercial tenant and a Azure Government (GCC-High) tenant — running real production workloads, including a nightly NetSuite synchronization.
• ~1,300+ automated server tests across the platform.
• Versioned, image-based releases you pull on your own schedule.
• Eight signed connector bundles, each dual-signed (ES256) by two separate Key Vaults and verified fail-closed before load.

We do not publish uptime, latency, or throughput figures we cannot substantiate. What we do publish is the architecture and the process behind it — see Trust & Maturity and Security & Compliance.

Where to go next

• Architecture — where every component runs and how data flows.
• Core Concepts — precise definitions of bridge, adapter, UQL, report, pipeline, workspace, Site, skill, RBAC, and MCP.
• Connectors Overview — the shipped connectors and the generic HTTP/JDBC paths.
• Deploy from the Marketplace — stand up your own tenant.
• Connecting AI Agents — point an assistant at your data, governed.

Nexus gives you the reach of a central data platform with the control of software you own and operate yourself.