MLOps in Public Health: Workspaces, Pipelines, and Governance
Table of Contents
Modern data science and ML work depends on consistent environments, controlled access patterns, and reproducible workflows. In public health, these needs underpin governance as much as they support productivity.
At Wellington-Dufferin-Guelph Public Health (WDGPH), we have found that the simplest way to address both delivery and risk is to standardize how tools are delivered into managed, isolated environments, and to route repeatable work through governed pipelines. This post focuses on those two foundations, developer environments and pipelines, within a larger MLOps program.
MLOps is the set of practices that make machine learning work operational: repeatable training and scoring, versioned artifacts, monitored runs, controlled access to data and secrets, and a path to change management over time.
This post only covers a small part of that surface area, specifically the foundations that make later practices feasible: standardized workspaces, controlled pipeline execution, and the access boundaries that allow sensitive workflows to run in a governed way.
We discuss these foundations through the lens of WDGPH’s Kubeflow-based platform. The same ideas can be implemented with other tooling.
Foundations for governed data work #
Most AI and data science maturity frameworks converge on the same early milestones: a shared environment that avoids disparate laptop setups, a repeatable execution path for pipelines, and baseline governance that supports least privilege and traceability.
In practice, teams often begin local-first. Over time, that becomes a mix of laptops, ad-hoc environments, mismatched dependency versions, and an accumulating set of scripts that constitute fragile automation. Even when everyone is careful, this creates avoidable variance: it becomes hard to know what is running where, hard to reproduce results, and difficult to apply consistent controls around data access and credentials. Collaboration also slows down when shared work depends on aligning toolchains before any substantive work begins.
Our goal was to create a secure default environment where staff can do serious public health data science, data engineering, and AI work without each person maintaining their own unique software stack, while avoiding unnecessary restrictions that slow innovation or degrade developer experience.
Workspaces #
Workspaces at WDGPH are container-based development environments with a consistent toolchain, a browser-accessible editor and terminal, and a small set of approved defaults.
Our workspaces are built around code-server (VS Code in the browser) as the primary interactive experience. We chose this approach because it provides a familiar interface, strong extension support, and a rapid update cadence.
We provide a base workspace image that covers the common cases, and a small number of specialized images for specific requirements. For example, we maintain a dedicated image for browser automation workfow development. We keep images minimal and performant, and we reduce the risk surface by avoiding unnecessary packages and privileges.
Workspace images are versioned and published to a private container registry for deployment into our Kubeflow-based platform. Updates are managed through GitHub pull requests. Dependency updates are proposed automatically, and every pull request triggers vulnerability scanning before an image is promoted.
Developer Experience #
A managed environment only works if people use it. In practice, usability and governance are coupled. When the default workspace is comfortable and fast, teams are less likely to route around it with local setups that are harder to secure and support.
We treat the workspace as an opinionated baseline. Staff can personalize their environment (for example themes, key bindings, and local settings), and they can enable or disable approved extensions within their own workspace. When someone wants a new extension or tool made available, it is usually handled as a small change request against the workspace image with team review.
For Python work, we standardize project and dependency management using uv so environments can be recreated predictably. Within their workspace, users can also install user-scoped binaries without needing administrative access.
We support direct integration with GitHub from the workspace. New staff and trainees are onboarded into this workflow on day one. A practical target is that everyone can make a first commit from this environment on their first day.
Isolation and Access #
We run workspaces as namespaced environments with role-based access control (RBAC). Even before identity controls are applied, container-based workspaces provide a baseline isolation boundary by running each user’s tools and processes inside a dedicated, non-root container with its own filesystem and runtime, rather than directly on a shared host. The practical effect is that a user starts with tooling, not blanket access. This is reinforced with network access restrictions and monitoring.
Access to datasets, mounted storage, and secrets is granted on a request basis and scoped to need. Users do not have cluster-wide access. Where it is appropriate, trained staff can request a role that enables them to manage pipelines within a specific namespace from their workspace.
If GPU capacity is available, it can also be exposed to approved namespaces for development and pipeline runs using the same access model.
We maintain a documented process for vetting new packages and tools. If a proposed tool introduces an external service or data egress, a privacy impact assessment is triggered.
Pipelines #
As projects mature, we shift work from interactive exploration into automated pipelines. Pipelines are the controlled path from a notebook or script to repeatable execution. They reduce one-off runs, and they create a consistent place to apply governance controls.
We build and orchestrate pipelines with Kubeflow Pipelines. Components run in immutable, isolated, ephemeral images built from restricted foundations. Runtime package installation during scheduled execution is disabled to enforce consistency.
Scheduled pipelines consume component images emitted from the latest stable state of our Kubeflow Pipelines monorepo. Our monorepo contains image definitions, shared utilities used during development and execution of pipelines (such as standardized logging and run metadata utilities), and the pipeline definitions themselves. Updates to our base images occurs through a pull request process that covers pipeline compilation checks, vulnerability scan results that are either mitigated or explicitly accepted, and manual approval. If a pipeline needs a new capability, we add a new base image or extend an existing one via the same process. Like our workspace images, dependency updates to images are automated.
Images are pushed to a private container registry using tags that tie back to a specific commit and branch context. This supports one-off test runs of non-main development branches without changing the images used by scheduled pipelines. When base images are updated, we refresh pipeline component definitions against the latest foundations using an internal utility.
This structure supports reproducibility and provenance in a practical way. Runs can be tied back to a specific repository state, a specific set of component images, and a recorded set of parameters and schema versions. It also makes operational handoff easier because production pipelines are managed as team assets rather than personal automation.
The governance benefit is clear: both interactive work and scheduled execution occur inside governed infrastructure, and the platform produces a usable record of what ran, where it ran, and with what configuration.
Code, state, and data #
We separate code, workspace files, secrets, and data sources.
Source code is versioned and synchronized with GitHub in either private or public repositories, depending on the project and what can be shared. Workspace files are reserved for what developers need day to day that may not belong elsewhere, such as configuration files and small scratch outputs.
Secrets are never built into images or code. Instead, workloads retrieve secrets at runtime from a cloud-based vault. This keeps credential handling consistent and supports rotation and monitoring.
Data sources typically live in our data lake, which is integrated with both workspaces and pipelines. Details around our data lake strategy are saved for a future article.
Observed effects at WDGPH #
We have been able to onboard analysts, data and analytics specialists, data scientists, data engineers, epidemiologists, and trainees into a shared environment that supports contemporary workflows without each person maintaining their own stack. Local automations have been reduced, and team-managed patterns have replaced many one-off approaches. Pairing on projects is easier because the environment is predictable. It is also easier to transition and rebuild work when staff rotate, because production pipelines are managed as team assets.
For operational work, reliability looks like scheduled outputs arriving when expected. This includes reports, dashboard refreshes, batch model updates, and automated notifications. A managed workspace and pipeline model does not guarantee reliability by itself, but it creates the conditions to manage it as an operational property rather than an individual practice.
What to evaluate #
If you are building or procuring platform capability in a public health setting, it is often useful to evaluate options through a small set of questions:
How will you provide a consistent developer environment that supports mixed technical backgrounds, without creating a collection of unmanaged local setups?
How will work move from exploration to repeatable execution with a clear record of code, inputs, and runtime environment?
How will access boundaries, secrets handling, and change management be enforced as defaults, not as optional add-ons?
At WDGPH, Kubeflow has been a practical vehicle for these goals. In another organization, the right answer may be different. The underlying pattern remains consistent: standardized environments, isolation that supports sensitive workflows, and pipeline tooling that supports reproducibility, provenance, and operational reliability.