UDMI provides modular tmux-encapsulated controllers for managing local service stacks, background daemons, and test harnesses with full environment isolation, diagnostic probes, and zero-sudo unprivileged execution.
The local infrastructure is divided into modular, decoupled service domains:
| Controller Script | Tmux Session | Default Services | Optional Services (++svc) |
Description |
|---|---|---|---|---|
bin/tmux_base |
udmi_base[~ns] |
clone, certs |
(none) | Site model provisioning and CA / reflector certificate generation. |
bin/tmux_barbican |
udmi_barbican[~ns] |
etcd, mosquitto, udmis |
pubsub |
Core message bus, distributed registry, and UDMIS control plane. |
bin/tmux_butler |
udmi_butler[~ns] |
postgres, influxdb, butler |
validator, registrar |
Data persistence, telemetry storage, and event processing. |
bin/tmux_bridgehead |
udmi_bridgehead[~ns] |
pubber |
spotter |
Device-under-test (DUT) and network discovery agent emulation. |
bin/tmux_mcp |
udmi_mcp[~ns] |
server |
(none) | FastMCP test and diagnostic automation server. |
bin/tmux_<box> [command] [target_or_namespace] [project_spec] [target_id] [service_filters...]
Running any bin/tmux_<name> script with no arguments (or help, -h, --help) displays usage instructions and available services, then exits cleanly.
The lifecycle of each controller revolves around four operational states:
start: Initializes and starts configured services in a background tmux session. Preserves existing certificates, cloned models, and runtime database state (non-destructive, idempotent).stop: Shuts down services and terminates the tmux session without deleting site models, certs, or data files, preserving state for diagnostic inspection.clean: The destructive operation that purges runtime state, cached certificates, databases, and cloned site models (sites/udmi~<ns>) without starting any services.restart: Clean-slate fresh restart equivalent to the sequence { stop, clean, start }.status: Displays session lifecycle status and semantic diagnostic health probes (PIDs, listening ports, health checks).logs: Dumps pane scrollback buffer (bin/tmux_<box> logs [window] [lines]).attach: Interactively attaches to the session or specific window (Ctrl-b d to detach).help: Shows available commands and service options.Passing a bare semantic namespace identifier (e.g. btesting, alpha, staging):
bin/tmux_barbican start btesting
[20000, 55000] (port = 20000 + ((SHA-256(ns) % 3500) * 10)).var/. Root permissions are only required when installing system-level dependencies (e.g., sudo bin/setup_base).udmi_<box>~<namespace> (e.g. udmi_barbican~btesting).sites/udmi~<namespace>.When no target is passed (e.g. bin/tmux_barbican start or bin/udmi start):
default.udmi_<box>~default.//mqtt/localhost:<PORT> (derived for default).sites/udmi~default.When specifying a custom site model directory (e.g. sites/my_site):
# Valid:
bin/tmux_barbican start sites/my_site //mqtt/localhost:46432
# Invalid (fails fast):
bin/tmux_barbican start sites/my_site
bin/tmux_barbican start sites/my_site btesting
Fine-tune which services run inside the tmux session during start:
+service): Run only the specified service.
bin/tmux_barbican start btesting +mosquitto
!service): Exclude a default service.
bin/tmux_barbican start btesting !udmis
++service): Enable an optional service that is disabled by default.
bin/tmux_barbican start btesting ++pubsub
For unified local infrastructure orchestration across multiple service controllers, see bin/udmi (UDMI Local Orchestrator).