RunBay is a local daemon plus desktop client for managing long-running scripts.
The project is split into two components:
daemon: Go HTTP daemon for task registry, process supervision, and log tailing.qt-client: Qt Widgets desktop client that talks to the daemon API.
The daemon listens on 127.0.0.1:8732 by default and exposes:
GET /api/healthGET /api/tasksPOST /api/tasksGET /api/tasks/{id}DELETE /api/tasks/{id}POST /api/tasks/{id}/startPOST /api/tasks/{id}/stopPOST /api/tasks/{id}/restartGET /api/tasks/{id}/logs?tail=500&after=123
Task definitions are persisted to a JSON file. Task logs are returned as ordered entries with monotonically increasing ids, so clients can request only entries after the last id they have rendered.
Daemon:
cd daemon
go run ./cmd/runbaydBy default, task definitions are saved in a machine-level location suitable for running the daemon as a system service:
%ProgramData%\RunBay\tasks.json
On Linux the default is /var/lib/runbayd/tasks.json; on macOS it is
/Library/Application Support/RunBayd/tasks.json. You can override the path
when running without service permissions:
go run ./cmd/runbayd -data .\runbay-tasks.jsonQt client:
cd qt-client
cmake -S . -B build\Debug -DCMAKE_BUILD_TYPE=Debug
cmake --build build\Debug --config Debug
.\build\Debug\bin\runbay-client.exeIf Qt is installed but cmake or Qt tools are not in PATH, open qt-client
with Qt Creator and select your installed Qt 6 kit.
On macOS, package the Qt client as a native app bundle with the daemon embedded
in Contents/MacOS:
brew install go cmake qtbase yaml-cpp
./scripts/package-macos.sh
open ./dist/Release/RunBay.appThe packaging script runs macdeployqt, performs an ad-hoc signature, and
writes the self-contained app to dist/Release/RunBay.app. It packages the
native architecture by default. A universal package can be requested when the
Qt installation contains both slices:
./scripts/package-macos.sh --architectures 'arm64;x86_64' --qt-prefix /path/to/universal/QtInstall the third-party create-dmg tool and create a styled DMG containing
the app and an Applications shortcut with:
brew install create-dmg
./scripts/create-macos-dmg.sh \
--app ./dist/Release/RunBay.app \
--output ./dist/RunBay-macos-Release.dmgThe DMG uses the 660×400 background and icon layout under packaging/macos.
The GitHub Actions workflow installs create-dmg with Homebrew and uses the
same script and assets as local packaging.
macOS uses launchd as the equivalent of the Windows Service Control Manager.
RunBay uses a system LaunchDaemon, rather than a per-user LaunchAgent, so
the daemon starts during boot and does not require a logged-in user. Open
Service -> Manage Services... in the desktop app to:
- add a service and select a local macOS user;
- register or unregister it through the standard administrator authorization prompt;
- start and stop it from the UI;
- inspect its current launchd state.
Tasks spawned by the daemon run as the selected service user. The app creates that user's data and log directories during registration. The command-line installer remains available for a default root-owned service:
sudo ./dist/Release/install-launchdaemon.shThe generated LaunchDaemon directly runs
RunBay.app/Contents/MacOS/runbayd; it does not copy the daemon to a separate
system directory. UI-created launchd labels use
com.runbay.daemon.<service-id>. The minimal generated plist contains the app's
daemon path, selected user, boot policy, and a pointer to service.json;
listen address, data file, and log directory are stored in that
platform-neutral JSON configuration instead of the plist.
To uninstall the boot service while retaining task data and logs:
sudo ./dist/Release/uninstall-launchdaemon.shThe default root service stores task data under
/Library/Application Support/RunBayd and logs under /Library/Logs/RunBayd.
Services running as normal users default to that user's
~/Library/Application Support/RunBayd directory. Because launchd directly
references the registered app bundle, moving or deleting RunBay.app requires
unregistering and registering the service again from the app's new location.
Both Windows SCM registration and macOS launchd registration start the daemon
with runbayd -service-config <path>. The referenced JSON is the authoritative
runtime configuration:
{
"version": 1,
"service_id": "runbay-0123456789ab",
"name": "RunBay",
"listen_address": "127.0.0.1:8732",
"data_file": "/path/to/RunBayd/tasks.json",
"log_directory": "/path/to/RunBayd/logs",
"user": "service-user"
}Platform service definitions retain only values required by the operating
system, such as the Windows service account or launchd's UserName and label.
The configuration schema is strict and versioned; unknown fields and unsupported
versions are rejected.
Helper scripts:
.\scripts\build-daemon.ps1
.\scripts\build-qt.ps1 -QtPrefix C:\Qt\6.8.3\msvc2022_64
.\scripts\build-all.ps1 -QtPrefix C:\Qt\6.8.3\msvc2022_64
.\scripts\build-all.ps1 -C Release -QtPrefix C:\Qt\6.8.3\msvc2022_64
.\scripts\package-windows.ps1 -C Release -QtPrefix C:\Qt\6.8.3\msvc2022_64
.\scripts\package-windows.ps1 -C Release -T Client -QtPrefix C:\Qt\6.8.3\msvc2022_64
.\scripts\package-windows.ps1 -C Release -T DaemonBuild outputs are separated by configuration:
- daemon:
daemon\bin\Debug\runbayd.exeordaemon\bin\Release\runbayd.exe - Qt client:
qt-client\build\Debug\bin\runbay-client.exeorqt-client\build\Release\bin\runbay-client.exe
Windows packages are written to dist\<Configuration>. By default,
package-windows.ps1 packages both runbayd.exe and runbay-client.exe; pass
-T Client or -T Daemon to package only one side. The shorthand -T is an
alias for -Target. Partial packaging updates the existing output directory in
place, while the default -T All cleans the output directory unless -NoClean
is passed.
The client package includes Qt DLL/plugin dependencies copied by windeployqt.
The package script skips Qt translations, software OpenGL, the system D3D
compiler payload, and the MSVC runtime installer to keep the Windows package
smaller. Pass -IncludeCompilerRuntime if you want
windeployqt --compiler-runtime.
Register, start, stop, and remove Windows services from the Qt client's Service menu. The Windows package does not include separate service management scripts.
When installed as the RunBay Windows service, runbayd.exe uses the native
Windows Service Control Manager protocol and reads the same service.json
format used on macOS. The Qt client checks /api/health
and shows service state in the status bar, including whether the service is
installed, running, and configured for automatic startup. It does not install
or start the service automatically; use the Service menu to install, start,
stop, or delete it.
When registering a service to run as a normal Windows user account, configure the account before starting the service:
- Open
secpol.mscfrom the Run dialog or Start menu. - Go to
Local Policies->User Rights Assignment. - Open
Log on as a service. - Add the service account, for example
.\usernameorCOMPUTERNAME\username. - Make sure the account can read and write the selected RunBay data directory.
- Register and start the service from the Qt client's Service menu.
Windows Home may not include secpol.msc. In domain-managed environments, Group
Policy can overwrite this local setting; ask the domain administrator to grant
Log on as a service to the account if the setting does not persist.
Daemon and task log files are written under %ProgramData%\RunBay\logs on
Windows. Logs are grouped by date folder and old folders are pruned daily, with
the latest seven days retained.
The Build workflow is the single CI entry point. It runs on every branch push
and can also be started manually from the Actions tab, then calls the reusable
Package Windows and Package macOS workflows in parallel. Windows builds the
Release daemon and Qt client on windows-latest, then uploads
RunBay-windows-Release.zip. macOS builds both binaries on macos-26, embeds
the daemon and Qt frameworks in RunBay.app, creates
RunBay-macos-Release.dmg, verifies it, and uploads the DMG as the
RunBay-macos-Release artifact.
VS Code:
- Install the Go extension for
RunBay: Debug daemon (Go). - Install the C/C++ extension for Qt client debugging.
- If Qt is not discoverable automatically, set
runbay.qtPrefixin.vscode/settings.jsonto your Qt kit path, for exampleC:\Qt\6.8.3\msvc2022_64. - Use
RunBay: Debug Qt client (MSVC)for MSVC kits orRunBay: Debug Qt client (MinGW)for MinGW kits.