Skip to main content
nx1-deployer image v1.16.0
The August 2026 release for non-web portal users adds new API endpoints across the AI router, code scanning, S3 credentials, and data quality. It also adds disaster recovery support and fixes multi-site domain and cache issues in Keycloak. AI API, Metastore, and Keycloak also gain autoscaling, and Kyuubi and S3 Gateway get reliability fixes.

New features

New features recently added to the NexusOne platform.

AI router classifier management

The NX1 LLM router now supports classifiers that tag incoming requests with a DataHub domain, so the router’s decision rules can act on that domain. You can manage those classifiers and publish them to the router’s live config through the following new API endpoints:

AutoLLM fine-tuning

AutoLLM is a new pipeline for fine-tuning your own large language models. A CrewAI run first assembles a DataHub domain’s knowledge into a Q/A training dataset, which you review and approve before it trains. Its new API endpoints include the following:

Code scanner

The code scanner scans a Spark codebase for changes needed to migrate it to NexusOne, and flags each issue by severity. Its new API endpoints include the following:

Data migration

A new Count data migration runs matching filters endpoint returns a count of migration runs matching a filter, without listing them all.

Data quality rule suggestions

CrewAI already suggests data quality rules from a table’s sample data. You can now preview a suggestion’s matching data before promoting it to a real rule, or create rules in bulk. The new API endpoints include the following:

Inferencing

Deploying a fine-tuned AutoLLM model with vLLM applies its Kubernetes manifests and registers it with the NX1 LLM router automatically. You can do this through the following new API endpoints:

S3 credential vending

You can now generate, view, and delete your own S3 access credentials, and vend credentials for a specific bucket or the platform default. The new API endpoints include the following:

Bug fixes

Fixes to issues affecting apps or features on the NexusOne platform.

AI API no longer blocks on Trino during a fresh tenant deployment

AI API is NexusOne’s natural language SQL and data engineering service. Its pod mounts two Trino-managed Kubernetes volumes at startup:
  • trino-s3: S3 access config that Trino also uses
  • trino-gateway-routing-rules: Routing config that Trino Gateway uses to reach the right Trino cluster.
AI API reads from those volumes whenever it calls Trino to run the SQL it generates. In previous releases, Terraform defined those volumes inside the Trino and Trino Gateway modules. But portal, which deploys AI API, had no dependency on either. That meant AI API’s pod could start on a fresh tenant deployment before the volumes even existed, and it would just sit pending. In this release, Terraform moves the two volumes out of the Trino and Trino Gateway modules into standalone top-level resources. The Trino, Trino Gateway, and portal modules now all explicitly depend on them. AI API’s pod no longer waits on Trino during a fresh deployment.

Data shares catalog URL now uses a global domain

The data shares credential feature lets one NexusOne tenant share Iceberg datasets with another, through a Gravitino Iceberg REST Catalog (IRC) server. In previous releases, NX1 Portal showed that server’s URL using only the local domain Terraform variable. A consumer tenant on a different cluster can’t reach a local-only URL. The portal now shows the IRC server’s URL at a global_domain Terraform variable by default. The portal still shows the domain URL too, but only as a fallback when global_domain and domain are different.

DR support

DataHub’s OpenSearch previously had no way to keep a standby site’s data current. There was no multi-site snapshot support, no security plugin protecting the search API, and no way to point DataHub at the active site. JupyterHub’s database schema also had no cluster namespacing, so primary and DR sites sharing one database would collide. DR support is now built into the shared services core and modules layers, covering the following:
  • OpenSearch snapshot scheduling: The main site snapshots OpenSearch to S3 hourly now, not every 6 hours. This affects standby and demoted sites as follows:
    • Standby site auto-restores the main site’s latest snapshot.
    • Standby site can use the main site’s snapshot bucket directly, instead of its own.
    • Demoted site now deletes its own snapshot policy instead of pausing it, so gaps don’t appear silently after promotion.
  • OpenSearch security: A new security plugin adds basic auth and transport TLS, and an optional external route lets DataHub follow whichever site is active.
  • Per-cluster JupyterHub schema: JupyterHub’s schema name now includes a new cluster_name Terraform variable. Setting a distinct value per site gives each one its own schema within the same shared database, instead of colliding.
  • Per-cluster Kyuubi schema: Kyuubi’s schema name now includes that same cluster_name Terraform variable, so it gets its own schema within the same shared database too. It falls back to the workspace name automatically when cluster_name isn’t set.

Keycloak

This release includes Keycloak fixes for multi-site domain routing, cache staleness on standby-to-main site promotion, and Active Directory sync.

Domain routing fixes

NexusOne supports multi-site DR pairs, a main site and a standby site. Some components need a domain that resolves to whichever site is currently active, so users don’t have to know which one is live. In previous releases, a few components used the alternate_domain Terraform variable to provide that active-site domain. Airflow stayed hardcoded to the local domain instead, breaking access through the second domain. This release renames alternate_domain to global_domain. Airflow’s webserver URL and Trino connections now follow that variable when it’s set.

Cache staleness on site promotion

The main and standby NexusOne sites each run their own Keycloak, but the two share a database and previously ran separate caches. Promoting a standby site to main could leave stale realm and user data. Users could see outdated group or role assignments until those cache entries expired on their own. In this release, a new cache-clear job runs on site promotion and clears stale user, realm, and keys caches. That job needs to run in Keycloak’s own image, which was previously hardcoded. The image tag is now the keycloak_tag Terraform variable, default 26.5.6.1, and the keycloak_image output tracks it automatically for the job.

Faster and more frequent Active Directory sync

Keycloak previously checked Active Directory for group and role changes only once a day. In this release, Keycloak checks every 6 hours instead, so those changes reach Keycloak faster.

S3 Gateway now enforces Ranger policy consistently

The S3 Gateway had the following two authorization issues in previous releases:
  • Ranger policy and the bucket’s own legacy policy or Access Control List (ACL) ran separately for every request. They could give conflicting answers for the same request.
  • The copy-source read that happens during a copy operation doesn’t route through Ranger’s central authorization hook.
In this release, S3 Gateway makes Ranger the single source of truth for authorization. The gateway no longer checks the legacy bucket policy or ACL path, though read-only and object-lock checks still apply separately. The copy-source read is now explicitly authorized through Ranger too. This applies consistently across AI API and Keycloak-session accounts.

Session and job recovery for Kyuubi database failover

When you connect to Spark through Kyuubi, Kyuubi creates a session for each connection. Each session gets a Spark engine to run its jobs. MetadataManager stores that session, engine, and job metadata in a managed database, and reads it back when needed. In previous releases, that database could fail over and cause MetadataManager’s reads to fail instead of retrying. This caused a Kyuubi session’s jobs to restart or drop instead of continuing. In this release, Kyuubi now retries failed MetadataManager reads a few times, while waiting longer between each try. When a database failover happens, it no longer interrupts a session or its running jobs. MetadataManager writes are also now protected from concurrent-write conflicts, so job history stays consistent across a failover. Lastly, Kyuubi stops logging MetadataManager errors during failover, since the previous retry already resolves them.

Superset’s Trino connection now uses a global domain

Superset’s Trino connection config lives in a database that primary and DR sites share. In previous releases, that config’s Trino host value used the local domain Terraform variable. Two sites writing their own local Trino host value to the same shared row meant whichever site’s init job ran last would win. The other site was then left with a config pointing at a Trino host it can’t reach. Superset’s Trino host now uses a global_domain Terraform variable instead. That name resolves to whichever site is currently active, so the config stays valid from either cluster.

Enhancements

Enhancements to existing app features on the NexusOne platform.

AI API now scales automatically with load

AI API previously ran a fixed 2 replicas, with hardcoded CPU and memory limits. That worked exactly as configured, but it couldn’t grow under heavy load or shrink when idle. In this release, a Kubernetes HorizontalPodAutoscaler scales AI API automatically, using the following new Terraform variables:
  • Scales between the hpa_min_replicas and hpa_max_replicas variables, 2 and 6 by default.
  • Adds or removes pods when average CPU usage crosses the target percentage in the hpa_target_cpu variable.
  • The hpa_memory_enabled variable adds pods when memory crosses the hpa_memory_average_value variable, independent of CPU. It never triggers a scale-down, since memory usage doesn’t reliably drop even when idle.
  • Scale-up is immediate. Scale-down waits the hpa_scaledown_stabilization variable’s seconds. It removes one pod at a time.
  • CPU and memory requests/limits are now configured via the cpu_request, cpu_limit, memory_request, and memory_limit variables.

DataHub editor and reader roles now available through Keycloak

DataHub has three built-in access levels, Admin, Editor, and Reader. In previous releases, Keycloak could only grant the Admin role. Assigning Editor or Reader access required configuring it manually inside DataHub instead. In this release, two new Keycloak realm roles, datahub-editor and datahub-reader, grant DataHub’s Editor and Reader roles the same way Admin already worked. All three DataHub access levels are now assignable directly through Keycloak.

kyuubi-submit can now authenticate with a Keycloak token

The kyuubi-submit command-line tool already supported a --token flag for Bearer-token authentication, as an alternative to --username/--password. In previous releases, there was no way to actually obtain a token, since no Keycloak client existed for it. In this release, users can request a token from Keycloak directly by specifying client_id=kyuubi-cli. That token carries the user’s realm roles as a groups claim, for downstream authorization. Users can then pass that generated token to kyuubi-submit --token instead of a username and password.

Spark History Server URL now also shows running jobs

Spark’s built-in job UI shows live progress, stages, and executors. It lives on the job’s own driver pod, though, at a port that changes with every job. The Spark History Server serves a saved copy of that page once a job finishes, at a fixed, familiar URL. But visiting that URL for a still-running job didn’t work, since History Server only has saved copies. In this release, the History Server’s URL routes through a new spark-web-proxy service instead. It checks whether a job is still running and forwards to that job’s live page. If the job already finished, then it forwards to the History Server’s saved copy like before.

T-shirt sizing extends to Metastore and Keycloak

Kyuubi already supported t-shirt sizing, with small, medium, large, and xlarge tiers, each setting replicas, CPU, memory, and JVM heap together. Metastore and Keycloak didn’t. Their sizing stayed hardcoded regardless of tenant size. In this release, Metastore reuses the existing kyuubi_sizing variable to size itself alongside Kyuubi, since the two scale together. Keycloak gets its own new tiers through the existing datahub_sizing variable instead. Both changes cover the following:
  • Metastore’s replica count now varies by tier, from 2 to 6.
  • Keycloak gains real autoscaling for the first time, based on CPU usage.
  • Keycloak’s minimum replicas never drops below 2, so its session cache always keeps more than one copy.
  • Both now scale their JVM heap size with the tier too. Previously, the heap stayed fixed even after raising the memory limit, so the extra memory went unused.

Upgrades

Version upgrades to existing apps on the NexusOne platform.

JupyterHub 5.4-nx1.10.1 upgrade

Upgraded JupyterHub from 5.4-nx1.6-slim to 5.4-nx1.10.1. The 5.4-nx1.9 and 5.4-nx1.10 upgrades happened in the middle of this release.

Metastore 3.1.7 upgrade

Upgraded Metastore from 3.1.4 to 3.1.7. The 3.1.5 and 3.1.6 upgrades happened in the middle of this release.

S3 gateway v0.17 upgrade

Upgraded S3 Gateway from v0.15 to v0.17. The v0.16 upgrade happened in the middle of this release.