What we ship, week after week.

Deploy from Git, security rules per organization

You deploy a CaaSThor app from your Git repository: change the image in a file in the repository, and the app picks it up on its own or waits for your go-ahead. On a dedicated install, you set security rules for each organization from the cockpit.

• A CaaSThor app takes its image from a Git repository. A hyperfluid.toml file in the repository names the image to deploy, on GitHub, GitLab or Forgejo.
• You follow a branch or the latest release. When following tags, the app takes the highest one that matches the regular expression you give.
• You choose between automatic updates and approval. In manual mode, the console shows that a new image is available and waits for you to sync.
• Every sync leaves a record. The history lists the images applied or offered and the failures, with their commit, and an alert fires when the repository can no longer be read.
• Your environment's Forgejo links in one click. The console creates the repository access for you, with no token to copy.
• hfctl and Terraform drive the same source. hfctl apps sync starts a sync, and hfctl validate checks a hyperfluid.toml before you push it.
• Security rules are set organization by organization. From the cockpit, you set a value for the whole platform and override it for one organization, with a note on why.
• The first rule decides who may follow Git automatically. Turned off, it moves every app of an organization to manual approval, without touching their configuration.

CaaSThor internal addresses, encrypted secrets backup

You know how to call a CaaSThor app from inside your environment without looking up its service name. On a dedicated install, you back up the secret store and the platform's secrets, encrypted, to your own storage.

• A CaaSThor app's page gives its internal address. The ca-<name> host and the URL on its primary HTTP port sit next to the public URL.
• Every address copies in one click. So do the requested and running image references, now shown in full.
• The secret store is backed up on a schedule. Every 6 hours by default, an OpenBao snapshot goes to the S3 storage of your choice.
• Backups are encrypted before they leave the cluster. They are encrypted with age for the recipients you name, then read back to check their size and checksum.
• The platform's secrets travel with the snapshot. The internal certificate authority and the admin credentials go into the same backup, and an alert fires when none has succeeded for 12 hours.

CaaSThor app health, a time range for the audit log

You see at a glance which CaaSThor apps are healthy and which need your attention. In the audit log, you pick the time range on screen and share it with a plain link.

• The CaaSThor apps list becomes a health view. Tiles sum up healthy apps, ready instances, restarts, and CPU and memory use over the last day.
• A filter keeps only the apps that need attention. Those that are failing, nearing 80% of a limit, or that restarted in the last 24 hours.
• Each row says what is wrong. Missing instances, memory, CPU and restarts sit next to the app's CPU and memory curves for the day.
• A row expands into its instances. You read the state and usage of each one, and a menu restarts or stops the app without leaving the list.
• You pick the audit log's time range. The last 24 hours, 7 days, 30 days or exact dates, in the console and in the control center alike.
• The time range is part of the link. A filtered audit log view goes to a colleague as is, and opens on the same events.
• Your organization's security view focuses on your code. Databases, Kafka, Airflow or models that the platform runs and updates for you are no longer listed.
• The control center decides per organization. A switch makes managed services visible again to an organization that wants to follow them.

Rescan every image in one click, security scoped to your own

After a platform update, you rescan every running image from the control center in a single action. Your organization's security view lists the images you deploy and can change, and only those.

• The control center rescans every image in one click. Once you confirm, each image running on the cluster is queued, and a message tells you how many were.
• The platform-wide rescan includes the platform's own images. Those are the first an upgrade replaces, and no single organization can rescan them.
• Your organization's security view shows what you can change. Components the platform installs and updates for you, such as a Data Dock's SQL Engine, are left out.
• In a managed PostgreSQL database, you see the database. The PostgreSQL container and its pooler stay listed, the bootstrap and backup containers the platform adds are hidden.
• The numbers match what you see. Summary tiles, per-environment (harbor) totals and restarts are computed from the list on screen.
• The control center keeps the full picture. Platform components stay visible there, marked with an Internal badge.

Business metrics for your apps, built-in dashboards

Your application exposes its own Prometheus metrics and you see them in the console, next to CPU and memory, without running a Grafana. You build a dashboard from those metrics in one click.

• Your CaaSThor applications expose their own metrics. You give the port and, if needed, the path (/metrics by default), and the platform collects them.
• The Metrics tab shows system and business side by side. CPU and memory charts stay on top, your own indicators appear right below them.
• One click creates a dashboard. The console builds it from the metrics your application already exposes, and you adjust it from there.
• A widget charts a SQL query or an application metric. The editor lists the available metrics and shows a preview before you save.
• Each application only sees its own metrics. A query is always scoped to the application that issues it, even if the application publishes misleading labels.
• hfctl apps metrics queries those metrics from the terminal. You list an application's metrics with --names or run a PromQL query with --query.

Nextflow environments, workload supervision, Excel import

You run your Nextflow and nf-core pipelines in an isolated environment, from the console or the terminal. You see everything running in your organization at a glance, with the CVEs of each image, and you import an Excel workbook straight into a table.

• A Nextflow environment runs your nf-core pipelines. You create it inside an environment (harbor), with its shared work volume, its attached buckets and its own quota.
• You launch, resume and cancel a run. The console follows each run with live logs, its task list and their exit codes, and a resume picks up from the previous run's cache.
• hfctl nextflow does the same from the terminal. You create an environment, launch a pipeline with --follow and read a task's logs without opening the console.
• Vauban lists everything running in your organization. Each workload shows the image it runs, whether it is exposed to the internet, and the network rules that cover it.
• The CVEs shown are those of the image actually running. Each image is scanned weekly by default, you set that pace per organization, and you trigger a rescan on demand.
• Each environment has its security tabs. Workloads, restarts and network: a container restart links to the logs of the moment it happened.
• You import an Excel or OpenDocument workbook into an Iceberg table. A preview shows the columns and their types before anything is written, and you pick the sheet and the header row.
• A SharePoint connector can be edited after it is created. You change the source, the credentials or the schedule, and every run in the history opens its logs.

PostgreSQL dump import, Atlas documentation, S3 gateway

You load a dump or a SQL script into a managed PostgreSQL database, from the console or the terminal. Your organization gets its own documentation inside the console, and its own S3 gateway.

• You import a dump into a managed PostgreSQL database. An Imports tab takes a pg_dump archive, a .sql script, compressed or not, or SQL pasted directly.
• An import applies in full or not at all. It runs in a single transaction, as the editor role you pick, and every imported object belongs to that role.
• The same operation runs from the terminal. hfctl db import uploads the file, starts the import and follows it to the end.
• Atlas gathers your organization's documentation. Guides in French and English, full-text search, favorites, notes, and procedures that owners publish for their teams.
• Help opens next to the screen you are working on. From storage, Petite Requête, Sapience or applications, the matching guide opens without leaving the page.
• Each organization has its own S3 gateway. It answers on a dedicated address, and the access keys the console issues belong to it.
• Resources the platform created are marked. A bucket, a database or an application shows its source, and what the platform created for you cannot be deleted by mistake.
• An agent starts in the repository you choose. On a workstation, you pick a session's repository, branch or worktree, and its open pull requests show above the conversation.

Governed scheduled queries, Ask AI, Airflow to the SQL Engine

You choose the service account each scheduled query runs as, and you know which identity read the data on every run. Petite Requête writes your SQL from a question, and your Airflow DAGs query the SQL Engine without handling a secret.

• A scheduled query runs as the service account you give it. You grant that one report the access it needs, and you take it back the same way.
• Every run records the identity that read the data. The history keeps the account that held the token that day, even after you assign a different one.
• You set a managed database's recovery point objective. At creation you pick the interval that bounds how much data a restore can lose, 5 minutes recommended, 60 seconds at the shortest.
• An Airflow environment connects to the SQL Engine. You declare the connection to a catalog, your DAGs use it by name, and every query stays subject to your organization's permissions.
• Petite Requête writes the SQL from a question. You describe what you are looking for, the query lands in the editor as a draft, and running it stays your decision alone.
• You choose the model behind it. The SQL assistant binds to the Sapience model you pick, with per organization authentication and usage accounting.

Point-in-time restore, service account RLS labels, hfctl airflow

You bring a managed PostgreSQL database back to the minute you choose, from the console or the terminal. You filter the rows a service account reads the same way you do for a user, and you run your Airflow environments with hfctl.

• A managed database restores to a point in time. From the backups tab, you pick a date and a time down to the minute, and the database is rebuilt as it was at that moment.
• The console shows the period you can restore. Each database states how far back and how far forward its backups reach, and the time you pick is bounded to that period.
• The same restore runs from hfctl. hfctl db restore --at takes a timestamp or an offset such as -2h, to go back two hours without working out the time.
• An alert fires when a scheduled backup did not happen. A database whose daily backup has not completed in 26 hours notifies your channels, even when everything else reads healthy.
• A service account holds RLS labels. You give it the labels that filter the rows it can read, from its page in the console, as you would for a user.
• hfctl airflow runs your Airflow environments. You create them, put them to sleep, restart them, read their logs and manage their connections without opening the console.
• A custom role can be renamed. You change its name and its description, and the members holding it and its permissions stay in place.
• You change a member's roles from the users list. A dialog lists the organization's roles with their descriptions, and you tick the ones the member should hold.

Airflow connections, SIEM export, isolated Iceberg maintenance

You declare an Airflow environment's connections without typing a secret, you send your audit events and platform logs to your SIEM, and your Iceberg table maintenance runs under its own identity, in a resource group that never gets in the way of your queries.

• Airflow gets managed connections. You declare a connection to a managed PostgreSQL database or a bucket, and your DAGs use it by name, with no secret in their environment.
• A managed database alerts you when its backups stop moving. As soon as transaction log archiving falls behind, a critical alert reaches your channels with the number of segments waiting.
• Iceberg maintenance has its own identity. Compaction and snapshot expiry run under a dedicated account, limited to those operations, and every write is attributed to it in the audit log.
• And its own resource group. The SQL Engine caps maintenance at 8 concurrent queries and 15 % of its memory, so your queries keep priority.
• Your logs go to your SIEM. Audit events and platform logs are forwarded to VMware Aria Operations for Logs, or to any other SIEM over RFC 5424 syslog on TLS.
• One domain for every workstation preview. An installation serves the previews of every organization under a dedicated domain, with a single DNS record and a single certificate for the whole cluster.
• Kafka ships with the platform. The Strimzi operator installs from the Hyperfluid chart, with the broker and Kafka Connect images built on every release.

The image actually running, custom CPU and memory in hfctl

You see which image actually runs behind each container app, including on a floating tag or during an update. From the terminal, you list the available tiers and set an app's CPU and memory yourself.

• A container app shows the image actually running. Its overview lists each running image by digest, with its pod count, and marks a floating tag such as latest.
• hfctl lists app tiers. hfctl apps tiers shows each tier the platform offers, with its CPU and memory.
• You set an app's CPU and memory from the terminal. --cpu and --memory replace picking a tier, on create as on update, within the platform's bounds.
• hfctl shows what runs, and at what size. hfctl apps get prints the app's tier or custom size, and each running image with its pod count.

Ceph storage monitoring comes to the control center

You follow the health, capacity and activity of your Ceph storage from the control center, without opening a separate monitoring tool.

• A page shows the state of your Ceph cluster. Health, active alerts and monitor quorum are displayed and refresh every 30 seconds.
• You see the capacity and what uses it. Raw capacity, the usage of each pool and the state of placement groups are shown side by side.
• Every disk has its own row. The state, fill level and write latency of each OSD let you spot the one slowing down.
• Throughput and IOPS are charted over time. Reads and writes are plotted over a window you choose, from 15 minutes to 24 hours.
• A missing reading never passes for healthy storage. When a sample is missing or a query fails, the page says so instead of showing idle or healthy storage.

The SBOM of the installed version, CPU-focused CI runners

You hand your security officer the software bill of materials (SBOM) of the installed version, downloaded from the control center with its reports. Your CI runners get CPU-focused sizes, and the form shows you what a pool reserves.

• The control center shows the SBOM of the installed version. It is produced by the build that made the image, at the release commit, so it describes exactly what runs on your cluster.
• You download the SBOM and its reports. A CycloneDX 1.5 document per deliverable, an aggregate of the whole and a summary for your security officer are ready to archive.
• The licenses to decide on come first. Strong copyleft and undetermined licenses are brought forward, because they are the two cases your IT department has to settle.
• Known vulnerabilities are listed by component. Each carries its CVSS score and the version that fixes it, and the page sets apart those scoring above 7 on a component actually delivered.
• The infrastructure gets its own inventory. The Kubernetes base layer, storage, query engines and message bus are listed with their deployed version.
• Your CI runners get four CPU-focused sizes. From C2 to C8, they provide one GiB of memory per vCPU, for builds that need compute rather than memory.
• The form shows what a pool reserves. It computes one runner's CPU and memory, Docker included, then the total of a GitHub pool at its maximum number of runners.

CI runners filter their egress, the network flow matrix

You apply the same network egress lists to your CI runners as to your workstations, you pick their size, and your jobs build Docker images inside their micro-VM. The control center produces the network flow matrix to hand to your network team, read from the cluster.

• Your CI runners follow the harbor's egress lists. A Forgejo runner attaches the same allow-lists as your workstations, and is edited in place, without recreating it.
• One Runners page. GitHub pools and Forgejo runners are managed in the same place, as two kinds of the same thing.
• Seventeen ready-made egress lists. Debian, Node.js, Rust, Python, Docker Hub, GitHub, Kubernetes and ten more: you switch them on in one click inside an allow-list.
• You pick the size of your runners. Four sizes from S to XL, each with its own Docker disk, or a custom size you set within the platform's bounds: CPU, memory and disk.
• Every runner carries its own Docker daemon. It runs in the runner's micro-VM on a dedicated block volume, and only the job it serves can reach it.
• The control center generates your network flow matrix. A page lists every network flow to open, its criticality and its encryption, and exports it as XLSX in French or English, ready for the network team.
• The matrix is read from the cluster. Addresses and image registries are read from the cluster, resolvers and time servers from the machines, and every value says whether it was read or declared.
• You declare the capabilities of an external model. A shared model hosted outside the cluster carries its context window and its tool support, and a flavor can serve it under a stable name.

Several Airflow per harbor, Trino queues, SQL in the audit log

You create several Airflow environments in one harbor, each with its own execution space and network egress. Your interactive queries no longer wait behind a bulk job, and Vauban shows the exact SQL each query ran.

• Several Airflow environments per harbor. Each has its own address, an isolated execution space for its tasks, its own egress allowlist and its own airflow.cfg settings, created from the console.
• Interactive queries go ahead of bulk jobs. The SQL Engine separates the queues, so a lookup that takes a few milliseconds no longer waits behind a fleet of pipelines.
• Vauban shows the SQL of every query. The exact text, the outcome, the columns read and the execution statistics join the audit log of each Trino query.
• Service accounts have a name in the audit log. A service account appears under its name rather than its identifier, and is filtered like a user.
• A service account role can be scoped to one harbor. You bind a role to the whole organization or to a single harbor, and a harbor binding carries only that harbor's permissions.
• The forge stores its files in the organization's bucket. Git LFS objects, attachments, packages and artifacts live in your object storage, and survive an uninstall.
• Triton embedding models answer in OpenAI. Sapience recognises a shared model's protocol and translates a /v1/embeddings call into a KServe v2 model, with the tokenizer declared on the model.
• An audit mode for workstations, one organization at a time. Off by default, it records what is asked of the agent and what is typed in the terminal, and the user is told.

Bigger containers, their volumes, audit by query

You size a container down to the millicore, you see how full its volumes are, and you read your data activity one query at a time.

• Containers go up to 8 vCPU. Two sizes extend the existing range, 2xlarge (4 vCPU, 4 GiB) and 4xlarge (8 vCPU, 8 GiB).
• Or you enter the exact size. You type the CPU and memory you want, priced and computed like any standard size.
• Volume usage is visible in the console. Each volume shows its mount path, size, storage class and how full it is, with a warning past 80%.
• The tab separates volumes from mounted files. You see at a glance what survives a restart and what is simply placed inside the container.
• Audit reads one query at a time. Access events are grouped by SQL query, and Trino planner noise is filtered out.
• You follow activity live. A real time view shows access events before they are aggregated, with their detail.
• Petite Requête keeps the schema cached. Catalogs are explored in parallel, and if one does not answer, the others still appear.

The SharePoint connector, the data plane, the public pages

You ingest a SharePoint library like any other source, you see the state of the data plane without opening a terminal, and you edit the copy of your public pages yourself.

• SharePoint becomes a source. A document library is ingested into a bucket through Microsoft Graph, on the same model as Google Drive.
• A page shows the state of the data plane. The LLM gateway and Bifrost report their availability, their restarts and their traffic, model by model.
• Seven alert rules watch those two components. An outage of the gateway or of Bifrost announces itself.
• Bifrost metrics are collected. The throughput and latency of the PostgreSQL proxy are visible, and a degraded embedding backend is named.
• A stopped container starts again. It comes back at the replica count it had, with prominent start and stop buttons.
• Memory appears next to CPU. A container's resources panel gives both.
• You choose the models behind the AI features. The SQL assistant, dashboards, ontology generation and table classification are all set from the control center.
• Public pages change without a deployment. The signup, landing and invitation copy is edited from the control center, live.

Runtime security, stronger isolation, Trino public or private

You see what your containers really do, and isolation between organizations no longer rests on our code alone.

• A security agent runs on every node. It watches what containers actually do, and every alert names the organization it concerns.
• All the alerts are in one place. A page in the control center gathers the security alerts of the whole fleet.
• Isolation moves into Kubernetes. A request that tried to bypass the platform is refused by the Kubernetes API itself, no longer by our code alone.
• You choose whether Trino is exposed. A Data Dock's Trino is public or private, and you switch it in one click from the console.
• The network is closed by default. Access to Trino, to pipelines and to managed PostgreSQL databases is protected without you writing a rule.
• You choose your vulnerability databases. The ones image scanning uses, including on an installation with no internet access.
• Third-party images are configurable. You point them at your own registry from the installation chart.

Runner egress ports, bucket objects in bulk

Your builds finally reach repositories that do not listen on 443, and you tidy a bucket without opening it file by file.

• You open a precise port. A runner can reach an apt repository on port 80 or an internal registry on port 5000. Before, only 443 went through.
• Or you allow everything. A runner pool can run with no restriction at all, for builds that download from more domains than a list can hold.
• A bucket behaves like a table. Column sorting, search, multi select, bulk delete and pagination.

Service links in Terraform, the control center rebuilt

You describe in Terraform which services may reach each other, in the same place as the rest of your infrastructure.

• You declare call permissions in Terraform. The hyperfluid_service_link resource states which services may call each other, in the same files as the rest of your infrastructure.
• An application exposes several ports. As many as it needs, and Terraform can refer to it by its slug.
• The control center looks like the console. A collapsible navigation rail, breadcrumbs, and a palette that opens any page in two keystrokes.

The audit log becomes readable in the console

You know who asked for what, on which resource, and what was decided, without writing a single query.

• Every access decision is readable. The Vauban page shows who asked, on which resource, what was decided, and the rule that decided it.
• SQL queries come with detail. You see the schemas, tables and columns each one touched, with the row filters and masks applied.
• You filter the list, then you open a row. By action, by resource, by decision or by event type, and each row shows the full request.

Self-service Slurm, third-party AI models, GitLab

You stand up a compute cluster with no ticket, you call third-party models with your usual key, and you code on a GitLab repository.

• You create a Slurm cluster yourself. With its partitions, its node sizes and an ssh login node. No ticket to open.
• Job accounting is optional. You get the history with sacct and you set QOS limits per partition.
• Third-party models join the catalogue. Each with its context window and its price, called through the same endpoint and the same key as your local models.
• Credits to pay for them. A balance, a statement of what was granted and spent, and a warning before a call is refused.
• You work on a GitLab repository. From a workstation, then you open the merge request and follow it from the console.
• One API key can no longer starve the others. You set its rate ceiling yourself, within the limit the platform allows.
• hfctl handles compute docks. You create one, list it, resize it and connect to it from the terminal.

Twelve SQL connectors, agent skills, admission control

You query databases the platform does not host, and your agents change skills without restarting.

• Twelve more databases in the SQL catalogue. MySQL, MariaDB, ClickHouse and the JDBC family: a catalog can point at a database we do not host.
• Agent skills are edited in the console. A change reaches workstations that are already running, with no restart.
• The console does what the terminal did. It shows which skills answered, a table picker grouped by schema, and thinking time under each answer.
• hfctl talks to agents. You manage them, edit their skills and chat with them from the terminal.
• hfctl drives pipelines. You create one, trigger it and follow its run to the end.
• The AI gateway can say no. An admission policy decides which calls it accepts, and refuses the rest explicitly.

Service links on the command line, traced maintenance

You declare from the terminal which service may reach which, and you know what each maintenance run did to your tables.

• hfctl declares links between services. You state which service may call which, without going through the console.
• Every Iceberg maintenance run leaves a trace. It has its own identity, its result metrics and its logs, so you know what ran and what it did.
• Model keys live in the vault. The pipeline names the key instead of carrying it in the clear.

Catalogs onto your existing databases, workstation ports

You query your databases where they are, without moving them, and your workstation publishes its ports on its own.

• A catalog can point elsewhere. At a database the platform does not host, with a credentials form specific to each connector.
• A workstation's ports open in one click. Any port your code serves shows up on its own in the console.
• An agent skill stays inside its perimeter. It names the tables it may read, and its search goes no further.
• A map shows who talks to whom. The declared links between services are readable service by service.

Scheduled queries, built-in support, governed GPU

You schedule a query and let it run, you open a ticket without leaving the console, and the GPU is driven like a resource.

• A query can run without you. You write it, you schedule it, it runs in the background with its own authorization.
• Support is in the console. You open a ticket from the interface, it lands straight with the platform team.
• The GPU becomes a governed resource. Entitlement, budget and pool, granted organization by organization.
• An undersized application flags itself. Seven-day p95 CPU shows the one that reserves more than it uses.

TLS on the PostgreSQL wire protocol, object level permissions

Your data API connections are encrypted all the way to the client, your authorizations reach down to the object, and you size an application with a single number.

• Data API connections are encrypted all the way to the client.
• Bucket authorizations reach down to the object.
• One vCPU number per tier, from which the reservation and the ceiling are derived.

Private secrets, workstation networking, platform changelogs

You keep your secrets in an area that is yours alone, you control your workstations' networking, and you clone several repositories into one.

• A reserved secret path per user, visible to its owner alone.
• A network tab on workstations, with custom allow lists.
• Several repositories cloned into one workstation.
• Platform news shows up directly inside the console.

One Kubernetes namespace per environment

• Every environment gets its own Kubernetes namespace, enabled organization by organization.
• An environment's resources are isolated from the others, down to the network.

Capacity alerting, agent conversations, FHIR demo

You let an agent answer several conversations at once, and you are warned before capacity runs out.

• Capacity alerts, with a notification plane in the console.
• Agents answer mail concurrently, serialized per conversation.
• A complete FHIR demo in a single command.

Public trial signup, managed agent mailboxes

You start a trial without asking us, and your agents get mailboxes of their own.

• Public trial signup, with an approval queue in the backoffice.
• Platform hosted mailboxes for your agents.

Token consumption per model and per principal

• Token consumption charts per model, over the period you pick.
• The same view per principal: users and service accounts, side by side.
• Enough to know exactly who consumes what, model by model.

Platform administration backoffice

You administer the platform from a backoffice separate from your organizations' console.

• A dedicated backoffice for platform administration, separate from the organization console.
• Organization creation, account management, cross tenant oversight.
• Built on the same design system as the console.

Bulk grants, group roles and permissions

• Bulk editing of grants given directly to a user.
• Role and permission management at group level, not just per person.
• Iceberg schema deletion from the interface.

Token metering per principal, users and service accounts alike

• Token consumption is attributed to each principal: user or service account.
• An automation's OCR model is configured at creation time: key, name and URL.

A denial names the permission that was missing

• An access denial names the permission that was missing, in the console and in hfctl.
• No more guessing which right to ask your administrator for.

Import and export of container app environment variables

• Export of a container app's environment variables.
• On import, hfctl's secret: syntax is recognised: a variable can point at the vault.
• hfctl reports that an update is available after a command.

Realtime AI consumption, dense series and quick ranges

• Denser consumption series, quick ranges and refresh control.
• Realtime tracking becomes readable over short windows.

Cluster GPU inventory, consumption dashboard

You see the GPU fleet available, its real usage, and the history of what you consumed.

• A Resources tab on the AI gateway: GPU inventory and usage.
• Realtime and history modes on the consumption dashboard.

AI gateway: token metering and external models

You measure your inference consumption precisely, and you expose models served outside the platform.

• All inference goes through the gateway, for a reliable measure of usage.
• Models served outside the platform, exposed and discovered automatically.
• The console moves to Tailwind CSS v4.

Breadcrumbs on every detail page, faster local OCR

• A breadcrumb on every detail page: home, section, resource, tab.
• Local OCR sped up by reading the PDF text layer directly, when there is one.

Managed Airflow, OCI containers in workstations

You provision Airflow from the console, and you run containers directly inside your workstation.

• Managed Airflow, provisioned and supervised from the console.
• OCI containers usable directly inside a workstation.
• A PDF capable OCR playground.

A console rebuilt as a service catalogue

You find your services in a catalogue, with your favourites pinned. The features do not change, the way you reach them changes entirely.

• Service catalogue navigation, with pinnable favourites.
• The SQL Engine adopts the same interface grammar as containers and databases.
• Agents ask a clarifying question when the request is ambiguous.
• Precomputed embedding contract: the pipeline embeds, Bifrost copies.

Agents reachable by email, governed queries from the CLI

You write to an agent like a colleague, it replies in the thread. And you query your data from the terminal, under your policies.

• An agent reads a mailbox and replies in the conversation thread, over IMAP and SMTP.
• A setup wizard walks through connecting the mailbox, provider by provider.
• hfctl query and hfctl search: query the data plane from the terminal, under policy control.

Per organization identity providers, dedicated OCR playground

• Each organization can plug in its own identity provider, with invitation based sign in.
• A dedicated OCR playground for vision language models.
• Log explorer: volume histogram, live follow and export.

Per organization log retention, advanced filters

• Log retention is set organization by organization.
• Advanced filters in the log explorer.

Embedded logs, and the agent runtime wired end to end

• A log engine embedded in the platform, with its own search page in the console.
• The agent runtime is wired end to end: from the creation wizard through to chat.
• Backup management on an existing database, from the console and from hfctl.

User defined AI agents, end to end

You define your own AI agents, from declaration through to conversation.

• User defined AI agents, from declaration through to conversation.
• Creation of a managed PostgreSQL database from a backup.
• Dashboards: variables, cross filtering, auto refresh and text widgets.
• Kafka access by service account, over OAuth.

AI first dashboards, Kafka topic management

You build your dashboards with AI, and you manage your Kafka topics from the interface.

• AI first dashboards, built inside the console.
• Kafka topic management from the interface.
• The SQL Engine gets its own section: column browsing, cluster statistics and an access tab.

Shared model playground, multi profile wallet for hfctl

• Playground and code samples for shared models, with the gateway URL.
• hfctl handles several authentication profiles in one wallet.
• A default backup target on every environment.

Guardrails and groups in Vauban, dark theme in the console

You set guardrails per resource and per group, and nothing is exposed to the internet unless you decided it.

• Vauban: per resource access levels, guardrails and group management.
• Light and dark theme, your pick, from the user menu.
• Databases and applications are private by default, exposure becomes an explicit choice.
• hfctl gains a command group for key value caches.

PostgreSQL quotas, per organization storage zones

• Capacity quotas on managed PostgreSQL databases.
• Ceph storage zones enabled per organization.
• The console spots environment variables that look like secrets and offers to move them into the vault.

Inbound email interface in the console

• The inbound email interface lands in the console.
• Workstation ergonomics reworked.

Inbound email, capacity quotas, browsable secrets

• An inbound email transport, on the platform side.
• Bulk import of environment variables, and a browsable picker over the secret tree.
• Capacity quotas on container apps.

Terraform provider served by the console, twenty more connectors

• The console serves the Hyperfluid Terraform provider as a registry.
• Twenty more open data connectors, including data.gov.uk and SCB Sweden.
• Configurable Keycloak login theme per organization.

Filterable open data catalogue

• Filterable open data catalogue, with each connector's metadata.
• Managed image source in the new application wizard.

Twenty open data connectors, French and European

You cross your data with twenty French and European public sources, without writing an ingestion script.

• Twenty open data connectors: DREES, Ameli, Crossref, Zenodo, TfL, ONS and more.
• French connectors: data.gouv.fr, Enedis, DVF, GRDF, SNCF, RATP.
• hfctl configures itself from the service account file.
• Slimmer workstation images, and a Rust base.

Trino control plane, Dagster orchestration, Forgejo CI

• A Trino control plane: monitoring, scaling and catalog management.
• Dagster orchestration, from CRD through to the interface.
• Forgejo CI jobs push to the internal registry.
• One click Trino enablement, in a dedicated SQL Engine section.

Distributed Bifrost, embedded monitoring, a wider hfctl

You scale up: Bifrost becomes distributed and autoscaled, and you monitor the platform from the console.

• Bifrost becomes a service of its own, with autoscaling.
• An embedded monitoring system, in production.
• Managed PostgreSQL exposed through Trino catalogs.

Workstation environment templates, Source Control

• Environment templates for workstations: CRD, catalogue and authoring interface.
• Source Control joins the catalogue, backed by Forgejo.
• hfctl gains the storage and buckets commands.

AI assisted editing in workstations, first open data connectors

• AI assisted editing in workstations, Cmd-K style.
• A shared Qwen3 model, with no organization or key coupling.
• First open data connector: the World Bank, into an Iceberg table.
• Vauban moves from RBAC to ABAC for console access.

hfctl available for macOS

• hfctl is distributed for macOS as well as Linux.
• OS detection in the install script.

Workstations: editable IDE, zero config LSP, source control

• The workstation IDE becomes editable, with multi file tabs.
• Completion, hover and code navigation, with no configuration.
• A source control tab, with a live branch indicator.

hfctl, the Hyperfluid command line

You drive the platform from the keyboard, from model serving through to a database's logs.

• hfctl, the Hyperfluid command line, in full.
• Sapience commands: model serving, inference, shared models and API keys.
• Member invitations from the console.
• Streaming database logs, in the console and from the CLI.

Configurable runtime for container apps

• The runtime class for container apps is configured on the platform side.

Container app persistence, connector scheduling

• Built in persistent volume for a container app.
• Configurable cron schedule on connector pipelines.
• Image pull testing and a complete edit surface on an application.

Shared per organization Ceph object storage

• Shared per organization Ceph object storage, partitioned by environment.

Custom domains end to end, files mounted into containers

You serve your applications under your own domain names, from verification through to go live.

• Your own domain names on applications, from verification through to go live.
• Files mounted into a container: inline config, or a secret served as a file.
• Responsive Data APIs page, and a reworked sidebar.

Custom domains: operator reconciliation

• The operator reconciles custom domains.

Non PDF routing in the file sorter

• Files that are not PDFs are routed explicitly by the file sorter.

Custom domains: the foundations

• The foundations of custom domains: API, database and ownership verification.

Default medallion schema on Iceberg

• A default medallion schema on Iceberg catalogs.
• Cascading deletion of a lakehouse's resources.

Connectors: statistics and bucket navigation

• A statistics tab on every connector.
• Google Drive connector detail page, with bucket navigation.
• Ceph credentials are published into the secret store.

On demand PostgreSQL backups, Google Drive connector

• On demand PostgreSQL backups, alongside scheduled ones.
• Google Drive connector, end to end.
• A database user's secrets are reachable from its tab.

Backup targets, default environment per organization

• Backup targets declared as resources.
• A default environment for every organization.
• Badges on Trino tables.

Managed PostgreSQL reachable from outside

• A managed PostgreSQL database can be reached from outside the cluster.
• The endpoint is published into the user's secrets.

Managed PostgreSQL users, path based secret organization

• Managed PostgreSQL users, declared and reconciled as resources.
• Secrets are organised by path.
• RNIC open data connector.

OCR: automatic resume and processing context tracking

• OCR resumes where it left off, without redoing work already done.
• Configurable backoff on model calls.

Managed PostgreSQL: the CRD and its operator

• Managed PostgreSQL: the CRD and its operator.
• Configurable Ceph zones on a Data Dock.
• A reusable log viewer in the console.

Hybrid search: separate queries, merged results

• Hybrid search runs its two queries separately before merging the results.

Continuous Bifrost indexing

• Bifrost indexing runs continuously.

Tunable result fusion for hybrid search

• A fusion parameter on hybrid search, for a predictable merge of results.

Redesigned data product explorer

• The data product explorer is redesigned from the ground up.

Password reset from the cockpit

• Password reset from the cockpit.

Cockpit v3: admin panel and automatic onboarding

You administer the platform from a real panel, and a new organization starts with no manual step.

• Cockpit v3: a stateful admin panel, for the platform.
• Automatic onboarding of a new organization.

BGE embeddings, and the Hippocampe memory layer

You get a three level memory layer, and vector search moves to BGE embeddings.

• BGE embeddings for vector search.
• Hippocampe: a three level memory layer.

Extra fields on the import API

• Extra fields carried through the import API.

Ceph lifecycle and status

• Ceph storage lifecycle and status, visible in the console.
• The import API's extra fields are reused by pipelines.

Omnifeed, and page level document splitting

• Omnifeed: a single entry point to feed pipelines.
• Document splitting by page number, as reported by OCR.

Sign in screens in your organization colours

• Sign in screens take your organization's colours.
• Cilium network policies on container apps.

Self service and quotas

• Self service onboarding, with per organization quotas.

Kata containers: hardware isolation for applications

• Applications can run in Kata containers, isolated at hardware level.

Registry secrets and network policies for containers

• Registry secrets and network policies on container apps.

Lakehouse v2 blueprint on Ceph

• A Lakehouse v2 blueprint, backed by Ceph storage.

Iceberg table optimization

• Iceberg table optimization, triggered from the platform.
• Faster change detection on application pods.

CaaSThor: container apps, ingress and logs

You deploy a container app from the console, with its ingress, its pods and its logs on the same page.

• CaaSThor: deploy a container app from the console.
• Ingress, pod list and logs, on the same page.
• Bucket picker on Iceberg catalogs.

Kafka, and a rebuilt Bifrost index and cache layer

• Kafka joins the service catalogue.
• Bifrost indexes and caches rebuilt.

Secret store

• A secret store built into the platform.

Bifrost index pre computing

• Bifrost indexes are pre computed rather than built on demand.

Observatory metrics service

• Observatory: a metrics service for the platform.

Internal labeler in production

• The internal labeler goes to production, replacing the external API.

Global models, log expiry, Petite Requete monitoring

• Global models, available across the platform.
• Petite Requete monitoring.
• Automatic expiry of pipeline logs.

Local GPU OCR with Qwen2.5-VL

Your documents no longer leave the platform to be read: OCR runs locally on GPU.

• OCR runs locally on GPU, with Qwen2.5-VL, with no external API call.

Batch creation of chunk references

• Batch creation of chunk references.

Petite Requete, and the Ceph Data Dock

You query your data from Petite Requete, and your object storage moves onto Ceph.

• Petite Requete: the SQL runner takes its name and its documentation.
• A Data Dock backed by Ceph.
• Reworked object storage interface.

A SQL runner in the console

• A SQL runner in the console, to query without leaving the platform.

S3 copy in pipelines

• S3 copy in pipelines.

Table duplication within an Iceberg catalog

• Table duplication within one Iceberg catalog.

The hyperfluid-users role

• A hyperfluid-users role, the base of platform access.

Pipelines and navigation redesigned

• Pipelines and console navigation are redesigned.
• Lazy loading of heavy pages.
• Dynamic values in labelling.

Import API connection and suffix control

• An import API connection type in pipelines.
• File suffix control on import.

File sorting in pipelines

• A file sorting step in pipelines.

ZIP imports and exports, Vauban 0.2

• ZIP format imports and exports.
• Vauban 0.2, and the first public landing page.

PostgreSQL Data Dock, and row level security

You plug a PostgreSQL database in as a source, and your policies filter down to the row.

• A PostgreSQL Data Dock.
• Row level security in policies.
• User and role synchronization from an external API.