Documentation / Release Notes

Release Notes

A capabilities-by-area summary of what has shipped in Nexus — every connector, the pipeline runtime, RBAC, Sites, MCP, version control, workspace, and the deployment and update model — reconciled to ground truth.

Nexus is delivered as an Azure Marketplace managed application that runs inside your own Azure subscription. Each release ships as a new server image on the 2.1.x line, paired with an updated managed-app offer. This page is a capabilities-by-area summary of what has shipped, not a dated per-version changelog. It is the honest inventory of what the platform does today; for the forward-looking split between what is built and what is planned, see What's shipped vs. roadmap.

If a capability is not listed here, treat it as not shipped. Where a control is still rolling out across tenants rather than universally GA, we say so.

Data Connectors

Nexus ships 8 signed adapter bundles plus a baked-in internal workspace adapter and two generic substrates (HTTP/REST and JDBC) for sources without a native adapter. Every bundle carries a signed manifest, a SLSA-style attestation, and a transparency-log entry; each is dual-signed with ES256 by two separate Azure Key Vaults and verified fail-closed before load. An adapter that cannot be verified at startup is not loaded.

The pushdown column matters for buyers: it says whether filtering, ordering, grouping, and aggregation run inside the source or in the Nexus engine. When an adapter does not push an operation, Nexus evaluates it in-engine against fetched rows (a clean, correct fallback bounded by a row budget — never silently wrong). This is governed by the UQL capability model — see Pushdown & capability semantics.

Connector	Version	Read	Write	Pushdown (where / order / group / agg)
PostgreSQL	2.0.7	yes	insert / update / delete / merge	Full — where, order, group, distinct, having, join, select-expr, sum/count/avg/min/max
MySQL	2.0.5	yes	insert / update / delete / merge	Full (same SQL base)
Microsoft SQL Server	2.0.5	yes	insert / update / delete / merge	Full (T-SQL)
NetSuite (REST + SuiteAnalytics Connect)	2.0.8	yes	insert / update / delete / merge	Dual-surface — SuiteQL = full pushdown; REST record surface = none (engine filters)
QuickBooks Online	2.0.1	yes	insert / update / delete (no merge)	where + order only; aggregation runs in-engine
Monday.com	2.0.6	yes	insert / update / delete	where + order only; aggregation runs in-engine
Stripe (preview)	0.1.0	yes	insert / update / delete (per collection)	none — engine filters and orders in memory
JDBC (generic)	2.0.5	yes	SQL write	group, order, distinct, having, join, select-expr, aggregates
Internal Workspace	baked-in	yes	insert / update / delete / merge	Full — per-tenant Postgres, no stored credentials, isolated

Notes worth calling out:

NetSuite ships two surfaces. The REST record surface has no pushdown (Nexus fetches and filters in-engine); the SuiteQL surface and the SuiteAnalytics Connect JDBC path get full pushdown. Choose the surface per workload. See NetSuite (REST/SuiteQL) and NetSuite SuiteAnalytics Connect.
QuickBooks Online and Monday.com push filters and ordering to the source but evaluate grouping and aggregation in the Nexus engine. Monday.com's GraphQL dialect adds $not_contains/$not_empty and does not support $in/$expr.
Stripe is a preview (pre-1.0) connector. It reads and writes per-collection but declares no pushdown, so the engine filters and orders results in memory. Treat it as preview until it reaches 1.0.
JDBC (generic) connects any JDBC-compatible source with a configurable driver and URL and a JAR you upload — the answer to "we have a SQL database you don't list natively."

The generic answer to "any REST or SQL API"

Two first-class substrates mean you are not blocked waiting for a native adapter:

Generic HTTP/REST connector — a real connector substrate, not just ctx.http. You author build_request and parse_response scripts (sandbox-compiled), with OAuth2 and auth-header resolution brokered by the bridge and SSRF-checked egress. This is the supported way to integrate an arbitrary REST API today. See Generic HTTP/REST connector.
Generic JDBC connector — any JDBC-compatible database via a configurable driver/URL and uploaded JAR. See Generic JDBC connector.

Beyond these, Stingray builds native adapters on request, and customers with developers can build their own connectors against the adapter contract. The full connector inventory with per-operator detail lives in the connector capability matrix.

Pipeline Runtime

Pipelines are Python modules, each with a single async entry point:

async def run(ctx):
    rows = await ctx.adapters.mssql.read({"query": "SELECT TOP 10 * FROM orders"})
    await ctx.logger.info("fetched rows", count=len(rows))
    return {"rows": rows}

Each pipeline is compiled under a sandbox with an import allowlist; exec, eval, file I/O, and unrestricted network calls are stripped at the AST level before execution. The ctx SDK provides ctx.adapters, ctx.secrets, ctx.http (allowlisted, SSRF-checked), ctx.logger, ctx.workspace, ctx.variables, ctx.files, and ctx.nexus (to launch child runs). See the pipeline SDK reference.

Execution primitives that have shipped:

Durable run queue — a Postgres run_queue with FOR UPDATE SKIP LOCKED claiming and LISTEN/NOTIFY dispatch; run state is persisted in pipeline_runs.
Per-run wall-clock timeouts — default 3600s, hard ceiling 6h, overridable per pipeline with a # nexus:timeout directive, enforced by the worker wrapper.
Pipeline constraints — defense-in-depth caps on the maximum rows read, created, updated, and deleted per run.
Concurrency controls — a global semaphore queue (default max 5 concurrent), a worker cap of 10, and a per-tenant 429 cap. This is a queue that delays work, not a rejecting limiter. A bridge connection governor caps per-replica DB connections and reaps orphans.
Cron scheduling with exactly-once firing — wall-clock-aligned ticks, a compare-and-swap claim, and cross-replica Postgres advisory locks ensure a scheduled tick fires once. Exactly-once applies to firing only; queue dispatch is at-least-once at the claim boundary, and there is no end-to-end exactly-once pipeline execution.
Run cancellation — Nexus requests cancellation. A live in-memory task is cooperatively cancelled; otherwise the run is marked cancelled in the DB, and the isolated-worker path can terminate the process. It is best-effort, not guaranteed termination.
Run history and diagnostics — full run detail, structured logs, and the complete traceback on failure are persisted per run. Orphaned runs are detected by a heartbeat reaper.

What the runtime does not do, so there is no confusion: there is no automatic run-level retry or exponential backoff, and no dead-letter queue. (Bounded backoff exists only for adapter HTTP 429s and child-run polling.) The reliability primitives, the idempotent-pipeline pattern buyers use today, and what is marked roadmap are documented in Reliability & operations.

Role-Based Access Control

Nexus ships a multi-layer RBAC model applied uniformly across the REST API and the embedded MCP server:

Tenant roles — the built-in Reader and Admin roles (plus custom roles) control the baseline of what a principal can see and do.
Per-resource scoped grants — narrow a grant to specific pipelines, reports, bridges, files, sites, or tools, for both users and app principals. A Reader granted one report can run that report and nothing else.
App-principal roles — API keys and registered OAuth apps are assigned roles the same way users are, so service-to-service access needs no workaround.
Execution roles / assume-role — pin a curated role to a pipeline or report so a low-privilege caller can opt a single run into that role's permissions, with no standing elevation.
Admin edit-locks on sensitive resources.
Credential isolation — a service bridge holds a shared, admin-managed credential; a user bridge holds a user's personal credential. The system enforces that a user's credentials can never resolve for another user, regardless of how a request is crafted.

The same RBAC and audit trail govern the embedded MCP server — AI agents act strictly within the connecting identity's permissions. See Roles & RBAC and Execution roles.

Sites (Hosted Web Pages)

Nexus serves tenant-authored static web pages from /sites/{slug}/. A hosted page calls the Nexus REST API as the viewing user, inheriting that user's RBAC exactly — it cannot exceed it or exfiltrate a bearer token.

Upload HTML, CSS, JavaScript, images, and JSON via REST or the MCP.
Pages are served under a strict Content Security Policy (script-src 'self', connect-src 'self' login.microsoftonline.com). This CSP is a Sites feature; it is not a platform-wide server-enforced CSP.
A first-party nexus-client.js SDK handles authentication transparently — no token ever appears in page JavaScript.
Draft and published states, a per-site slug, and a configurable default_document.
Sites render in the desktop app via a dedicated WebView, with standalone browsers as a fallback.
AI agents can author and deploy a complete site end-to-end through the MCP tools.

See Sites overview.

Version Control

Every pipeline, report, site, and skill is backed by a per-tenant git repository stored on Azure Files. History, diff, and restore are available through both the REST API and the MCP.

# Inspect what changed between two saved versions
uql_diff     kind=pipeline  id=<pipeline_id>  a=<sha_a>  b=<sha_b>

# Restore a previous version
uql_restore  kind=pipeline  id=<pipeline_id>  ref=<sha>

Writes take an advisory lock on the shared Azure Files mount, so version writes are multi-replica safe; reads are lock-free. See Version control.

Internal Workspace

Every tenant includes a baked-in PostgreSQL workspace reachable from pipelines via ctx.workspace. Pipelines create tables, insert rows, and query across them within or across runs. The workspace runs on its own database with its own managed identity, structurally isolated from Nexus operational tables — UQL literally cannot reach the operational schema, and no bridge credential can reach the workspace.

async def run(ctx):
    await ctx.workspace.create_table("staging", [
        {"name": "id", "type": "integer"},
        {"name": "value", "type": "text"},
    ])
    await ctx.workspace.insert("staging", [{"id": 1, "value": "hello"}])
    return {"rows": await ctx.workspace.query("SELECT * FROM staging")}

See Internal workspace.

MCP and AI Integration

Nexus ships an embedded MCP (Model Context Protocol) server that mirrors the REST surface, governed by the same RBAC and audit trail. Connected agents and tools can:

List and query bridges (list_bridges, discover_schema, query_data).
Create, save, validate, and run pipelines.
Author and publish reports and sites.
Inspect version history and restore prior versions.
Manage files, secrets, roles, and grants — always within the caller's permissions.

The MCP server is reachable from the desktop app and from any MCP-capable client via the local proxy. See MCP server and Connecting AI agents.

Files

Nexus provides a unified file store for pipeline outputs, attachments, and site assets. Files are persisted inline in PostgreSQL or in Azure Blob Storage based on size — transparently to callers — and are accessible via the REST API and within pipelines through ctx.files. See Files.

Skills

Administrators author skills — Markdown guides that AI agents consult during tasks. Nexus ships system skills baked into the image, including a master directory agents pull first; tenant-authored skills are version-controlled alongside pipelines and reports. See Skills.

Identity

Identity is Microsoft Entra ID. Users sign in with OAuth2 + PKCE; automation authenticates with scoped app tokens or API keys. The desktop app stores tokens in the OS keyring. See Identity.

Signing, Secrets, and Egress

Signing keys live in Key Vault behind a 5-minute TTL cache and a circuit breaker, on a NIST 90-day rotation. Outbound traffic is constrained by an application-layer egress allowlist and a network-layer NSG, and all outbound HTTP is SSRF-checked. Supply-chain integrity for adapter bundles is covered under Supply-chain integrity.

Deployment Model

Nexus runs entirely inside your Azure subscription — there is no Stingray-hosted data plane. Each tenant gets a Container App, a PostgreSQL Flexible Server (managed-identity auth, DB passwords disabled), a Key Vault, a VNet with an NSG egress allowlist and a private endpoint to the database, and Azure Files for pipeline state and version history. See Marketplace deployment.

Telemetry

Nexus emits structured telemetry — pipeline runs, errors, bridge queries — to Cosmos DB in the Stingray-operated control plane, aggregated per tenant for billing and cost reporting. Telemetry can be toggled per tenant from the admin panel. See Audit & telemetry.

How releases work

Nexus ships as two coordinated artifacts: a server image on the 2.1.x line, and the managed-app offer that provisions and updates a tenant's Azure resources.

Image-only updates — when a release changes only the server image, you apply it in-app with the "pull the update" flow. No portal action is needed.
Infrastructure updates — when a release changes the provisioned Azure resources (new resource types, network or identity changes), you apply a managed-app Update from the Azure portal, which reconciles the tenant's deployment.

Because each tenant runs its own image, tenants can be on different 2.1.x revisions — our two live tenants, stingraytest (commercial) and Delva (Azure Government / GCC-High), are updated independently, and a cross-cloud image pull into Azure Government is proven. See Updates.