These tutorials start in the editor and finish on a runner. Complete Getting Started first so package import and approval are familiar.
Use a separate project for each tutorial. After building a graph, trigger it in the editor's Simulation tab before exporting. Simulation checks the graph with controlled input. The final runner test checks that the real listener or device works on the target machine.
This low-risk workflow writes a timestamped message once per minute while the background service is running.
Target runtimes: select each Windows or Linux Desktop or Headless environment where the workflow will run
Nodes: Schedule, Log
Runner requirement: schedule triggers enabled and baudbound serve or the desktop background runner active
1 and Unit to Minutes.Scheduled run at {{system_time}}.The graph is:
Schedule -> Log
Scheduled run at followed by a time.baudbound serve in a terminal.Expected result: one successful run and one timestamped log message for each due interval. If nothing runs, check the Triggers and Service views and confirm that schedules are enabled in runner configuration.
Disable or remove the script when the recurring run is no longer needed. Stop baudbound serve with Ctrl+C if you started it in a terminal.
This workflow accepts a local HTTP POST, logs a value from its JSON body, and returns JSON to the caller.
Exposing a webhook beyond
127.0.0.1changes its security boundary. Keep this tutorial local. Do not bind to0.0.0.0without authentication, firewall, proxy, and request-limit planning.
Target runtime: any supported runtime
Nodes: Webhook, Log, Webhook Response
Runner requirement: webhook listener enabled on 127.0.0.1:43891
tutorial.30.json.message output into the Log Message field. The editor creates a reference containing that node's real ID, similar to {{NODE_ID.json.message}}.200, Content type to application/json, and Body to { "received": true }.The graph is:
Webhook -> Log -> Webhook Response
Do not type the literal placeholder NODE_ID. Use the variable browser so the reference points to the Webhook node in your project.
{ "message": "hello" }.hello and the response trace reports status 200.127.0.0.1 and port 43891.$token = "PASTE_TOKEN_HERE"
Invoke-RestMethod `
-Method Post `
-Uri "http://127.0.0.1:43891/events/tutorial" `
-Headers @{ "X-BaudBound-Token" = $token } `
-ContentType "application/json" `
-Body '{ "message": "hello" }'
TOKEN='PASTE_TOKEN_HERE'
curl --fail-with-body \
--request POST \
--header "X-BaudBound-Token: $TOKEN" \
--header 'Content-Type: application/json' \
--data '{ "message": "hello" }' \
http://127.0.0.1:43891/events/tutorial
Expected response:
{ "received": true }
Expected runner result: a successful run whose log contains hello. A 401 means the token header is missing. A 403 means the token is wrong. A 404 means no active route matches the method and hook name. A connection error usually means the listener is stopped, disabled, or using another address or port.
Disable the tutorial script and stop its background runner if it was started only for this test. Keep the webhook listener disabled in configuration when no installed script needs it.
This workflow receives text from a serial device and writes ack back to the same logical device.
Serial actions access physical hardware and require explicit approval. Confirm device identity, voltage level, baud rate, and protocol from the hardware documentation before sending data.
Target runtime: a Windows or Linux runtime supported by the connected device
Nodes: Serial Input, Log, Serial Write
Runner requirement: one serial mapping with logical device ID tutorial-device
tutorial-device.data output into the Log Message field.tutorial-device, data to ack, and line ending to the value required by the device. Use None when the protocol does not require LF or CRLF.Both serial nodes must use the same logical ID. A logical ID is not a Windows COM name or Linux /dev path.
ping as the Serial Input data.ping and Serial Write reports that it would send ack.Simulation does not open the physical port.
tutorial-device, and configure the native serial settings required by the device. New mappings use 9600 baud and Idle gap framing by default. Follow the device manual when it requires different values.Detailed identity and port-rebinding behavior is documented in Configuration and Serial Devices.
ping from the physical device.ping and the device receives ack.If the trigger remains inactive, open Doctor and inspect the serial reader state, active port, framing mode, buffered byte count, and latest error. The runner refuses ambiguous identity matches instead of guessing between similar devices.
Disable the script before disconnecting test hardware. Remove the tutorial-device mapping from Config when it is no longer used.
This workflow starts when a test file changes and logs the event and path.
Target runtime: any supported runtime with access to the chosen path
Nodes: File Watch, Log
Runner requirement: file-watch triggers enabled and the configured path present before the listener starts
Open PowerShell:
New-Item -ItemType Directory -Force "$HOME\baudbound-tutorial"
Set-Content "$HOME\baudbound-tutorial\input.txt" "initial"
Use the full path printed by:
(Resolve-Path "$HOME\baudbound-tutorial\input.txt").Path
Open a terminal:
mkdir -p "$HOME/baudbound-tutorial"
printf '%s\n' 'initial' > "$HOME/baudbound-tutorial/input.txt"
Use the full path printed by:
readlink -f "$HOME/baudbound-tutorial/input.txt"
~ or a runtime variable.event and path outputs into a message such as File event EVENT at PATH, using the variable browser for both values.modified event, then confirm both appear in the log message.Add-Content "$HOME\baudbound-tutorial\input.txt" "changed"
printf '%s\n' 'changed' >> "$HOME/baudbound-tutorial/input.txt"
Expected result: a successful run whose log reports the changed path and an event such as modified. Operating systems may report more than one low-level event for one application save.
Disable the script, stop the test service if needed, then run:
Remove-Item -Recurse -Force "$HOME\baudbound-tutorial"
Disable the script, stop the test service if needed, then run:
rm -rf "$HOME/baudbound-tutorial"
This workflow increments a persistent counter and logs a different message after the third run.
Target runtime: any supported runtime
Nodes: Manual, Variable Operation, If/Else, Log
Runner requirement: approval for persistent storage
run_count, Scope to Persistent, and Amount to 1.{{run_count}} greater than or equal 3.Run count reached {{run_count}}.Run count is {{run_count}}.The graph is:
Manual -> Variable Operation -> If / Else -> true -> Log reached
-> false -> Log count
Simulation confirms branch wiring and typed comparison, but do not use it as proof that production persistence is configured. Trigger it enough times to observe both branches in the current simulation session.
Then:
Expected result: the first two runs follow the false branch, and the third follows the true branch with a count of 3. Further runs continue increasing the stored value.
Removing or reinstalling a script may affect its stored state according to runner storage rules. Do not use a destructive cleanup command merely to reset one value on a production runner. Use this tutorial only in a test runner home until the storage and recovery documentation describes the intended operation for your release.