OneSciencePlace: Composable research computing, data, and publishing

Composable research platform Open-source distribution planned

OneSciencePlace

Research applications, data access, workflows, and publishing in a single composable platform 
OneSciencePlace is a web-based platform for delivering research and education capabilities through a coherent, reusable environment. It can support a focused project, a shared gateway, or a broader platform that grows over time.

Explore the platform

What Is OSP?

A managed, multi-tenant platform that unifies app execution, data sharing, publishing, and site content, eliminating the need to stitch, maintain, and manage different tools.

Apps

Run native or container-based command-line, web, or graphical apps, with a no-code launch UI on a web browser.

Data

POSIX and S3/object storage; optional archiving of job outputs.

Publishing

Publish apps, datasets, and other content with metadata and DOIs.

What OSP helps with

Faster delivery

Deploy portals, gateways, repositories, and application environments faster by reusing a common platform instead of building each one from scratch.

Lower implementation overhead

Reduce the amount of specialized web and backend development needed for common research platform use cases.

Room to grow

Start with a focused need and expand over time across groups, departments, institutions, or collaborations. Lab → department → institution → multi-institution.

Apps

OSP supports browser-based delivery of native, container-based, command-line, web, and graphical applications. It provides a no-code launch interface for building forms and user-facing application controls, while preserving reproducibility through tracked job parameters and restart support.

  • Containers: single-port web containers.
  • Native: command line serial, parallel, or distributed executables are supported.
  • Graphical apps: embed VNC/DCV/Xpra in the container; OSP proxies to the browser.
  • No-code launch UI: build forms and complex UIs without writing code.
  • Restrictions: Apps can be private or tenant-wide. Group restrictions planned.
  • Reproducibility: Job parameters are tracked and stored.
  • Clone & restart: one-click re-run; checkpoint/resume when the app supports it.
  • Visibility: apps are tenant-scoped; publish as single-user or site-wide (groups planned).
Have existing containers or native codes?
OSP can help bring them into a reusable web-based environment.

Compute Integration

Targets

Single VMs/hosts (no scheduler) and Slurm clusters; multiple systems per tenant.

Private nodes

Proxy to non-public compute nodes behind NAT; only the gateway is internet-facing.

Parallel & distributed

MPI and many-task/array workloads supported; GPU when available on the target.

Data, Storage & Publishing

  • Storage today: POSIX and S3/object + file sharing.
  • Globus: Globus data transfer planned.
  • Publish: publish datasets and apps with rich metadata and DOIs, FAIR data support planned.
  • Archiving: post-run configuration support archive job outputs to POSIX or S3.
OSP can be aligned with your data management, storage, and archiving needs

Identity & Access

Federated sign-in

OIDC/SAML (e.g., CILogon, InCommon) and LDAP. CILogon and Globus Auth are supported.

Heterogeneous IdPs

No shared IdP required across systems; per-system identity mapping.

SSH key bridging

Optional SSH key bridging to bind web users to remote Unix accounts.

Where OSP fits

Project and lab environments

Share applications, data, and outputs through a focused site.

Course & Workshop

Deliver prebuilt applications and simple user access for instruction and training.

Science Gateways

Provide access to one or more applications across local, campus, or national resources.

HPC Portal or Shared Institutional Platform

Support multiple groups, services, and workflows on a reusable foundation.

Featured Project: Quakeworx

Quakeworx is an extensible framework for earthquake simulations delivered with OSP.
quakeworx.org

Common Challenges?

  • Researchers need HPC access; the command line blocks many of them.
  • Staff time is limited for evaluating or building DIY portals.
  • Maintaining a custom gateway consumes scarce FTEs.
  • Sponsors require Open Access; you need DOIs and metadata without building a repo.

Typical deployment approach

  1. Define the use case: Identify the applications, users, data, and infrastructure the site needs to support.

  2. Configure the environment: Set up site structure, branding, access model, and core platform components.

  3. Connect systems: Integrate identity, compute resources, storage, and related services.

  4. Add applications and workflows: Configure application launch, data handling, publishing, and user-facing workflows.

  5. Launch and operate: Run the platform as a managed service or align it with your preferred operational model.

Lineage

OneSciencePlace was originally initiated within  NSF’s Science Gateway Community Institute and is informed by three decades of research on cyberinfrastructure, with contributors from people who helped develop Hubzero, SeedMeLab, CIPRES, Apache Airavata, and Tapis. The National Science Foundation funded this work under award numbers 1547611, 2311206, 2311207, and 2311208.

Open Source

OneSciencePlace is built on open-source software and open standards. Core components of the platform are available in public repositories and are actively maintained within their respective communities. The integrated distribution is currently managed as a coordinated release, with broader public release work underway.

In alignment with NSF CSSI objectives, we are working toward a structured public release of the unified distribution. Release milestones are tied to funded development phases and institutional partnerships. If you would like to collaborate early or access the source code, please contact us.

Interested in whether OSP fits your use case? Talk with us