Problem
backlog browser --no-open is already the correct primitive for running the Web UI as a long-lived background service, but users have to hand-write the platform-specific unit file (systemd on Linux/WSL2, launchd on macOS, NSSM/Scheduled Task on Windows). PR #600 documents those recipes in the README, which covers the common case.
For users who want a friction-free path — "I just ran backlog init, now I want this to survive reboots" — a first-class CLI command would be nicer than copying a snippet.
Proposed solution
A small backlog service command group that generates and registers the platform's native auto-start file:
backlog service install [--port 6420] [--user|--system] [--working-dir <path>]
backlog service uninstall
backlog service status
Platform mapping
- Linux / WSL2 — write
~/.config/systemd/user/backlog-browser.service and run systemctl --user daemon-reload && systemctl --user enable --now backlog-browser; optionally remind about loginctl enable-linger.
- macOS — write
~/Library/LaunchAgents/md.backlog.browser.plist and launchctl load -w it.
- Windows — register a Scheduled Task via
schtasks (simpler path) or emit instructions for NSSM (more robust path) if NSSM is on PATH.
The command would wrap the exact same backlog browser --no-open --port <port> invocation as the docs, so no new runtime behavior is introduced — just file generation and registration.
Why this is worth the API surface
- Removes a ~60-line copy/paste from the README per OS.
- Keeps the "zero-config CLI" promise alive for the service use case — today the docs lean on systemd vocabulary that new users don't want to learn.
- Uninstall is the real win:
backlog service uninstall can confidently remove a file it knows it owns, instead of users guessing where they put the unit.
Counter-argument (aware of AGENTS.md simplicity-first rules)
So this is genuinely a judgement call on whether the ergonomics are worth the maintenance surface. Opening the issue to see if there's maintainer appetite before investing in implementation.
If accepted
I'd be happy to send a PR starting with Linux systemd-user only (the most common and lowest-risk path), then add launchd and Windows in follow-ups once the shape is agreed.
Related
Problem
backlog browser --no-openis already the correct primitive for running the Web UI as a long-lived background service, but users have to hand-write the platform-specific unit file (systemd on Linux/WSL2, launchd on macOS, NSSM/Scheduled Task on Windows). PR #600 documents those recipes in the README, which covers the common case.For users who want a friction-free path — "I just ran
backlog init, now I want this to survive reboots" — a first-class CLI command would be nicer than copying a snippet.Proposed solution
A small
backlog servicecommand group that generates and registers the platform's native auto-start file:Platform mapping
~/.config/systemd/user/backlog-browser.serviceand runsystemctl --user daemon-reload && systemctl --user enable --now backlog-browser; optionally remind aboutloginctl enable-linger.~/Library/LaunchAgents/md.backlog.browser.plistandlaunchctl load -wit.schtasks(simpler path) or emit instructions for NSSM (more robust path) if NSSM is on PATH.The command would wrap the exact same
backlog browser --no-open --port <port>invocation as the docs, so no new runtime behavior is introduced — just file generation and registration.Why this is worth the API surface
backlog service uninstallcan confidently remove a file it knows it owns, instead of users guessing where they put the unit.Counter-argument (aware of AGENTS.md simplicity-first rules)
--uservs--system) adds real code.So this is genuinely a judgement call on whether the ergonomics are worth the maintenance surface. Opening the issue to see if there's maintainer appetite before investing in implementation.
If accepted
I'd be happy to send a PR starting with Linux systemd-user only (the most common and lowest-risk path), then add launchd and Windows in follow-ups once the shape is agreed.
Related