Skip to main content

What's New

Recent Hrida.ai Studio features and changes: backups and container images, knowledge base sync API, API alerts, analytics across APIs, gateway metrics, API analytics and call log archiving, office-skills upload for AI document skills, SOAP and WSDL support, API Tools for agents, shared APIs, interface languages, API Builder AI assistant, environments, consumer keys, gateway resilience, admin API catalogs, sidebar layout, spam filtering, and removed integrations.

Recent features and changes in Hrida.ai Studio. Each item links to its full documentation.

Look and feel​

🏢 A calmer, corporate look​

  • One accent colour. Buttons, tabs, toggles and focus rings are all brand indigo, matching zlabs.digital and these docs; they used to mix violet, coral, blue and green. Greys are cool slate in light mode and navy in dark mode, text and headings are Inter, corners are crisper, and buttons no longer shrink when pressed or cards lift on hover.
  • Sign-in follows your theme. The sign-in page used to be black even in light mode, with mismatched fields. It's now a light or navy card, depending on your theme, with matching fields and the brand button.
  • Chat answers are formatted again. Headings, bullet and numbered lists, links and quotes in answers had lost their styling and showed as plain text.
  • A chat opens at its last message, fully in view, instead of stopping a little short of it.
  • Dark mode is the same dark mode everywhere. Choosing Dark in settings used to switch to neutral greys until the next reload; it now matches a fresh load.

Performance​

🧵 Each chat message does less work, and chats open at their end​

  • Fewer lookups per message. A message used to run 28 database queries before and after its answer, and about 10 blocking Redis lookups of the model list. Filter functions were looked up three times per message; the model's settings, your API key and your OAuth session twice each; and the usage limits with your groups on every message. These are now kept by each Studio process and dropped the moment one changes, in every replica (within 30 seconds when there is no Redis). A message now runs 13 queries and no blocking Redis lookups. In a 200-message chat the first words arrive in 60 ms instead of 98 ms, with a third less server CPU; with 16 people sending at once, in 287 ms instead of 606 ms. → MODELS_REGISTRY_CACHE_SECONDS
  • Less work per streamed token. On every token, Studio rebuilt its reasoning-tag patterns and searched the whole answer so far for each one. It now builds each pattern once and searches only the end of the answer, where a new tag can appear. A streamed token costs 0.41 ms of server CPU instead of 0.58 ms, and a 5,000-token answer 2.5 s instead of 3.4 s.
  • Chats open at their end, with only what's on screen. A chat used to open at the top and scroll smoothly through the whole conversation. Meanwhile the "load more" loader at the top was in view and kept loading older messages: opening a 100-message chat rendered about 40 messages instead of 9. A chat now opens at its last message at once, and older messages load when you scroll up. Opening that chat is done in 0.7 s after its data arrives instead of 1.7 s, and a chat with two long answers in 0.17 s instead of 0.65 s.
  • A tab in use for hours stays as fast. Every message shown registered the Markdown extensions again, so each later message, and every streamed update, took a little longer to render. They're now registered once.

💬 Chats answer sooner and stream with a fraction of the work​

  • Sending a message saves it with one read and one write of the chat, instead of reading the whole conversation 13 times and writing it 5 times. In a 200-message chat, Studio hands the message to the model in about half the time (the send request takes 92 ms instead of 184 ms); with 16 people sending at once, 314 ms instead of 905 ms. Two changes to one chat at the same moment (a status update while an answer is saved, two models answering) no longer overwrite each other.
  • Streaming answers send the answer so far at most every 50 ms instead of on every token: a 1,500-token answer is 91 updates (373 KB) instead of 1,507 (6.2 MB) through Redis and the browser, and takes half the server CPU. The first words aren't delayed. → CHAT_RESPONSE_STREAM_UPDATE_INTERVAL_MS
  • After an answer, the whole conversation is no longer sent back to the browser: only the messages an outlet filter changed, and nothing at all (not even the lookup) when the model has no outlet filters.

🖥️ The main pane no longer lags behind the sidebar​

  • The model list doesn't wait for the providers. Every page load lists the models, and whenever a user's copy was more than a second old, the page waited for each provider's model list. Now the last copy is shown while a background request refreshes it. The list's database part (workspace models, functions) stays in memory until one of them changes, and the shared copy in Redis is only rewritten when it changes. With a provider that takes 400 ms to list its models, a page load gets the list in 8 ms instead of 440 ms, and the endpoint serves about six times as many requests under load. → MODELS_CACHE_TTL
  • The main pane waits only for what it needs. It shows once the models and your settings are in; banners and tools load alongside. The model list is requested as the app starts, the message editor downloads with the page instead of after it, and a chat's tags and running tasks are fetched together with the chat. On a first visit, the main pane now shows within half a second of the sidebar instead of 1.2 to 1.4 seconds later.
  • Opening a chat no longer writes it back. A chat used to be saved again 400 ms after it opened, which also moved it to the top of the chat list. The Overview tab's diagram library now loads when that tab is shown, not with every chat.

⚡ Studio serves requests twice as fast​

Every request Studio serves now does less work before it reaches its handler: it finds its route among the few whose path prefix fits instead of trying hundreds in turn, a rate-limit middleware that scanned every route on every request without enforcing anything is gone, and settings are read from Redis at most once a second instead of on every read (each read blocked the server). Long garbage-collection pauses, about half a second several times a minute under load, are gone too. In a load test, one Studio worker went from about 170 to about 430 API calls per second, and its slowest 1% of requests from about 480 ms to about 100 ms. Pages, chat and APIs all benefit. → Configuration

🏎️ Pages load faster, and Studio keeps up under load​

  • The web app's files come from memory. Each file is read and compressed once instead of on every request: a JavaScript file went from about 14 ms to under 1 ms, so a first page load after a deploy, which fetches over a hundred of them, no longer keeps a server busy. → FRONTEND_ASSET_CACHE_MB
  • Pages show sooner. A page now needs a third of the JavaScript it used to (3 MB instead of 8 MB for the chat home page): the diagram, maths, code-highlighting, terminal and code-editor libraries load when something uses them, not with every page. Fonts are sent as WOFF2 (Inter 318 KB instead of 785 KB) and kept by the browser for a week, and the app's startup requests run side by side instead of one after another. With a warm browser cache the home page is ready in half a second instead of a second.
  • No more reconnecting to the database under load. Connections opened for a burst are reused instead of closed and opened again for the next request; that reconnecting cost a third of the CPU at 32 concurrent requests. Requests per second now rise with concurrency instead of falling: about 2.4 times as many for /api/config and the signed-in user check. → DATABASE_POOL_OVERFLOW_IDLE_SECONDS
  • Less work on every request. The signed-in user is kept in memory and refreshed the moment their account changes, on every server; a session token is verified once instead of on every request, and its revocation check takes one Redis round trip instead of two. A user's groups are read once instead of on each permission check (a broken Redis lookup made every check fail and query the database), the user count behind /api/config is reused, and the last-active time is written at most once a minute per user.
  • Half the memory per worker with an external embedding engine: the machine-learning stack (torch and friends) is only loaded when a local model needs it, about 480 MB less per worker. → LAZY_ML_IMPORTS

🔒 Security fixes​

  • Dependencies updated for 60+ published advisories, among them request parsing that a crafted upload or form could stall (python-multipart), JWT verification bypasses (PyJWT), request smuggling (aiohttp), image and PDF parsing (Pillow, pypdf), OAuth CSRF (Authlib), websocket memory exhaustion (python-socketio), sandbox escapes (RestrictedPython, simpleeval) and the OpenSSL bundled with cryptography. python-jose, unused and with an unfixed token-forgery flaw, is gone.
  • Sign-in: a failed sign-in takes as long whether or not the account exists, so response times no longer reveal which emails have accounts; password checks run a few at a time, so a flood of attempts can't take the server's CPU. → Sign-in protection
  • Uploaded office files and fetched sitemaps are parsed without DTDs or entities, so an "XML bomb" can't expand to gigabytes.
  • Unknown API paths (/api/...) answer 404 instead of the web page with status 200, which API clients took for success.
  • A file request under /cache/ could reach a neighbouring folder whose name starts with cache, or follow a symlink out of the cache folder.

Deployment​

🛟 Backups for production stacks, and what each image is​

  • Continuous database backups. The production stacks' PostgreSQL runs from the hrida-ai-studio-postgres image: PostgreSQL 16 with pgvector, plus WAL-G. With STUDIO_PG_BACKUP=true it ships every change to MinIO or S3 within about a minute, takes a full backup every night, and restores itself when it starts on an empty volume. → Backup & Restore
  • Off-server copies of everything else. The hrida-backup sidecar copies the files in MinIO (including the database backups), the app's data volume, LDAP and Grafana to an S3 bucket on another server, encrypted, and its restore.sh script brings each one back. It stays idle until BACKUP_ENABLED=true. → Off-server backups
  • What each package is. The four images in the registry (the app, the API gateway, the database and the backup sidecar) now say what they are on their package pages, and a new reference page lists their tags and how to pin them. → Container Images

Artifacts​

📦 Upload office-skills instead of mounting it​

AI document skills (edit, generate and convert real PowerPoint, Word, Excel and PDF files) need the office-skills repository. Admins can now upload it as a zip in Admin Panel › Settings › Artifacts: no server access, compose change or rebuild. It's saved in the database, so it survives image updates and every Studio server uses it, even replicas on several hosts; upload a new zip to update the skills. A mounted folder still works and is used when nothing is uploaded. → AI document skills (admin setup)

API Builder​

🛡️ Gateway ready for production traffic​

The API gateway now holds up under heavy, and hostile, traffic, and gives partners what they expect from a production API:

  • Exact and complete: bodies nothing changes are passed on byte for byte, so large numbers keep every digit; headers such as Location, ETag, Idempotency-Key and rate-limit headers pass both ways; large responses stream to the caller.
  • Overload protection: limits on each API's calls at once, a per-worker cap that answers 503 at once instead of queueing, a retry budget with jitter, and one upstream call for identical cache misses. Masking patterns and mapper expressions are limited in time and steps, so one bad rule can't freeze a worker.
  • For partners: consumer-key quotas per day and month, allowed addresses and client-certificate binding; access tokens (JWT) from a partner's own identity provider; CORS settings per API for web pages; Idempotency-Key support; and Deprecation / Sunset headers.
  • Abuse: made-up keys never reach the database, and floods of failed logins are throttled per address and kept out of the call log.
  • At scale: the call log is split into daily partitions on PostgreSQL; the gateway service runs from a slim image of its own (the hrida-ai-gateway package, with Studio's tags) as an unprivileged user; an optional PgBouncer stack pools database connections; Valkey's memory is capped; and the encryption key for stored secrets can be rotated. The circuit breaker is atomic across replicas, with exactly one trial call. In a load test, one gateway worker handled more than 600 calls per second. → Gateway Policy & Security · API Gateway · Dedicated Gateway Service

🚀 Dedicated gateway service, faster gateway calls​

The API gateway can now run as a service of its own, next to Studio: the same image, started with HRIDAAI_SERVICE=gateway. It serves only the gateway's URLs, can sit on its own host name (e.g. api.example.com), and gets its own replicas, so heavy API traffic no longer slows Studio. The Docker Swarm stack includes it, and new Kubernetes manifests scale it automatically with a HorizontalPodAutoscaler. Every call is also cheaper, in Studio too: upstream connections are reused, and API definitions, versions, mappers and consumer keys are cached, with any change made in Studio clearing the caches in every process at once through Redis. Rate limits and the circuit breaker no longer block the server while waiting on Redis. In a load test, one Studio worker went from about 40 to about 220 gateway calls per second, and one gateway service worker reached about 470. → Dedicated Gateway Service

🔗 Spec at the gateway URL, upstream timeout, trace context​

Each published API serves its OpenAPI spec at its gateway URL plus /openapi.json, for anyone with a consumer key or the gateway secret, so it can be loaded into Postman or added in Settings › Integrations › Manage Tool Servers. That dialog now explains a wrong URL (a documentation page, or an operation's URL) and offers the right one, and shows why a connection failed. A new Upstream timeout (seconds) setting in the gateway policy (60 by default) replaces the old instance-wide value, which had no limit unless set, and a slow POST is no longer sent again after a timeout. The upstream now gets a W3C traceparent, and its trace id comes back as X-Hrida-Trace-Id. → API Gateway

🔔 Alerts​

Add alert rules to any API and hear about trouble before your users do: error rate, availability or ≈p95 latency over a window, no traffic after a busy period, or the circuit breaker opening. Alerts go to Slack, Microsoft Teams, Google Chat, Discord, any JSON webhook, email or the app, with a resolved message when the API recovers, optional reminders, muting, retries for messages that couldn't be delivered, and a cap so a flapping service can't flood a channel. The API Builder list marks APIs with an alert firing. → Alerts

🌐 Analytics across APIs​

Admins get Admin → Dashboard → API Analytics for every API; space admins and lifecycle managers get an Analytics tab in the API Builder for their space. See the busiest, failing, slowest and fastest-growing APIs, traffic by environment, gateway, space and catalog, top consumer keys, and live APIs that nobody calls. Export it all to CSV. → Analytics across APIs

📡 Gateway metrics and usage questions​

With OpenTelemetry metrics on, the gateway exports per-API call, latency and circuit breaker metrics for Prometheus and Grafana. The AI Assistant now answers usage questions such as "why did errors go up since yesterday?" from the analytics. → Metrics for Prometheus and Grafana · AI Assistant

📈 API Analytics​

Each API's page now has an Analytics card:

  • calls, error rate, availability, latency and cache hits, each compared with the previous period
  • charts of traffic and latency
  • breakdowns by operation, environment, caller type and consumer key
  • errors grouped by who has to act on them

Filter by time range, environment, operation, caller or key, jump to the matching calls, or export to CSV.

The call log now stays small in production. Raw calls are kept for 30 days, then archived to storage as daily compressed files and deleted in batches; history lives on in hourly and daily summaries. Recording a call no longer waits on a database write. Admins set retention and archiving under Gateway settings. → API Analytics · How the call log stays small

🧼 SOAP services and WSDL import​

Put a JSON tool in front of real SOAP services:

  • SOAP 1.2 as well as 1.1, the service's target namespace (qualified or unqualified children), and one upstream endpoint path for every operation. A GET operation is sent as a SOAP POST built from its parameters.
  • SOAP Faults come back as a JSON soap_fault error, never as a result. Faults the caller caused return 400 and don't trip the circuit breaker.
  • Custom SOAP headers, and WS-Security UsernameToken upstream auth (password text or digest, with timestamp).
  • WSDL import proposes the OpenAPI spec, base URL and request/response mappers for every operation from a WSDL URL or text.
  • Responses are typed by the operation's schema (numbers, booleans, lists), and requests are sent in xs:sequence field order.
  • The mapper test now shows exactly what goes on the wire.

SOAP headers, WS-Security and WSDL import are set through the API for now. → SOAP services · Importing a WSDL · WS-Security

🤝 Shared APIs in the receiving space​

An API published to another space now appears in that space's API Builder list with a Shared badge while prod serves it. It opens read-only, and its call log shows each viewer only their own calls. → Publishing to other spaces

✨ AI Assistant​

Ask in plain language and the assistant builds, tests and debugs APIs for you, in any API catalog you can access: it drafts the OpenAPI spec, creates a draft API, tests it through the gateway, reads the call log and fixes problems. It acts as you (same permissions and audit log), can't publish or touch secrets, and only sends write requests (POST/PUT/PATCH/DELETE) when you allow it. Every reply lists the actions it took. → AI Assistant

🌱 Environments​

Promote one approved version through stages such as dev and staging before it reaches prod. Each stage has its own base URL and, optionally, its own credential. Prod keeps serving while the next version is drafted and reviewed — pulling an API back to draft no longer takes it offline. → Environments

🧪 Test console​

Send a request through the gateway from the API's page and see exactly what an agent would get: status, response, and debug headers. Works on drafts, the saved working copy, or any environment. → Testing an API

🔐 Gateway secret & consumer keys​

  • Show gateway secret on the API page gives the gateway URL, the secret and a ready-to-run curl example (audited; lifecycle managers and above).
  • Consumer keys give each outside caller its own key, with an optional expiry and rate limit, revocable on its own. Keys work in one environment only and are shown once.

→ Consumer keys · Secret rotation

⚡ Gateway protection​

  • Response validation — warn about, or reject (502), upstream responses that don't match the spec.
  • GET cache — serve repeated successful GETs without calling the upstream (up to 1 hour).
  • Circuit breaker & alerts — after repeated upstream failures, calls pause for a cooldown instead of piling on, and an alert webhook (Slack/Teams-compatible) is notified when calls pause and resume.
  • Debug headers — every gateway response says which environment, version and operation served it, and whether it came from cache.

→ Gateway Policy & Security · Debugging a call

🕘 Version history in the builder​

Every publish is snapshotted. Restore a version as a draft for review, or — during an incident — put a previously published version straight back live. → Version snapshots & rollback

🛡️ Safer lifecycle​

  • Whoever submits an API for review can't also approve it (instance admins exempt).
  • Developers can withdraw their own submission; lifecycle managers can pull a published API back to draft.
  • A space must always keep at least one space admin.

→ Lifecycle rules

🗂️ API Catalogs in the admin console​

Admin → API Catalogs manages API Builder's catalogs and spaces: grant users access with a role, see every API in a space and whether it's live, and suspend a catalog or space to stop all of its APIs at once. → Managing catalogs, spaces, and members

Agent Builder​

🔧 API Tools on agent nodes​

Tick the API Builder operations an agent node may call: from APIs in your spaces or shared to them. Calls go through the gateway to what prod serves, acting as the user who ran the workflow. → API Tools

Studio​

💬 Public Tutor: chat button, conversations, documentation answers​

Visitors to the landing, about and demo pages get a chat button in the bottom-right corner that opens HRIDA TUTOR, and the tutor now remembers the conversation, so follow-up questions work. With the HridaDoc Agent as its model it answers from the whole Hrida.ai documentation. It no longer needs Enable API Keys switched on, and models with knowledge, web search or tools work: before, they failed with 'NoneType' object is not callable (also for API callers of /api/chat/completions). Send a test message in Admin Panel › Settings › Public Tutor shows the tutor's answer, or exactly why there is none. → Public Tutor

🔄 Knowledge base sync API​

Studio now has the sync API that Knowledge Sync (OIKB) uses, so hrida-oikb sync works against it: each run sends only new and changed files, removes deleted ones and keeps the source's folders. Before, a sync stopped with 405 Method Not Allowed. Files added to a knowledge base by hand are never deleted by a sync. → Keep a knowledge base in sync · Syncing a Knowledge Base

Interface languages​

Studio's interface now ships in eight languages: English (US), Arabic, Bengali, Hausa, Hindi, Kannada, Odia and Swahili, with far more of the interface translated. Other languages were removed. Users who had one selected now get the instance's default language (English unless an admin set another). A browser set to plain hi, bn, kn or or now picks the matching language.

The Build section now always shows, in this order: Workspace → Agent Builder → API Builder → Automations → Agent Skills ("Skills" is now called Agent Skills). Agent Builder's catalog and space picker sits inside the Agent Builder entry.

Email Intelligence: spam stays out of the inbox​

Emails the AI scores as spam (at or above the admin's Spam Threshold, default 0.75) are hidden from the inbox and thread views. Nothing is deleted or moved in your mailbox. → Email Intelligence

Removed​

RemovedNotes
PagerDuty and Opsgenie incident providersGrafana OnCall is the supported incident provider. Existing PagerDuty/Opsgenie configurations are removed on upgrade. → Incident Management
CRM calendar integrationThe CRM connection in Admin → Settings → Integrations and "Link to CRM record" on calendar events are gone. The CRM single-sign-on link in the sidebar is unchanged.
Hrida.ai is proprietary software of Zlabs Innovation. See the license for terms. © 2026 Zlabs Innovation.