What we build
Hyperfluid is an internal cloud: 20 self-service services in a single console, installed in your datacentre, your cloud account or an air-gapped network.
The service-by-service catalogue, the installation documentation, the price list and the administration console are published on hyperfluid.cloud.
Writing that platform forced us down to the bottom of the stack. That is where what we know how to do on our clients' systems comes from.
The four deployment targets — managed tenant in Europe, your datacentre, your cloud account, air-gapped network — and the law that applies to each are set out column by column in the sovereignty brief.
Why we wrote it
We did not change trade. We industrialised what our engagements kept repeating.
We started out running other people's stacks. A query engine here, a Kubernetes cluster there, an object store, an identity directory, a monitoring stack rewired with every addition. From one engagement to the next, the same components came back and the same weeks played out again: integrate, secure, monitor, document, hand over.
What kept repeating, we industrialised. Not one more component: what holds them together. One console where the services live, one identity directory that applies to all of them, monitoring you do not rebuild with every addition, quotas and roles set once above the catalogue. That is what an internal cloud is. The documented installation procedure now takes a bare server to its first SELECT in < 1 h (1) .
Writing that forces you to understand every component down to the bottom. You do not package distributed storage, a SQL engine or a Kubernetes control plane while staying on the surface of its documentation: you have to read its code, know its failure modes, know what it does when a disk dies or a certificate expires. That is the price of building a product, and it is what makes a team able to run its clients' stacks. You cannot operate what you do not understand.
Engineering evidence
Two infrastructure clients written in Rust, released under open licences, running in production inside the platform we build.
8,316 lines of Rust · 14 files
A gRPC client for the Talos Linux API — the SideroLabs immutable OS the clusters we operate run on. mTLS by default, a typed surface generated from the official proto files.
An immutable OS has no shell and no SSH: everything goes through its API. Driving a fleet from our own code meant writing that client ourselves.
6,374 lines of Rust · 45 files
A Trino client for Rust. Presto support was removed and the engine's recent features added — including the spooling protocol, which returns large result sets through object storage instead of the HTTP channel.
Querying a distributed SQL engine from a Rust service, with no JVM in the path and no ceiling on large result sets.
Close to fifteen thousand lines of published Rust, alongside our contribution to Ferris Key, an authentication server in Rust under Apache-2.0. Writing the client for a component means knowing its protocol, its errors and its limits better than its documentation describes them.
For a services client
Same engineers, same repositories, same components.
Our engineers work as embedded teams, on architecture audits or on open source support, over stacks we already run for our own account: Kubernetes and Talos Linux, PostgreSQL, Trino, Ceph, Kafka, Keycloak, the GPU inference chain. When an incident leaves the manual, escalation goes to the people who wrote the code, not to a general-purpose hotline. ▪
No client has to deploy Hyperfluid to work with us: the platform is what proves the level, it is not a condition of the engagement.
