Developed by UCLA, SDSC, and TACC
Documentation: Home · End Users · App Contributors · Tutorials · Systems · Tenant Admin · Reference
OneSciencePlace Documentation
This documentation covers the OneSciencePlace (OSP) platform for end users, app contributors, system administrators, and tenant administrators. Each guide is organized by role — find your role in the persona guide below and follow the link to the relevant page.
Last updated: April 2026. Documentation is actively expanding.
On this page
- What is OneSciencePlace
- Core concepts
- Technology stack
- Who this documentation is for
- Getting help
- Recorded tutorial
What is OneSciencePlace
OneSciencePlace (OSP) is a web-based platform for delivering research and education capabilities — applications, data, and publishing — through a single, coherent environment. A typical OSP deployment presents a branded portal through which users browse and launch applications, run jobs on connected compute systems, work with data, and publish results as citable objects.
OSP is a multi-tenant platform. Each deployment (also called a tenant) has its own branding, user community, applications, connected systems, and content. Tenants operate independently while sharing the underlying orchestration layer.
Core concepts
Five building blocks underpin everything in OSP. Understanding these will help you find your way around the platform regardless of your role.
App — A structured, versioned definition of a computational tool or workflow. An app encapsulates everything needed to run a job: execution commands, input and output specifications, runtime environment, and system requirements. Apps can be shared across users, published as citable objects, and restarted with their original parameters.
System — An integrated computing or storage resource connected to OSP. A system may be an HPC cluster, a single host, or a cloud instance — on-premises or remote. Users interact with systems through OSP's web interface to run jobs, store data, and manage files. A single app is mapped to a single system; the same underlying tool deployed on a different system is represented as a separate app.
Job — An instance of an app execution. Jobs are submitted through an app's launch form, monitored in real time, and can be cloned and re-submitted with their original or modified parameters. Every job carries a record of the app, system, parameters, inputs, and outputs used.
Data — Files and folders extended with metadata, comments, and sharing controls. Custom viewers and visualization plugins can be added for non-standard file types.
Publication — A structured, versioned record for sharing scholarly content in compliance with FAIR principles (Findable, Accessible, Interoperable, Reusable). Publications can be assigned persistent identifiers (DOI, Handle, or ARK) and optionally go through an editorial review workflow before release.
Technology stack
OSP is built on mature, widely-used open-source foundations rather than a custom ground-up stack. This keeps the platform's surface area manageable and lets OSP inherit the documentation, community support, and security practices of the underlying projects.
OSP's components fall into three categories:
Drupal modules
The user-facing platform is delivered as a set of Drupal modules on top of a standard Drupal installation. This covers the website, user management, scholarly content types, access management, the app store, the app UI builder, job management, and site management. Deployments benefit from Drupal's authentication, access control, theming, and extensive contributed module ecosystem.
Services integrated with Drupal
Several capabilities run as separate services that the Drupal modules integrate with: search, ticketing, metrics, data systems, and light storage. Keeping these as distinct services lets each one scale and be upgraded independently of the main CMS.
Standalone systems and services
The execution and routing layers run outside Drupal entirely:
- Tapis (developed at TACC) is the API layer for job and system lifecycle management across connected computing resources. Tapis handles the details of submitting jobs, monitoring them, staging inputs and outputs, and integrating with schedulers like Slurm.
- A satellite proxy provides secure routing for interactive Web and VNC app sessions.
- Container runtimes — Docker and Singularity (Apptainer) — run the actual scientific applications on connected systems. OSP does not prescribe a runtime; the system administrator selects what's supported on each system.
- Execution systems include Linux hosts and HPC clusters using Slurm.
This stack reflects the current architecture; specifics may evolve in future releases. For the details relevant to your role — identity integration, system configuration, or app packaging — see the corresponding guide.
Who this documentation is for
This documentation is organized by role. Find yours below and go to the corresponding guide.
End users
Researchers, students, and community members who launch applications, run jobs, and work with results. If you are using OSP to do research, take a course, or access tools your institution has made available, this is your starting point.
App contributors
Researchers and research software engineers who package computational tools so others can use them. If you are publishing apps for others to launch through OSP — your own scientific code, a Jupyter environment, a containerized workflow — start here.
Go to the App Contributor Guide → | Go to the App Contributor Tutorials →
System administrators
HPC center staff, research computing professionals, and IT staff who connect compute and storage systems to an OSP deployment. If you are responsible for registering clusters, hosts, or storage with OSP, configuring credentials, or setting up scheduler profiles, start here.
Go to the System Administrator Guide →
Tenant administrators
Deployment leads responsible for user roles, content, publishing workflows, and overall site administration. If you manage who has access to what, oversee publication review, or set the deployment's policies, start here.
Go to the Tenant Administrator Guide →
A note on roles
Roles are not exclusive. A single person may be an app contributor and an end user, or a tenant administrator who also administers systems. Read the guides that match what you are trying to do, not just one.
Getting help
If you cannot find what you need in this documentation, contact the OSP team at osp@oarc.ucla.edu. Documentation is actively expanding, and we welcome questions and suggestions for topics to cover.
For platform overview, features, use cases, and deployment information, visit onescienceplace.org.
The complete glossary of OSP terms is on the Reference page.
Recorded tutorial and pilot environment
The 2025 Science Gateways Conference tutorial provides a hands-on introduction to OSP — application deployment, UI development, compute integration, publishing, and access management — with no programming experience required. Watch the recording, or browse the accompanying slides on overview, creating apps, publications, and permissions.
To follow along or experiment with OSP firsthand, the pilot environment at pilot.onescienceplace.org is available — contact the OSP team for an account.
Next: End User Guide →