Onyxia: a web front end that gives data scientists a Kubernetes workspace on demand

The problem: giving analysts a cluster without a platform team

A statistics institute, or any organisation with analysts who need serious compute, ends up with the same problem. There is a Kubernetes cluster, there are data, and there is a group of people who need a notebook environment with a specific amount of memory, sometimes a GPU, and access to a particular bucket of files. Between the analyst and the running container sit a dozen decisions that are not the analyst's job: which chart, which version, which namespace, which secrets, which service account, which quota.

Onyxia is a web app that aims at being the glue between multiple open source backend technologies to provide a state of the art working environment for data scientists. It is developed by the French National Institute of Statistics and Economic Studies, INSEE, and supported by the Interministerial Digital Directorate, DINUM.

The audience is two overlapping groups. The first is the analyst who wants a working Jupyter or RStudio session with a GPU and their own data, without writing a Kubernetes manifest. The second is the platform team, which gets a repeatable way to expose that without maintaining a bespoke internal portal for every new chart.

The framing matters, because Onyxia is not a notebook server. It is a launcher and a catalogue front end, and the documentation says as much: the catalog of available images is not part of the app, you can create your own. The charts the institute itself uses live in a separate repository, helm-charts-datascience, built for the institute's needs, and the application has a Helm chart interface, so the set of environments you can start is the set of charts you or your platform team have published.

The licence is MIT, the homepage is onyxia.sh, and the last push was on 2026-10-21, with releases v11.8.6 on 2026-10-19, v11.8.5 on 2026-10-16 and v11.8.4 on 2026-10-14.

The components it glues together

The core feature set in the project description reads as a list of integrations, and that is the architecture.

There is an interface for Helm charts, for example Jupyter or RStudio, deployed on demand on a Kubernetes cluster. Users define the amount of RAM, CPU and GPU they would like to allocate to their containers, so the resource request is a form field rather than a YAML edit. They can specify a custom init script to be executed at launch, and define environment variables to be made available in the containers.

Around that sit the platform integrations, and they are the parts that would otherwise be a week of work per project. There is deep integration with S3 for working with data, with the documentation making a deliberate point that S3 is treated as the open standard rather than the AWS service, and with Vault for secret management. There is Keycloak integration for identity. And users can save and restore their service configurations, which is what makes the environment reproducible rather than a one-off.

The repository layout matches this structure: an api/ directory for the backend, a web/ directory for the frontend, and a helm-chart/ directory for the deployment of Onyxia itself. There is an update-api.sh script at the root, which suggests the API definition is generated rather than hand written, and the .gitmodules file indicates that some dependencies are pulled in as submodules.

The main language is TypeScript, with the SonarCloud properties file present, which is the usual accompaniment to a project that wants its quality metrics tracked continuously rather than reviewed occasionally.

The catalogue is not the product, and that is the design decision

Most platforms of this kind ship a fixed list of environments, and the list becomes a negotiation between the platform team and the users. Onyxia deliberately steps out of that.

The description states that the catalog of available images is not part of the app, that you can create your own, and points to a separate repository for the charts the institute builds for its own needs. The application offers an interface for Helm charts, which means the unit of distribution is a chart rather than a container image managed by the application.

The difference in approach is not cosmetic. A built-in catalogue is easier to support and harder to extend, and it ties the user experience to the release cycle of the platform. A chart-driven approach puts the extension point in a package format that already has a lifecycle, a versioning scheme and a way of publishing that most Kubernetes teams understand.

The cost is real too. If you deploy Onyxia without publishing charts, you have a portal that opens nothing. The platform team has to own the chart catalogue, the version pinning of the images inside those charts, and the security updates for them. That work does not disappear, it moves, and for an organisation that just wants a Jupyter server for ten analysts the trade may not be worth it.

There is a second reason the chart boundary matters. Because the charts are the contract, an environment is reproducible: the same chart plus the same user settings gives the same workspace, which is what allows a saved configuration to be restored months later and still work.

What a user actually controls, and what they do not

The user-facing surface is small, and it is the clearest part of the design.

The first control is resources: RAM, CPU and GPU, allocated to the containers. GPUs are called out specifically in the description, which is a signal about the intended audience, because a shared GPU pool is the reason many statistics institutes run Kubernetes at all.

The second is the init script, a custom script executed at launch. This is how a workspace is prepared: installing a package, fetching a data extract, writing a configuration file. The third is environment variables, made available to the containers, which is the usual way to point a notebook at a bucket or a database.

The fourth is the ability to save and restore service configurations, listed as its own item in the feature set with its own screenshot. For an analyst who has tuned a stack of packages for a particular dataset, being able to store that environment and bring it back is the difference between a working setup and a repeated afternoon of installation.

What the user does not control is the platform plumbing: authentication through Keycloak, secrets through Vault, data access through S3, and the admission of the chart itself. The result is that an analyst chooses a tool, chooses resources, chooses a startup script and chooses variables, and never writes a manifest.

The security question that follows is where the integration choices pay off, and where a deployment has to be careful. If a user can supply an init script, that script runs inside their container, so the isolation boundary is the Kubernetes pod and the cluster policy, not the application. Onyxia reduces the number of things a user has to get right, but it does not create a sandbox, and a platform team still has to decide which charts may request a GPU and which buckets a given project may read.

Governance, community and the public instance

The repository carries the paperwork of a project that expects to be run by other organisations.

There is a GOVERNANCE.md, a MAINTAINERS.md, a ROADMAP.md, a CODE_OF_CONDUCT.md, a DCO.md and a SECURITY.md, which together describe who decides, who maintains, how changes are proposed and where vulnerabilities go. There is a publiccode.yml, the file that public sector software catalogues use to record a project's identity and licence, which fits a project developed by a national statistics institute and supported by a government directorate. The .sonarcloud.properties file and the CI workflow badge point at continuous integration and static analysis.

There is also a public instance, datalab.sspcloud.fr, described in the project banner as the public instance, alongside the general documentation at onyxia.sh and the contributor documentation at docs.onyxia.sh, which includes a roadmap page and a page for community calls.

The community rhythm is specific: monthly Onyxia community calls on the last Friday of every month at 1pm Paris time, running since November 2023, with a Slack workspace that the badge says has 1137 members. The project also maintains a presence at conferences, with talks listed from KubeCon NA 2025, where the UN gave a keynote, through the New Technologies for Statistics 2025 conference, Offentlig PaaS, PyData Paris 2024, Devoxx France 2023, KCD France 2023, Open Source Experience 2022, OW2Con 23 and the Energy Data Hack.

That record is the strongest evidence about the project. A platform that is presented at KubeCon and maintained by a national institute is not a weekend experiment, and the monthly call is the mechanism by which other organisations adopting it can influence it.

Where Onyxia is the wrong tool

There are clear boundaries, and they are worth stating before an organisation spends a quarter on it.

If you need the software catalogue built in, Onyxia is the wrong starting point, because the catalogue is not part of the app and you have to publish charts yourself. If you are a single analyst or a small team, a shared notebook server is a much smaller commitment than a platform with Helm charts, Keycloak, Vault and S3 wiring, and the platform features will not pay for themselves.

If your data does not live in S3 compatible storage, the data integration does nothing for you. The documentation is explicit that S3 is used as the open standard rather than the AWS service, which is good news if you run MinIO or Ceph, and is bad news if your data is on a network share that someone mounts into the container by hand.

And if you are expecting the application to decide what a safe environment looks like, it does not. The isolation is the Kubernetes pod, the resources are what the user asked for, and the init script is arbitrary code that the user wrote. Onyxia is a well-built launcher with a sensible set of integrations, and it inherits the security posture of the cluster it runs on.

The concrete next step for an evaluating team is the helm-chart/ directory and the contributor documentation, because they describe the deployment assumptions. Then the roadmap, because the direction of the project and the version you would pin matter when the release numbering is already at 11.8.6.

Editorial conclusion

Adopt Onyxia if you run a Kubernetes cluster for analysts and want them to launch their own workspace with the resources they need, with authentication, secrets and data access already solved. Do not adopt it if you need the software catalogue built in, because the images are yours to supply, and do not adopt it as a personal notebook server, since it assumes a platform team behind the cluster. Before you deploy it, read the governance and roadmap documents in the repository, check the Helm chart version against the release you plan to pin, and confirm that your storage is S3 compatible, since the data integration is built around that standard.

Frequently asked questions

Official sources

1. InseeFrLab/onyxia on GitHub
2. License: MIT
3. Project website
4. README
5. Releases