Skip to content

[Proposal]: backlog service install subcommand for auto-start on boot #601

@brenoperucchi

Description

@brenoperucchi

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions