BullSequana AI 1.3.0

← All release notes

Released: September 4, 2026

Choose your deployment path

Use the path that matches the state of the target environment before changing a cluster.

The automated path assumes a known 1.2.1 baseline. A deployment that has changed platform templates, generated manifests, Argo CD applications, component versions, or stateful-service configuration is an advanced case even when its reported platform version is 1.2.1.

Executive summary

BullSequana AI 1.3.0 introduces organization-aware tenant administration and tenant-scoped application data. Platform administrators can create, monitor, and delete tenants through a guided Administration workspace, while BSQAI Tenant Operator 0.5.0 turns each tenant request into observable identity and infrastructure reconciliation. Users who belong to more than one Keycloak Organization can switch their active organization, and the portal and BSQAI API carry that tenant context through chats, files, agents, API keys, model presets, settings, branding, web search, and document-intelligence configuration.

Model serving uses KServe 0.20.0 and a dedicated inference application layer. The release provides CPU and NVIDIA GPU runtime profiles, including 1-, 2-, 4-, and 8-GPU profiles, private inference routing through the backend and LiteLLM, direct S3 model streaming, and expanded model-serving observability.

The portal and API add MCP Server management, web-search provider configuration, image attachments, microphone input, batch speech transcription, real-time text-to-speech, AI-interaction disclosure, and machine-readable provenance headers. The release also adds Lakekeeper, Tuples, automatic Kubeflow user-and-space bucket provisioning, and the Spark Operator to the Data stack.

The platform deployment layer gains installable bsqai CLI entry-point support, a resumable 1.2.1-to-1.3.0 upgrade workflow, resource-sizing presets, stable generated secrets, external object-storage configuration, safer Keycloak and PostgreSQL upgrades, stronger air-gap and private-CA support, and a broad security and dependency refresh.

What's new

Tenant administration and isolation

• Administration workspace: platform administrators now have a separate workspace with a guided tenant-creation wizard, live provisioning progress, a filterable tenant registry, and dedicated overview, services, and lifecycle-health views. Tenant-scoped sections cover General, Access Control, Vector Store, Theme, Service Desk, Integrations, and Allowed Resource Profiles. The previous settings URLs redirect to the new locations.

• Tenant lifecycle control plane: creating or deleting a tenant is an asynchronous workflow rather than a blocking portal operation. PostgreSQL stores the requested state, Temporal runs the durable workflow, and progress and failures flow back to the Administration workspace. Keycloak identity is mandatory for every tenant; a dedicated CloudNativePG database can be selected during provisioning.

• BSQAI Tenant Operator 0.5.0: one declarative PlatformTenant resource reconciles the tenant namespace, ResourceQuota, LimitRange, Keycloak Organization, and optional object-storage buckets and CloudNativePG database resources. The operator reports readiness separately for namespace, identity, storage, and database layers, preserves generated database credentials across reconciliations, and protects deletion with ordered cleanup and a finalizer.

• Organization-aware sessions: Keycloak Organization UUIDs are the canonical tenant identifiers. Users with multiple memberships select an organization from the portal. The selection persists per user, and API requests carry the active tenant as X-Tenant-Id.

• Tenant-scoped application records: tenant filters now apply to chats and responses, library files and folders, agent configurations, API keys, model presets, active resource profiles, system configuration, translations, branding, web-search credentials, and persisted document-intelligence configuration and orchestration runs. Cross-tenant identifiers are returned as not found rather than exposing whether another tenant owns the resource.

• Tenant-scoped RAG collections: the BSQAI API derives Milvus collection names from the canonical tenant UUID, embedding model, and dimension. Collection operations expose only the active tenant's namespace, while search and Responses API file search accept only that tenant's active collection. Existing configured legacy collections remain usable until a tenant reindex completes and are preserved during tenant-scoped cleanup.

• Curated tenant model catalog: the backend seeds 21 open-weight presets spanning text generation, multimodal, embedding, and reranking workloads for the global organization and each newly provisioned tenant. Administrators can tailor the catalog per tenant; edits and intentional deletions are preserved, and multi-GPU presets map to matching KServe runtime profiles.

See Administration and operations, BSQAI Tenant Operator, Portal model presets, and Multi-tenancy and tiered RBAC.

Portal and AI workflows

• MCP Servers: administrators can register managed MCP containers or remote MCP Servers, restrict their exposed tools with an allowlist, and inspect runtime status. Each user links a personal upstream credential through OAuth or a one-time secret entry. The MCP Gateway removes the platform credential before forwarding a request and injects the linked upstream credential. MCP Servers can be selected for a chat or attached to an Agent.

  Start with MCP Servers. Administrators can follow Add an MCP Server and Restrict which tools an MCP Server offers. Members can follow Link your credential to an MCP Server and Use an MCP Server in chat. External clients use Connect an MCP client to the Gateway.

• Web search providers: tenant administrators can configure Tavily, Brave, Exa, DuckDuckGo, or a custom HTTPS provider. Provider keys are encrypted at rest and returned only in masked form. One provider is active per tenant, with DuckDuckGo used when no configured provider is available. The selected provider supplies the web_search chat tool.

• Voice input in chat: the chat composer now includes a microphone control. Speech is transcribed through the real-time STT endpoint, appears in the text field, and can be edited before sending. The portal reports microphone permission, device, browser, connection, and transcription errors separately.

• Image attachments: users can paste or attach PNG and JPEG images to a chat with a vision-capable model. Images remain visible after the conversation is reloaded. Document attachments continue through the existing library and RAG path.

• AI disclosure: chat and Service Desk surfaces now state that the user is interacting with AI at the start of an interaction and retain a shorter reminder during the conversation.

• Conversation state restoration: reopening a chat restores its selected model or Agent and its RAG document or folder selection. Switching between chats no longer silently falls back to a default model or loses the knowledge scope.

• Configured upload limits: file uploads in the library and chat now use the tenant's configured maximum file size instead of a hard-coded portal value.

• Model deployment form fixes: model presets and Advanced Setup preserve the selected source and target request count. Model sources use an explicit hf://, s3://, or pvc:// selector, and duplicate vLLM arguments resolve in favor of the user's last value.

• Platform service catalogue: the login page groups discovered services into AI and models, Data and ML, observability, administration, and resources. Redirect routes, raw infrastructure endpoints, duplicates, and unavailable services are filtered out.

See Use BullSequana AI, Portal, and BSQAI API.

Model serving and inference

• KServe model-serving control plane: model registration, deployment, health checks, logs, and deletion use KServe resources. KServe, its CRDs, KAI Scheduler, Envoy AI Gateway, and the Gateway API Inference Extension run in a separate inference parent application.

• Private inference path: model workloads no longer have a public inference route. Requests flow through the BSQAI API and LiteLLM before reaching KServe, retaining authentication, authorization, usage tracking, and observability.

• Runtime profiles: the release includes a CPU profile and NVIDIA GPU profiles for 1, 2, 4, and 8 GPUs. vLLM CPU and GPU images are updated to 0.28.0. Administrators size KAI Scheduler quotas to the runtime profiles supported by the site's GPU capacity.

• Direct S3 model streaming: a GPU runtime profile can stream Safetensors directly from the platform object store without local model copies. An optional, separate [model_storage] configuration supports a shared external S3 model repository with its own credentials and CA.

• Serving safeguards: vLLM workloads receive stricter security contexts, remote-media restrictions, resource limits, and storage-initializer limits. KServe and vLLM dashboards expose model, pod, and inference telemetry.

See Foundation inference and KServe.

Data and ML platform

• Lakekeeper table catalogue: Lakekeeper provides an Iceberg REST catalogue backed by OpenFGA authorization. A Keycloak Organization maps to a Lakekeeper project with a default warehouse; personal user and shared-space buckets receive additional warehouses in that tenant project.

• Tuples authorization service: the Data stack adds a service for users, groups, spaces, buckets, datasets, and tables, with Keycloak identity, OpenFGA authorization, and Kafka audit configuration.

• Kubeflow user and space buckets: when a user profile is reconciled, the provisioner creates its personal user-* bucket and ensures a space-* bucket for each space membership. It records ownership and parent-space relationships through Tuples and creates corresponding Lakekeeper warehouses in the tenant project. Removing a user profile archives only its personal bucket; shared-space buckets remain with the space.

• Spark Operator: Kubeflow Spark Operator 2.5.2 is included as a Data component, watches all namespaces, uses private-registry images, and exposes Prometheus metrics.

• CloudNativePG backups: backups now use the Barman Cloud plugin path. Scheduled backups, backup rotation, credentials, and dashboards use the plugin metrics and object-storage configuration.

See BullSequana AI Data and Build a data and ML workflow.

Reliability and observability

• Document ingestion: Docling conversion now fails quickly on invalid submissions and repeated poll errors, reports Temporal heartbeats during long jobs, and uses bounded timeouts. Embedding and insertion run in batches, reducing peak memory for large and scanned documents. Chunk sizing can follow the active embedding tokenizer.

• Docling runtime: the backend chart deploys Docling with Redis-backed RQ workers so API replicas can answer conversion-status requests without tying a task to one pod.

• RAG authorization and folder scope: document and folder permission checks are batched through OpenFGA, reducing time to first token when a request contains many resources. Folder identifiers can now scope collection search and Responses API retrieval without enumerating every file.

• Speech processing: STT container decoders preserve the source sample rate before the engine-level conversion step. Batch transcription can auto-detect a language, and real-time transcription can opt into language detection.

• Reproducible speech images: the Speaches CPU, CUDA, and pre-baked model-cache images are pinned by digest instead of mutable latest tags, keeping connected and restricted-network deployments on the reviewed artifacts.

• OpenTelemetry coverage: the backend emits spans and metrics for API operations, inference, uploads, vector search, authorization, object storage, Temporal workflows, and speech sessions. Instrumented application logs include the active trace and span context when one exists, while server spans and responses carry the request ID. User content is excluded from telemetry attributes. Portal browser telemetry export is disabled in 1.3.0, and the backend's unauthenticated browser telemetry proxy endpoint has been removed; backend server telemetry remains enabled.

• Log and telemetry pipeline: per-node Alloy collectors can route a JSON pod-log entry to a tenant-specific Loki partition when its body contains a top-level tenant_id; non-JSON and unscoped pod logs use the platform partition. The Alloy gateway sends application OTLP traces to Tempo, metrics to Prometheus, and OTLP logs to the platform Loki partition. KServe metrics are scraped separately.

• Grafana dashboards: dashboards and monitors were refreshed for Kubernetes, Gateway API, CloudNativePG, Keycloak, KServe, vLLM, Milvus, MLflow, LiteLLM, OpenFGA, Temporal, Kubeflow, Kyverno, storage, and other platform services.

Platform deployment changes

CLI and configuration

• Installable CLI entry point: an editable tool install exposes the existing Typer application as bsqai while keeping templates and environment files anchored to the repository checkout:

  uv tool install --editable . --python 3.12
  bsqai --help

• Resource sizing: component-level CPU and memory requests and limits now have explicit baselines. SIZING_PRESET accepts S, M, L, XL, or CUSTOM; explicit component environment overrides remain absolute.

• Stable generated secrets: structured secret declarations support plain, base64, and bcrypt output. When RANDOMIZE_SECRETS=true, missing secrets are generated once and persisted in generated_secrets.env so later renders reuse the same values.

• Object-storage abstraction: [object_storage] selects the in-cluster Rook-Ceph service or an external S3-compatible service and defines endpoint, addressing, CA, and capability settings. Browser-facing presigned URLs use a separately configurable public host. Rook-Ceph applies the portal CORS policy to platform-owned buckets; external S3 operators must either preconfigure that policy or explicitly opt in with manage_bucket_cors = true, which replaces the bucket's complete CORS document. See External S3 object storage.

• Portable cluster DNS: the resolver service, resolver namespace, and cluster domain are configurable for Kubernetes and OpenShift environments.

• Component topology: the inference application owns model-serving components, the backend chart owns the Docling runtime, Alloy receives OTLP traffic, and MCP workloads use the MCP Lifecycle Operator.

• Optional NVIDIA bootstrap: GPU sites can install the NVIDIA GPU Operator directly with bsqai helm-apply gpu-operator. The platform values enable node feature discovery, the device plugin, DCGM metrics, GPU feature discovery, and MIG support; cluster-provided drivers and the container toolkit remain the default.

Upgrade and GitOps safeguards

• Versioned upgrade CLI: bsqai upgrade plan, apply, and status provide a classified, resumable 1.2.1-to-1.3.0 path. The CLI fingerprints the live baseline, validates cluster and configuration gates, preserves existing credentials, publishes a create-once GitOps snapshot, checkpoints progress in the cluster, and resumes a failed run without repeating completed Applications.

• Keycloak upgrade gate: a version-aware Argo CD PreSync hook checks CloudNativePG readiness and creates a verified database backup before a Keycloak version change. It rejects downgrades and blocks the sync when the safety checks fail.

• Keycloak reconciliation: Organization support, organization UUID claims, shared client scopes, protocol mappers, and client assignments are reconciled on existing realms as well as fresh imports. Existing client secrets are preserved.

• Manifest push validation: the Git client rejects invalid YAML, test-rendered markers, and unsealed Kubernetes Secret resources before generated manifests can be committed.

• Argo CD application behavior: empty parent applications are no longer generated, completed CloudNativePG permission jobs no longer cause persistent drift, and directory-based resources are not forced through Kustomize.

• Argo CD control-plane upgrade: the customer-run 1.2.1-to-1.3.0 CLI workflow preserves the existing Argo CD admin digest, Redis credential, Keycloak client secret, and sealing key. It upgrades the existing Helm release from Argo CD 3.3.12/chart 9.5.11 to Argo CD 3.5.2/chart 10.4.1, then changes the platform Applications only after that control plane stabilizes. It does not bootstrap a replacement installation.

• Ordered GitOps cutover: the upgrade adds a temporary project-wide sync lock, pauses each Application's saved automated policy, and moves the root, parent, and child Applications to one immutable manifest ref. Foundation, inference, AI, and Data migrations pass explicit dependency, health, backup, CRD, and hook gates before automation is restored.

Restricted-network and certificate support

• Air-gap hardening: deployable images, policy-embedded images, and approved Airbyte connector images use the configured private registry. The default disconnected configuration uses pre-baked assets instead of runtime downloads, and outbound product update and analytics checks are disabled where supported.

• Private registry trust: a registry CA can be supplied for OCI chart access, and an additional Docker configuration can carry credentials for other approved registries.

• Customer-managed certificates: custom wildcard certificates and their CA are propagated across namespaces. Tuples and the Ceph Dashboard trust the supplied CA, and Ceph Dashboard OIDC uses internal Keycloak endpoints where required.

• Network restrictions: optional Envoy load-balancer source ranges and Kubeflow kubelet probe CIDRs support restricted ingress and NetworkPolicy environments without changing the connected-cluster defaults.

See Platform CLI, Configuration model, and GitOps workflow.

API updates

Compatibility changes

• BSQAI API hostname: api.<platform-domain> is now the canonical public endpoint. BullSequana AI 1.3.0 retains the previous hostname as a temporary compatibility alias, but clients should migrate to the canonical endpoint or the site-specific endpoint provided by the operator.

Breaking changes

• Tenant selection: authenticated users with more than one Keycloak Organization membership must send the selected Organization UUID in X-Tenant-Id. The backend rejects missing, malformed, or unauthorized tenant selections. API keys are created and resolved within one tenant.

• Vector-store selection: API clients must now identify the selected tenant's active collection. Responses API file_search.vector_store_ids accepts exactly one identifier; requests containing multiple identifiers return 400, while inactive or foreign collection identifiers return 404.

• MCP management routes: the legacy MCP registry and deployment routes are replaced by /v1/mcp/servers plus per-user credential and OAuth routes. API clients that used the legacy routes must migrate to the new server model.

• Model preset schema: url is replaced by hf_identifier in model-preset create, update, and response schemas. Preset names are limited to 63 characters, and preset configuration adds target_requests.

• Model source schemes: model registration accepts only hf://, pvc://, and s3://. Requests using any other source scheme are rejected.

New and extended endpoints

AI-output provenance

Generative HTTP responses now include:

X-AI-Generated: true
X-AI-Provenance: model="<resolved-model>", generated-at="<timestamp>", producer="coreai-llm-backend"

The headers apply to OpenAI-compatible Responses, Anthropic-compatible Messages, portal chat responses, and chat-history reads that contain generated output. Streaming responses send the headers before the first event. The STT WebSocket carries equivalent marking on its handshake. Error responses and non-generative API surfaces are not marked.

Browsers can read both headers through CORS. Reverse proxies and external gateways must preserve them.

Security and component updates

The Rook-Ceph update patches CVE-2025-30156, CVE-2026-39944, CVE-2026-50152, and CVE-2026-54330. An idempotent CephX migration rotates daemon keys to the stronger format while retaining the CSI key type required by older kernels. A single RGW replica can have brief S3 outages while it rolls; sites requiring uninterrupted object access need at least two RGW replicas with topology spread or anti-affinity, an appropriate PodDisruptionBudget, and continuous-I/O upgrade validation. Superset is rebuilt from its upstream 4.1.4 source with the platform's required extensions, and the wider dependency refresh updates Argo Events, Argo Workflows, cert-manager, External Secrets, Grafana Alloy, Loki, OpenBao, OpenFGA, OAuth2 Proxy, Reflector, Tempo, and other platform services.