The Soba app stays running on a person's own laptop. A headless box installs the worker as a launchd or systemd service, and four things about that setup decide whether it is still working next month.
A machine that has to be woken by hand serves nothing. This page is about the step
after pairing: staying up.
On a person's own machine#
Nothing to do. Soba App keeps itself running as a login item
rather than a system service, which is the right shape for a laptop: it needs no
administrator, it runs as the person whose subscription it is, and it works on all
three platforms. It is also the only way to get a real approval dialog; see
Approvals.
On a headless box#
A VPS or an always-on machine in a cupboard has nobody to log in, so the app is the
wrong shape and the command-line worker installs itself as a service instead.
Terminal
soba-worker install
launchd on macOS, systemd on Linux. Windows has no service path: the honest
answer for a Windows machine is the app.
| Command |
|
soba-worker install |
Run in the background, and after reboot |
soba-worker uninstall |
Stop and remove it |
soba-worker service-status |
Is it installed, and is it up? |
soba-worker --status |
Runtimes and the service, in one report |
| Flag |
|
--system |
A system unit rather than a per-user one (Linux) |
Four things worth knowing#
No credential appears in a service definition#
A systemd unit is world-readable by design. So the pairing token stays in
~/.soba/worker.json (0600), and everything else (an endpoint's apiKeyEnv key,
a SOBA_* override) goes in ~/.soba/service.env (0600), which the worker loads
itself at startup. One mechanism on both platforms.
The exception is the handful of variables that decide where state lives
(SOBA_HOME and friends): those cannot come from a file whose own path they
determine, so they go in the definition. They are locations, not secrets.
Debugging a daemon
A variable in your real environment beats the saved one, so debugging does not mean
remembering that a file exists.
The recorded path is a stable one#
What gets written into the service definition is a fixed path to the installed binary,
never a path inside a package manager's cache. Caches get pruned, and a service
pointing into one works today and stops working weeks later with no visible cause.
The version is pinned too, so an unattended restart cannot swap the worker underneath
a machine nobody is watching.
A version-managed Node is flagged#
nvm, fnm, volta and asdf install per-version binaries, so .../v24.18.0/bin/node
stops existing the day you upgrade Node, and the service then fails at a moment
completely disconnected from the change that broke it.
install says so and carries on. Re-run it after a Node upgrade.
Linux user services stop at logout#
Unless lingering is enabled. install checks and tells you the command:
Terminal
sudo loginctl enable-linger $USER
On a VPS that is the moment you close the SSH session, which is exactly when an
"always-on" worker would go quiet.
Two workers, one token#
Do not run one. Two workers sharing a pairing token double the capacity Soba
believes the machine has, and runs land unpredictably between them. Installing the
service stands any foreground worker down rather than leaving both up, and Soba
App will not start a second worker beside one that is already serving.