Setting up another OpenSAFELY

In our previous blog post, we described bringing the OpenSAFELY Schools "walking skeleton" to life: demonstrating the core components working together and showing that the fundamental concepts behind OpenSAFELY could be applied in a new domain. Since then, we've been working closely with colleagues at NIoT to take the next step and establish a fully automated OpenSAFELY Schools proof of concept.

At a high level, the goal sounds simple: deploy OpenSAFELY software into a new domain and a new secure environment. In practice, achieving that has involved a substantial amount of engineering, infrastructure, security, and integration work across the entire OpenSAFELY platform.

For the Bennett Institute tech team, the key challenge was that our existing infrastructure has always been centred around a single NHS OpenSAFELY deployment. The data, governance arrangements, professional communities, user base, operational processes, and partner infrastructure in the Schools project are all fundamentally different. From the outset it was clear that we would need a completely separate deployment of the OpenSAFELY service stack, with its own users, authentication systems, domains, services, configuration, and operational processes.

A full OpenSAFELY deployment is not a single application. It consists of numerous interconnected services running across both cloud and secure partner infrastructure, all of which must be deployed, configured, secured, integrated, monitored, and maintained. Although we write and maintain all of these components ourselves, much of the platform had previously only been exercised in the context of a single NHS deployment.

Over the years, we have invested significant effort in designing OpenSAFELY's architecture so that it could eventually support multiple independent deployments. The Schools project provided the first real opportunity to test whether those architectural decisions would work in practice.

One of the most visible examples is the service behind jobs.opensafely.org, known internally as job-server. In the NHS platform this service is responsible for managing users, projects, workspaces, permissions, audit trails, and released outputs. Much of that functionality is closely tied to the NHS OpenSAFELY operating model and was neither necessary nor desirable for the Schools proof of concept.

Rather than adapting a large NHS-specific service, we designed and built a new component called reference-gateway. This provides a streamlined interface for user authentication and job submission while remaining independent of NHS-specific workflows. We then deployed and configured a dedicated instance at jobs.ted.bennettoxford.org for OpenSAFELY Schools users.

Although intentionally lightweight at this stage, building and integrating a new service required work across authentication, permissions, deployment, configuration, testing, and user management. It also allowed us to validate a more general approach that can support OpenSAFELY Schools as it develops, while creating a foundation for future OpenSAFELY deployments in other domains.

Building the new gateway was only one part of the work. A much larger effort involved deploying, configuring, and integrating the wider OpenSAFELY platform across both cloud and secure infrastructure.

Broadly speaking, the remaining services fall into two groups: those running in cloud infrastructure, and those running inside the secure environment provided by our infrastructure partner.

The primary cloud-based services are:

• the job-runner controller, which receives and coordinates jobs submitted by users;
• the proxy service, which provides secure read-only access to GitHub repositories where researchers store their code, together with the software environments used to execute analyses.

Within the secure backend environment, the primary services are:

• the job-runner agent, which retrieves and executes analysis jobs;
• airlock, which provides secure access for reviewing outputs and managing release requests.

Each of these services required deployment, configuration, testing, and integration within NIoT's environment. While the underlying software architecture proved highly reusable, substantial work was still required to provision infrastructure, establish secure communications between services, configure authentication and permissions, adapt deployment processes, troubleshoot integration issues, and carry out end-to-end testing of the complete platform.

The process also helped us identify and remove assumptions that had accumulated around operating a single OpenSAFELY deployment. For example, we updated the proxy service to support configurable domain names rather than relying on NHS-specific defaults. Changes such as these were often relatively small in isolation, but collectively they were an important part of making the platform genuinely deployable in multiple settings.

Looking back, one of the most encouraging outcomes is that the platform behaved largely as we had hoped. By introducing a new, more generic user-facing gateway and reusing the wider OpenSAFELY infrastructure through careful configuration and integration, we were able to establish an independent Schools deployment without needing to redesign the platform from scratch.

There is still plenty of work ahead. We continue to deepen integration with NIoT's environment, refine operational processes, and finalise review and release workflows. However, an important milestone has already been achieved: we have demonstrated that the OpenSAFELY architecture can be successfully deployed beyond its original NHS setting.

Together with the walking skeleton demonstrated earlier in the project, this proof of concept represents a significant step towards a fully operational OpenSAFELY Schools platform. It shows not only that OpenSAFELY's approach can be applied outside healthcare, but also that the underlying platform can be adapted and deployed in entirely new domains while retaining the security, transparency, and reproducibility principles on which it was built.

Perhaps most importantly, this work has validated years of investment in the OpenSAFELY platform. Establishing a second deployment required substantial engineering effort across infrastructure, security, automation, and integration, but it demonstrated that OpenSAFELY has matured into a platform that can support new forms of trustworthy, privacy-preserving research beyond its original setting.