s0
BUSL-1.1 · Apache-2.0 au 18 août 2030
An S3-compatible authorization gateway: every request is deserialized, checked against an OPA/ABAC policy, then re-issued to storage under a per-tenant identity.
What we build
We build Hyperfluid.
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
Giving control back to European companies.
A European company should be able to run its data without handing it to an operator subject to a foreign law.
The large clouds are efficient, and they remain subject to the law of their home country. A foreign order can reach data hosted in Europe, without the company that produced it being told. This is not a hypothesis: it is the legal regime these services are sold under.
Sovereignty is not delegated by contract, it is held by architecture. Hyperfluid installs inside your perimeter — your hardware, or the host you chose. The data, the logs and the keys stay there, and the infrastructure contract stays in your name.
That is what makes control verifiable rather than declared. You do not ask us to promise that your data does not leave: you read it in the topology and in the contract.
Engineering evidence
When a component was missing, we wrote it.
Three components written in Rust, with their code published, running in production inside the platform we build.
talos-rust-client
MIT OR Apache-2.0
A gRPC client for the Talos Linux API — the immutable OS the clusters we operate run on. An immutable OS has no shell and no SSH: everything goes through its API.
trino-rust-client
Apache-2.0
A Trino client for Rust, with the spooling protocol: querying a distributed SQL engine with no JVM in the path and no ceiling on large result sets.
We also contribute 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
The team that works on your systems is the team that builds the platform.
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.