Documentation / Trust & Maturity

References & Evaluation

How a serious buyer evaluates Nexus — what evidence is available, the deployment footprint you take on, how to run a proof-of-concept in your own Azure tenant, and the support and access model.

This page is for the evaluator who is past "what does it do" and into "how do I convince my own security and platform teams to say yes." It lays out how to actually evaluate Nexus: what evidence you can get, what footprint you take on when you deploy, how to run a real proof-of-concept in your own tenant, and how support and access work. It intentionally contains no uptime, latency, or SLA numbers — those are not substantiated, and an honest evaluation should not rest on numbers a vendor cannot back. It rests instead on evidence you can inspect and a deployment you can run yourself.

The evidence available to you

An evaluation is only as good as the evidence behind it. Here is what you can actually get, ordered from most-open to under-NDA:

This documentation, in full. It is written to be acted on by a skeptical senior engineer, and it is candid about what is shipped versus roadmap (see Shipped vs. Roadmap). Every reliability and security page states its limits, not just its features.
The security architecture whitepaper set. The Security & Compliance section documents tenant isolation and data custody, the identity and access model, supply-chain integrity for signed bundles, the secure-development and vulnerability-management process, incident response, and a compliance / shared-responsibility narrative.
The evaluator evidence package. A structured set of evidence assembled for buyers — including the material that is not appropriate to publish openly (details from the internal security-findings register and red-team exercises) — is available to evaluators under NDA. See Evaluator Evidence for what it contains and how to request it.
Your own proof-of-concept. The strongest evidence is the product running against your data in your tenant — covered below.

What the evidence does not include

Being explicit, so you can plan your review: we do not provide a third-party penetration-test report or an industry certification we do not hold, and we do not publish uptime/latency/SLA figures. We describe the security program and architecture, and we point out that the underlying Azure services carry their own certifications and posture, which Nexus inherits. If your process requires an independent audit artifact, raise it early — do not assume one exists.

The deployment footprint you take on

Because Nexus is an Azure Marketplace managed application that deploys into your own subscription, evaluating it means understanding the footprint it creates. There is no Stingray-hosted data plane; everything below runs in your tenant, under your governance:

A per-tenant Container App running the Nexus server (the versioned image).
A per-tenant PostgreSQL Flexible Server — managed-identity auth, DB passwords disabled — holding operational state, run history, audit, and the internal workspace (a separate database with its own managed identity).
A per-tenant Key Vault for secrets and signing keys.
A per-tenant VNet with an NSG egress allowlist and a private endpoint to the database.
Azure Files for pipeline state and the per-tenant git version-history repository.

The practical implication for your review: the availability, backup, and data-residency posture of Nexus is largely the posture of the Azure services above, which your team already knows how to govern. Your DR story for Nexus is an extension of your Azure DR story — see Backup & Disaster Recovery — and your data never leaves your subscription's control. The deployment mechanics are in Deployment and Tenant Isolation & Data Custody.

Running a proof-of-concept in your own tenant

The best way to evaluate a platform that runs in your subscription is to run it in your subscription. A representative proof-of-concept looks like this:

Deploy the managed application into a non-production subscription from the Marketplace. You get the full per-tenant footprint above, isolated from your production estate. See Deployment and Initial Configuration.
Wire up identity. Connect Microsoft Entra ID, register the users who will evaluate, and assign roles. Exercise the RBAC model directly — including per-resource grants and execution roles — against your own directory. See Identity and Roles & RBAC.
Connect a real source. Use a native connector if one fits, or the generic HTTP/REST or JDBC substrate for anything not natively covered. Confirm discover_schema and a real query against your data. See the Connector Capability Matrix.
Build one real pipeline and schedule it. Author a sandboxed Python pipeline that does something you actually need, put it on the cron scheduler, and watch a real run: timeouts, run history, the full traceback path on an induced failure, and the audit snapshots. This exercises the runtime the way the production NetSuite workload does.
Point your own security tooling at it. Because it is in your tenant, your scanners, your network monitoring, and your identity governance all apply. Inspect the egress allowlist, the private endpoint, the Key Vault access, and the signed-bundle verification. Request the Evaluator Evidence package to cross-check against the architecture.
Connect an AI agent, if that is in scope. Pair an MCP client and confirm that an agent acts strictly within the connecting identity's permissions — the same RBAC you configured in step 2. See Connecting AI Agents.

At the end of a POC like this you will have evaluated the real artifact — not a hosted demo — against your data, your directory, and your security controls. That is a stronger basis for a decision than any reference number.

Support & access model

You own the deployment. Because Nexus runs in your subscription, you retain operational control: you decide when to apply an update (see Updates), and your data plane is never in Stingray's hands.
Government cloud is a proven path, not a promise. Nexus runs today on an Azure Government (GCC-High) tenant, including a proven cross-cloud image pull. If you are a government or regulated buyer, that path exists in production — see Platform Maturity.
Custom connector work. If you need a source the catalog does not natively cover and the generic substrates are not the right fit, Stingray can build a native adapter on the same signed adapter contract, and customers with their own developers can build connectors against that contract.
Evaluation engagement. For the evidence package, a scoped POC, or connector questions, engage through the channel described on the Evaluator Evidence page.

The honest bottom line

Nexus asks to run inside your own Azure tenant, governed by your own identity and network controls, with signed and attested artifacts and a candidly-documented set of shipped-versus-roadmap capabilities. The right way to evaluate that is not to trust a number on a slide — it is to deploy it where you can inspect it and run your real workload through it. This documentation, the security whitepaper set, the under-NDA evidence package, and a proof-of-concept in your own subscription are, together, everything you need to make that call.