Documentation / Deployment

Updates & Versioning

How Nexus instances receive new platform versions through a publish-and-pull model — the difference between an in-place image pull and a Marketplace managed-app Update, how single-revision rollout works, how versions are pinned and signed, and how to verify health afterward.

Nexus by Stingray ships new platform versions through a publish-and-pull model: Stingray publishes each release, and your instance picks it up when you choose to apply it. Nothing changes in your environment until you act. This page is for administrators and operators who own a Nexus deployment and need to understand how updates flow, the two ways an update reaches a running instance, and how versions stay coordinated and signed.

How updates work

Every Nexus instance runs inside your own Azure subscription as a Marketplace managed application, and Stingray never reaches into your tenant to force a change. The flow is:

Stingray publishes a release — a new server image plus the signed adapter and toolkit bundles that pair with it, and (when provisioning changes) a new managed-app offer version.
The control plane advertises it — the shared Stingray-side control plane records which version is current and lets your instance discover that a newer one exists. This carries version metadata only; it does not push anything into your tenant.
You apply it — you decide when to roll forward, aligning updates with your own change windows and validating in a non-production instance first if you run more than one.

This keeps timing entirely in your hands. There is no forced-rollout window and no surprise change during business-critical periods.

Versioning

Nexus uses semantic versioning (MAJOR.MINOR.PATCH) across the platform's coordinated artifacts, which are released together so that any given server version always has compatible, signed bundles available:

Artifact	What it covers
Nexus server	The per-tenant FastAPI server, REST API, UQL engine, MCP surface, pipeline runtime, and built-in features.
Adapter & toolkit bundles	Signed connectors (PostgreSQL, MySQL, SQL Server, JDBC, NetSuite, QuickBooks, Monday, Stripe) and shared toolkits.
Managed-app offer	The Marketplace template that provisions and configures your instance.
Bundled web UI	The web app baked into the server image, version-pinned to the server so the UI and API never skew.

Because these ship as a set, an update never lands a server that expects bundles it cannot verify. Every adapter bundle is cryptographically signed and verified fail-closed at load time — a bundle that does not verify does not load — so an update can never weaken the trust chain. The signing and verification model is covered in the connectors overview.

Checking for updates

Your instance checks the Stingray control plane for newer versions and surfaces what is available, on demand, without applying anything. Using the Nexus MCP, an operator can ask:

uql_check_updates

This reports the version your instance is currently running and whether a newer release has been published. The same information is available in the desktop app's status views.

Applying an update

There are two ways a new version reaches a running instance, and which one applies depends on what changed in the release.

Image-only updates (pull in place)

When a release changes only the running server version — the container image and its bundled UI, with no change to how the tenant is provisioned — an operator can roll it forward in place. Using the MCP:

uql_pull_updates

Your instance updates its own container to the published version. This self-update path is scoped narrowly to your instance's own compute resource and touches nothing else in the deployment — not the database, not Key Vault, not the network. The rollout is single-revision: the new revision replaces the old one and takes all traffic, rather than stacking multiple live revisions. That keeps resource use predictable and avoids two versions of the server contending for the same per-tenant database connections during a rollout.

Because migrations run automatically on startup, an image pull that includes a schema change applies that migration as the new revision boots; readiness will not report healthy until migrations are applied.

Template updates (managed-app Update)

When a release also changes how your tenant is provisioned — new configuration, additional permissions, networking changes, or new resources — it is applied as a Marketplace managed-app Update, which re-runs the deployment template:

In the Azure portal, open your managed application resource.
Choose Update and select the new offer version.
Azure re-applies the deployment template, which updates configuration and rolls the server to the new version.

Because deployments are incremental, your stateful resources — the Azure Files share, the PostgreSQL database — are preserved across the update; only what the template declares as changed is changed. After the update completes, your connectors, signing trust, and configuration are re-applied to match the new release.

Which path do I use?

If the release…	Apply it via	Touches
Changes only the server image / bundled UI	`uql_pull_updates` (in place)	Your Container App revision only
Changes provisioning, permissions, or networking	Managed-app Update in the portal	The declared template resources (state preserved)

uql_check_updates tells you a newer version exists; the release notes indicate whether it is image-only or requires a template Update. When in doubt, the managed-app Update path is always safe because it reconciles the full template.

After updating

Once an update has applied, confirm the instance came back cleanly:

Verify the running version reflects the release you applied (uql_health reports it).
Confirm your data sources are connected and adapters loaded (uql_list_bridges_status).
Run a quick query or report against a known bridge to confirm end-to-end access.

The MCP uql_health and uql_list_bridges_status tools, or the desktop app's status views, give a fast confirmation. If you connect over MCP, note that the session may drop as the revision swaps — reconnect before verifying.

What this does and doesn't do

Updates are opt-in and operator-timed; Stingray does not force or schedule them into your tenant.
Image pulls are in-place, single-revision, and scoped to your compute — they do not alter your database, secrets, or network.
Versioning is coordinated and signed across server, bundles, and UI, so components never skew and every bundle is verified fail-closed.
There is no automatic rollback; the safe pattern is to validate a release in a non-production instance before applying it to production.

Staying current

Newer releases bring connector improvements, performance work, and security hardening. The recommended rhythm:

Check periodically with uql_check_updates so you know when a version is available.
Validate in a non-production instance first if you run more than one.
Apply during your own change window — the pull model means the timing is always yours.