Runtime Control
Control a running Rewire instance without restarting it.
Rewire supports runtime control over a loopback gRPC service. You can start new recordings and inspect the topics a running bridge is subscribed to — all without restarting it.
How it works
When rewire record starts, it hosts a gRPC control service on an OS-assigned port on 127.0.0.1
and registers itself by writing a small per-process file (rewire-<pid>.json) to the runtime
directory. CLI commands such as rewire log and rewire topics read that registry to discover the
live bridge and dial its endpoint.
Earlier versions used a Unix domain socket for this. As of v0.4.0, runtime control runs over loopback gRPC instead — the Unix-socket IPC has been removed.
Starting a new recording
rewire logThis tells the running Rewire instance to start a new recording. The viewer opens a new
recording session while the bridge keeps streaming — no data loss, no reconnection. Recordings
started this way behave exactly like the startup recording — they survive relay and
viewer restarts, and rewire status reports whichever recording is live.
This is useful when you want to segment recordings by experiment, test run, or scenario without interrupting the data flow.
If several bridges are running, target a specific one with --pid:
rewire log --pid 12345Use cases
- Experiment segmentation — start a new recording for each test run
- Continuous monitoring — keep Rewire running and trigger recordings on demand
- CI/CD integration — script recording management in automated test pipelines
Requirements
Runtime control requires both the running rewire record instance and the client command to be on
the same machine: the gRPC service binds to loopback (127.0.0.1) only.
The rewire status command is different — it queries a relay over the network rather
than a local bridge, so it works from any machine that can reach the relay port.