Hosting

Overview

Questions

• Where should I host my version control repositories?

Objectives

• Explain different options for hosting scientific work.

The second big question for groups that want to open up their work is where to host their code and data. One option is for the lab, the department, or the university to provide a server, manage accounts and backups, and so on. The main benefit of this is that it clarifies who owns what, which is particularly important if any of the material is sensitive (i.e., relates to experiments involving human subjects or may be used in a patent application). The main drawbacks are the cost of providing the service and its longevity: a scientist who has spent ten years collecting data would like to be sure that data will still be available ten years from now, but that’s well beyond the lifespan of most of the grants that fund academic infrastructure.

Another option is to purchase a domain and pay an Internet service provider (ISP) to host it. This gives the individual or group more control, and sidesteps problems that can arise when moving from one institution to another, but requires more time and effort to set up than either the option above or the option below.

The third option is to use a public hosting service like GitHub, GitLab, or BitBucket. Each of these services provides a web interface that enables people to create, view, and edit their code repositories. These services also provide communication and project management tools including issue tracking, wiki pages, email notifications, and code reviews. These services benefit from economies of scale and network effects: it’s easier to run one large service well than to run many smaller services to the same standard. It’s also easier for people to collaborate. Using a popular service can help connect your project with communities already using the same service.

As an example, Software Carpentry is on GitHub where you can find the source for this page. Anyone with a GitHub account can suggest changes to this text.

GitHub repositories can also be assigned DOIs, by connecting its releases to Zenodo. For example, 10.5281/zenodo.57467 is the DOI that has been “minted” for this introduction to Git.

Using large, well-established services can also help you quickly take advantage of powerful tools. One such tool, continuous integration (CI), can automatically run software builds and tests whenever code is committed or pull requests are submitted. Direct integration of CI with an online hosting service means this information is present in any pull request, and helps maintain code integrity and quality standards. While CI is still available in self-hosted situations, there is much less setup and maintenance involved with using an online service. Furthermore, such tools are often provided free of charge to open source projects, and are also available for private repositories for a fee.

Callout

Institutional Barriers

Sharing is the ideal for science, but many institutions place restrictions on sharing, for example to protect potentially patentable intellectual property. If you encounter such restrictions, it can be productive to inquire about the underlying motivations and either to request an exception for a specific project or domain, or to push more broadly for institutional reform to support more open science.

Challenge

Can My Work Be Public?

Find out whether you are allowed to host your work openly in a public repository. Can you do this unilaterally, or do you need permission from someone in your institution? If so, who?

Show me the solution

There is no universal rule, so use this short triage:

1. Check the data classification. PUBLIC data (the green tier in the Sagehen HPC security training) is fine for public repositories. PROPRIETARY (lab-internal) and RESTRICTED (FERPA, HIPAA, ITAR/EAR) data must never be pushed to GitHub, GitLab, or any third-party service.
2. Check the funding source. Some federal grants have publication or embargo clauses; corporate-funded work usually requires sign-off from the sponsor.
3. Check your PI. For student or research-staff work, the faculty PI is the gatekeeper. Their written agreement (an email is enough) is the cheapest insurance you can buy before clicking “Make repository public”.
4. Check Pomona ITS. For anything involving regulated data, contact its-hpc@pomona.edu before opening the repo. ITS may require the work live on Sagehen with controlled access rather than on a public host.

If the answer to all four is “yes, public is fine,” then you can typically open-source the repository unilaterally. If any answer is unclear, default to a private repository until you have explicit approval.

Challenge

Where Can I Share My Work?

Does your institution have a repository or repositories that you can use to share your papers, data and software? How do institutional repositories differ from services like arXiV, figshare, GitHub or GitLab?

Show me the solution

A practical comparison from a Pomona researcher’s perspective:

Service	Best for	Trade-offs
GitHub.com (public)	Code with broad reach; CI/CD; open source community	No control over the platform; sensitive data not allowed; free tier has LFS limits
GitHub.com (private/Education)	Code that needs to stay internal but uses GitHub’s tooling	Still hosted by Microsoft; not appropriate for FERPA/HIPAA/ITAR data
GitLab.com / self-hosted GitLab	Teams that want to migrate later; built-in CI; broader self-hosting story	Smaller third-party ecosystem than GitHub; self-hosting is real ops work
Pomona-hosted Sagehen storage (/bigdata)	Anything involving regulated data; very large files	Discoverability is poor; not a true “version control” host; pair with Git on a private remote for full provenance
arXiv / preprint servers	Manuscripts and figures, before or alongside journal submission	Not a code/data host; immutable record once posted
Figshare / Zenodo / Dryad	Persistent, citable datasets and code releases (DOIs)	Less interactive than GitHub; intended for archival rather than ongoing development

A common Pomona pattern: develop code in a GitHub private repo while the science is in flight, push raw data to Sagehen /bigdata so it never leaves College storage, and at publication time create a GitHub release that is mirrored to Zenodo for a citable DOI. That gives you good day-to-day collaboration tools, a clear audit trail for sensitive data, and a permanent reproducible record after the paper goes out.

Key Points

• Projects can be hosted on university servers, on personal domains, or on a public hosting service.
• Rules regarding intellectual property and storage of sensitive information apply no matter where code and data are hosted.