Documentation / Deployment

Deploy from the Azure Marketplace

Install Nexus as an Azure Managed Application from the Marketplace straight into your own subscription, with Stingray operating the software while your data, secrets, network, and infrastructure stay entirely under your governance.

Nexus by Stingray installs from the Azure Marketplace as an Azure Managed Application. The deployment lands entirely inside your own Azure subscription and Microsoft Entra tenant: the application server, its state database, your secrets, and your network egress controls all run in resources you own and pay for. Stingray publishes and operates the software through Microsoft's managed-application channel, but never holds standing credentials in your tenant and is never in your data path. This page is for the Azure administrator or platform team who will install Nexus, and for the security or procurement reviewer who needs to understand exactly what lands in the subscription and who can reach it.

The managed-application model

An Azure Managed Application deploys resources into your subscription, but places them in a managed resource group whose day-to-day control is delegated to the publisher (Stingray). You own the subscription and the resources; you pay for the underlying Azure infrastructure on your existing Enterprise Agreement or Microsoft Customer Agreement; and you retain full read visibility into everything deployed. The publisher gets a scoped, auditable ability to operate the software — nothing more.

Two properties of this model matter for a security review:

No Stingray-hosted data plane. There is no Stingray-operated multi-tenant service that your data flows through. Every component that reads, writes, caches, or stores your business data runs in your subscription. Stingray operates a small shared control plane (updates, the signed integration catalog, licensing, and optional aggregate telemetry) that never receives your business data, query results, or credentials.
No standing credentials in your tenant. The Marketplace itself brokers the deployment through Azure Resource Manager, so there is no cross-tenant secret exchange to stand up the tenant. The publisher's operational access is mediated by the managed-application resource and is visible to you.

The responsibility split is clean and auditable:

You (the customer)	Stingray (the publisher)
Own the subscription, the data, the secrets, and the infrastructure bill	Publish and operate the Nexus software: image updates, support, monitoring guidance
Control identity and access through your own Entra tenant	Never issued standing credentials to your tenant
Approve every version change before it applies	Publish new versions through the standard Marketplace upgrade flow
Retain full read access to every deployed resource	Hold no access to your Key Vault secrets or query results
Govern network egress via NSG + app-layer allowlist	Never sits in front of your instance as a gateway or proxy

What gets provisioned into your subscription

A single Marketplace install provisions one self-contained, single-tenant Nexus instance inside a managed resource group in your subscription. The core resources are:

Nexus server — Azure Container App. The application: REST API, UQL query engine, Python pipeline runtime, reports, RBAC, and the embedded MCP server. It runs the Nexus container image, pulled from Stingray's registry (see below) using a managed identity in your tenant.
Per-tenant state database — Azure Database for PostgreSQL Flexible Server. Stores reports, pipelines, sites, configuration, RBAC grants, run history, and audit records. Authentication is managed-identity only — password authentication is disabled — so there is no database password to store, rotate, or leak. The server reaches it over a private endpoint, not the public internet.
Per-tenant Key Vault. Holds every connection secret and credential (your bridges) plus the deployment's signing material. Access is scoped to the instance's managed identity; Stingray has none.
Per-tenant virtual network with NSG egress allowlist. The Container App runs VNet-integrated behind a network security group that restricts outbound traffic, and a private endpoint carries database traffic inside the VNet. This is the network-layer half of a defense-in-depth egress model; the application enforces an app-layer allowlist and SSRF checks on top of it.
Azure Files share. Durable state for pipeline execution and the per-tenant git repository that backs version history for pipelines, reports, sites, and skills.
User-assigned managed identity. The single identity the Container App uses to pull its image, read Key Vault, authenticate to Postgres, reach storage, and manage the in-product sign-in callback. There are no standing passwords anywhere in the deployment.
Microsoft Entra app registration. Created in your tenant for OAuth2 single sign-on (PKCE) from the desktop and Excel clients and for browser sign-in to hosted Sites.
Optional JDBC sidecar. Enables the generic JDBC connector for sources without a native adapter (Oracle, DB2, Snowflake, Redshift, and other JDBC-compatible systems), driver JAR supplied by you.

Nothing Stingray-side is provisioned into your subscription. The architecture overview walks through how these components fit together and where the trust boundaries sit.

How the image reaches your tenant — including Government cloud

Every customer — commercial and Azure Government / GCC-High — pulls the same signed Nexus container image from Stingray's single commercial Azure Container Registry into their own subscription at deploy and update time. Stingray does not stand up separate publisher infrastructure per cloud; there is one registry, one signed image line, and one signed adapter-bundle line. A GCC-High deployment flips only the client-side endpoints (for example login.microsoftonline.us for identity) — the image source is unchanged, and cross-cloud pull from the commercial registry into an Azure Government subscription is a proven, exercised path (the Delva tenant runs this way).

This is worth stating plainly for a supply-chain review: the artifact you run is centrally built and signed by the publisher, and the same artifact runs in every environment. Adapter bundles carry their own dual-signature verification chain, described in the connectors overview and the security material below.

What the publisher can and cannot reach — stated honestly

Because reviewers ask this directly, here is the candid answer:

Stingray cannot read your Key Vault secrets, your query results, or your business data. These never leave your subscription and Stingray holds no credentials to them.
Stingray does not sit in your request path. There is no shared gateway, proxy, or reverse proxy in front of your instance. Traffic goes browser/desktop → your Nexus server → your data sources.
Stingray operates the software through the managed-application resource — publishing versions you approve, and (with the opt-in) receiving operational telemetry that is aggregate and metadata-only, never your data.
Your instance makes outbound calls to the control plane for update checks, the signed catalog, and license leases. These carry operational metadata only. Licensing uses short-lived signed leases verified locally against a public key baked into your deployment, so enforcement does not depend on phoning home for every request.

If your security posture requires it, the NSG and app-layer egress allowlist are the levers that bound what your instance can reach outbound.

Before you install: authorize Nexus in your tenant

Nexus signs users in from your own Microsoft Entra tenant, so a Global Administrator grants a one-time admin consent before the first install. This is a short, browser-only step — no command line, no portal spelunking:

Open the admin-consent link from the Marketplace listing, substituting your own Entra tenant ID (find it under Microsoft Entra ID → Overview).
Sign in as a Global Administrator.
Review the requested permission — sign in and read the user's basic profile.
Click Accept.

That registers Nexus as an approved sign-in source for your directory. The full identity model — OAuth2 PKCE, app credentials, conditional access inheritance, and Government-cloud endpoints — is covered in Identity & Sign-In.

Installing

Find Nexus by Stingray Technology in the Azure Marketplace and choose Get It Now → Create.
In the deployment wizard, pick the Azure region, name your instance, and choose your tenant slug (a short, unique identifier — typically your company or team name; it also determines your custom-domain hostname later). One or more admin bootstrap object IDs seed the first administrators from your directory.
Review and start the deployment. Azure Resource Manager provisions the managed resource group; the provision typically completes in roughly ten minutes.
At first sign-in, the bootstrap administrator accepts the Terms of Service and Privacy Policy, then supplies credentials for the first system to connect (for example NetSuite or SQL Server). First-time setup — sign-in, one bridge, and a first query — typically takes about thirty minutes.

The full first-run checklist, including admin bootstrap, the tenant slug, connecting the first bridge, and health verification, is in Initial Configuration.

Updates and operations

Stingray publishes Nexus versions through the standard managed-application upgrade flow, and updates are opt-in: nothing changes in your environment until you act. Image-only changes can be pulled in place; changes that alter provisioning (new configuration, permissions, or networking) apply as a Marketplace managed-app Update that re-runs the deployment template. Your stateful resources — the Azure Files share, the Postgres database — are preserved across version changes because deployments are incremental. The full model, including how to check for and apply updates and how versioning works across the server, adapter bundles, and the offer, is in Updates & Versioning.

Cost

The Marketplace plan price covers Nexus licensing and Stingray's operation of the software. The underlying Azure infrastructure — Container App compute, PostgreSQL Flexible Server, Key Vault, storage, and networking — is billed separately to your subscription at standard Azure rates and appears on your existing Microsoft agreement, so there is no separate vendor invoice to process. A typical single-instance deployment runs on the order of USD 80–150 per month in Azure infrastructure, depending on region, compute sizing, and data volume. Because the underlying services are standard Azure resources, they carry Azure's own compliance posture and certifications; Nexus inherits the security posture of the services it runs on.