Monorepos
Last updated on June 26, 2026
A TofuPilot project holds one procedure or many, so a monorepo is the right layout when you want to share instrument drivers, calibration sequences, and finalizer phases across procedures. The patterns below scale from a single procedure on a laptop up to a fleet of related products that ship from the same repo.
Single procedure
When a project covers a single procedure, everything lives next to one procedure .yaml file. Phases, plugs, and the environment all sit in the same folder so you do not have to think about paths.
Multiple procedures
When a second product joins the repo, lift the reusable code into shared/ and keep each procedure under procedures/<name>/ with its own .yaml file. Each procedure then references shared code by relative path, so you keep one canonical copy of every driver and helper.
Each procedure .yaml file resolves Python references against its own directory, so shared modules are reached either via relative paths (../../shared/phases/save_to_mes) or by adding shared/ to PYTHONPATH from .env.local.
Sharing a plug across procedures
Define each plug once under shared/plugs/ and reference it from every procedure .yaml file that needs it, so a single file holds the canonical driver.
plugs:
- name: Power Supply
python: ../../shared/plugs/RigolDP832:RigolDP832When the driver changes, every procedure picks up the new version on the next run, so you do not have to remember to bump versions across the repo.
How is this guide?
Station
Run the TofuPilot CLI as a station service on the factory floor, with deployed procedures, a live operator UI, and automatic report upload.
OpenHTF
Learn how to run existing OpenHTF suites through TofuPilot so phase outcomes, measurements, logs, and attachments upload to the dashboard automatically.