Open OnDemand: a browser portal in front of the cluster

HPC access without the command line

Open OnDemand is an open-source, NSF-funded web platform that makes high-performance computing and resources accessible to everyone.

The README states the problem plainly: instead of requiring users to learn SSH, command-line job schedulers, or VPN clients, OOD delivers a full HPC experience through any modern browser.

That is the whole proposition, and it is worth understanding who it is for. An HPC cluster is normally operated by a small team of specialists who know the scheduler, the file systems and the interconnect. The users are often students and researchers who need a job submitted this afternoon and have no interest in the cluster's internals. The gap between those two groups is what this portal closes, and the feature list reads as a list of the things the specialists would otherwise have to explain.

The scale is stated on the same line. It is deployed at over 2,100 organisations worldwide, from major research universities to national labs to technology companies, and it is the access layer powering some of the world's most capable supercomputers.

The badges in the README give the institutional picture: a NumFOCUS affiliation badge, an NSF funded badge, a Discourse forum badge, a deployments badge reading 2100+, and links to the website, the documentation, the community hub at ondemand.connectci.org and an events page.

The licence is MIT, the primary language is JavaScript, and the last push to the repository was on 2026-10-20. The releases are v4.1.7 in August 2026, v4.2.4 and v4.2.5 in September, which is a fairly brisk cadence for infrastructure software.

The eight features, and what each one replaces

The key features list is short, and each entry corresponds to something a cluster user would otherwise do by hand.

The web-based shell gives a full terminal in the browser with no SSH client needed. That is the entry point for everything else, and it is also the feature that removes the VPN client from the picture for users who only ever need to look at a file.

The file manager handles upload, download, edit and management of files across the HPC storage systems, which is the piece that stops people from moving large files through a laptop and a file transfer tool.

The project manager is the batch job interface: build, submit and monitor jobs through an interface rather than through the scheduler's command line. The README is careful to say build, because the editor is part of the flow and not just the submission.

The interactive apps launch Jupyter, RStudio, MATLAB, VS Code and more directly on compute nodes. That is the feature that changes what people compute, because it turns the cluster into a place where you can do interactive work rather than only batch work.

Multi-cluster support means a single OOD deployment can serve several HPC clusters, which is what makes it a platform rather than a front end for one machine.

Authentication integrates with Keycloak, Shibboleth, LDAP and Active Directory, CILogon, OIDC and SAML, which in practice means it fits an existing campus identity system rather than requiring a new one.

Customisation covers branding, authentication, job schedulers and software environments, so a site can present its own portal.

And the community app framework lets institutions develop and share their own Batch Connect and Passenger applications through what the README calls the Appverse.

Evaluating it before you install it

The getting started section is two links and one point.

The first is the installation documentation, including system requirements, at the documentation site. The second is the test drive, which the README describes as a way to try Open OnDemand before deploying it at your site.

That test drive is the sensible first step for anybody evaluating this, because the evaluation questions are about infrastructure rather than about code. Whether OOD fits your site depends on whether your scheduler is supported, whether your storage can be exposed as the file manager expects, whether your identity provider integrates, and whether the interactive applications you want are installed on the cluster as software environments.

The last of those is the one people underestimate. An interactive app in OOD is a web application that the portal launches against an environment on the compute node, and if the module for RStudio or MATLAB or VS Code is not in the environment module system, the portal has nothing to launch. The customisation feature and the interactive apps feature meet here, and the answer is usually a site administrator's work rather than a configuration line.

The documentation site is at osc.github.io/ood-documentation, and the requirements page is the one to read first.

The repository is an on-premises install, not a library

The top level of the repository describes a deployable system rather than a package, and that shapes what you are looking at when you clone it.

The application directories are the most visible part: apps/ holds the applications the portal serves, lib/ holds the shared library code, ood-portal-generator/ generates the portal's pages, ood_auth_map/ handles the authentication mapping, mod_ood_proxy/ is the Apache module that puts the portal in front of the user's own session, and nginx_stage/ holds the web server configuration. Then there is packaging/ for the packages the project ships, hooks/ for the install-time hooks, spec/ and tests/ for the test suites, and docs/.

The Ruby and JavaScript tooling sits alongside. There is a Gemfile and a Gemfile.lock, a Rakefile for the tasks, a .rubocop.yml for the Ruby style and a .codespellrc for spelling, plus Dockerfile.dev and Dockerfile.example for the container builds.

The project files around them are the ones that say how serious the project is about being a community effort. ACCESSIBILITY.md is a file you do not see in most infrastructure projects, and for a portal whose users are researchers using assistive technology, that is not decoration. SECURITY.md is there for the vulnerability disclosure route, CODE_OF_CONDUCT.md for the community rules, CONTRIBUTING.md and DEVELOPMENT.md for the two audiences, and a contributor_jam_guide.md, which suggests the project runs contributor jams.

There is also VERSIONING_POLICY.md and a ROADMAP.md, which together suggest a project with a release process and a plan rather than one that ships when a maintainer feels like it. And the scholarly metadata is complete: CITATION.cff, a Zenodo record in .zenodo.json, codemeta.json, and paper.md with paper.bib, so that a paper about work using the platform can cite it properly.

The funding, the maintainers and the community

The acknowledgments section is short and unusually concrete.

This work is based upon support from the National Science Foundation under five grant numbers, 1534949, 1835725, 2138286, 2303692 and 2411375. That is a series of grants rather than a single one, so the funding has been continuous over the life of the project.

The development and maintenance are done by the Ohio Supercomputer Center in partnership with the global OOD community. OSC is one of the long established supercomputer centres in the United States, and running a production portal for thousands of researchers a day is what makes it a plausible home for the project.

The community side has its own infrastructure. There is a Discourse forum for discussion, a community hub at ondemand.connectci.org, an events page for conferences and training, and the contributor jam guide. The README also carries a test drive link, which is a small thing that says the project wants visitors.

For an adopter, this combination is the part that matters. A portal that runs in front of a supercomputing centre is infrastructure that has to survive upgrades, and the fact that the maintainers are a supercomputing centre rather than a vendor means the deployment advice comes from people who run one.

Where Open OnDemand is the wrong tool

There are clear cases where a web portal in front of a cluster is the wrong answer, and they come from who the users are.

If you have five researchers who already live in SSH, the portal adds a layer they will bypass. The value of OOD is in reaching people the cluster team would otherwise support one at a time, and if that population is small and expert, the cost of running a portal is not repaid.

The second limit is that it is a deployment, not a product. You cannot install Open OnDemand on a laptop and get a supercomputer, because what it provides is a web interface to a scheduler, a storage system and an identity provider that you already have. Somebody at the site has to do that work, and the effort is in the site, not in the software.

The third is the interactive applications. They are the feature that makes the portal attractive and also the most demanding, because each one is a web application that has to be installed and configured on the compute side, maintained as the underlying software moves, and supported for the people who use them. A site that wants a single Jupyter and nothing else can do that; a site that wants a dozen applications is running a small application portfolio.

The alternative approach is to give the users the cluster directly, with the scheduler's own web interface if it has one, and the shell for the rest. The difference in approach is that Open OnDemand wraps the scheduler, the storage and the interactive sessions in one branded, authenticated portal with a community around it, while the direct approach leaves the user in the shell with no shared interface and no place to publish the site own software environments. The trade is a great deal of site administration against a much better experience for the people who are not experts.

Editorial conclusion

Open OnDemand suits a university, laboratory or company that has a cluster and wants more than its expert users, and that wants its researchers to reach a batch scheduler, the shared storage and an interactive session without a support ticket. It does not suit somebody looking for a tool to run on their own machine, because it is deployed against a real site with its own authentication, storage and scheduler, and it does not suit a handful of expert users who already live in SSH, since the portal adds a layer they would bypass. Check three things before you evaluate it: that the documentation's requirements page matches the infrastructure you have, that the authentication you need is on the supported list of Keycloak, Shibboleth, LDAP, CILogon, OIDC and SAML integrations, and that the interactive applications you want, Jupyter, RStudio, MATLAB or VS Code, exist as software environments on the cluster rather than as something the portal can install. The last push to the repository was on 2026-10-20 and the newest release is v4.2.5.

Frequently asked questions

Official sources

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