OneSciencePlace (OSP) is available today as a managed deployment. An open-source distribution for institutional self-hosting is planned.

Building and maintaining a custom research portal typically requires dedicated web engineering, ongoing security management, and continuous integration work. OneSciencePlace replaces that effort with a managed service — your team retains control of applications, content, and users while the OSP team handles the platform layer.

How it works

The deployment process

An engagement typically begins with a conversation about your project, and proceeds through five steps. There is no fixed starting configuration — deployments are scoped to fit your project's goals, systems, and support needs.

01 / DISCOVERY
Define the use case
Identify the applications, users, data, and infrastructure your site needs to support.
02 / CONFIG
Configure the environment
Site structure, branding, access model, and core platform components.
03 / CONNECT
Integrate systems
Identity, compute resources, storage, and related services — across heterogeneous systems.
04 / POPULATE
Apps & docs
Configure applications, data management, publishing, and user-facing documentation.
05 / OPERATE
Launch & run
Operated as a managed service, or aligned with your preferred operational model. Scope can grow as your needs evolve.
Audience

Who this fits

Campus computing groups deploying an HPC portal
Researchers building science gateways for their community
Multi-institutional projects or centers with compute, data, and dissemination needs
Education and training initiatives needing prebuilt application environments
Faculty labs or research centers without dedicated engineering staff
Institutional repositories needing FAIR-compliant publishing infrastructure
Scope

What a deployment can include

Each deployment is scoped to fit. The components below are typical of an OSP engagement; not every deployment uses every component.

Typical components
  • Application onboarding and configuration
  • Compute and storage integration
  • Identity and access setup, including federated authentication
  • Data sharing and publishing workflows
  • Site structure, branding, and content setup
  • Ongoing platform support and updates
Collaboration model

What we each bring

Each deployment is a collaboration between the OSP team and your project or institution. Roles can be adjusted based on your team's capacity and preferences — some projects prefer more local control, others prefer a more fully supported model.

The OSP team provides
  • The OSP software stack, hosted and operated by the OSP team
  • Platform deployment, updates, and security patching
  • System integration and core configuration
  • Identity and access setup
  • Technical guidance on application onboarding
  • Issue resolution for the platform layer
Your project or institution provides
  • Research use cases and priorities
  • Application-specific requirements
  • Local policy and compliance decisions
  • Project content and user community management
Resources

Compute and storage

Compute and storage resources can be provided by your institution or requested as part of the deployment. Resources may be on-premises, cloud-based, or a combination of both.

Supported compute environments include Slurm-based HPC clusters and standalone Linux hosts. OSP can integrate your existing HPC clusters, cloud instances, or ACCESS and NAIRR allocations. OSP integrates with these systems entirely in user space — no privileged access on the connected systems is required.

Storage can be POSIX file systems or S3-compatible object storage, on-premises or in the cloud.

Evaluate first

Try the pilot

Before scoping a deployment, you can explore OneSciencePlace yourself in the public pilot environment. The pilot uses the same platform as production deployments, with sample applications and a public-access tenant.

Pilot environment
Browse curated applications, launch jobs, and see the no-code form builder firsthand.
Pricing

How pricing works

Pricing is scoped by project and reflects deployment scope, systems integration, and ongoing support. For most institutions, OneSciencePlace replaces the equivalent of significant custom engineering and operations effort, making it a cost-effective alternative to building and maintaining a portal in-house.

Engagement begins with a conversation to understand your project; pricing follows from the scoped deployment plan.

Future state

Open-source distribution

An open-source distribution for institutional self-hosting is planned. When available, it will enable institutions to deploy and operate OneSciencePlace on their own infrastructure. Managed deployment is the current delivery model.

Core components are already available in public repositories. Learn more about the open-source plan.

Common questions

Frequently asked questions

Is OneSciencePlace available now?
Yes. OSP is available as a managed deployment today. Contact the OSP team to start a conversation about your use case.
Is OSP open source?
OSP is built on open-source software and open standards. A unified open-source distribution for self-hosting is planned. Core components are already available in public repositories.
Can I self-host OSP?
Not yet. Self-hosting will be enabled by the planned open-source distribution. Managed deployment is the current delivery model.
Who is OSP for?
OSP is designed for HPC portals, science gateways, education and training environments, faculty labs, and research projects — from a single PI lab to national-scale systems and communities.
What compute systems does OSP integrate with?
OSP integrates with Slurm-based HPC clusters and standalone Linux hosts, on-premises or in the cloud. National resources, including ACCESS and NAIRR allocations, can also be integrated. Multiple systems per deployment are supported.
Can I bring my own compute and storage?
Yes. If you have existing HPC clusters, cloud instances, storage systems, or national resource allocations, OSP can integrate with them directly. Compute and storage can also be requested from the OSP team if needed.
Does OSP require root access on my systems?
No. OSP integrates with connected systems entirely in user space. No privileged access or per-system installation is required on the systems OSP connects to.
How does engagement start?
With a conversation. Contact the OSP team to discuss your use case, and we will work with you to scope a deployment plan that fits your project.

Discuss your deployment

Talk with us about your project, or explore the platform yourself in the pilot environment.

Request a demo Explore the pilot See use cases