Proposal: opt-in auto-start for `devspace serve` on login

[RoiexLee]

Summary

docs/setup.md describes the intended runtime shape as: start your tunnel, run devspace serve, connect the host. On desktop machines this leaves devspace serve as the only manually-started piece of the chain — after a reboot, users who already run their tunnel as a background service still have to open a terminal and start the MCP server before ChatGPT can use it.

Problem

• On Windows, devspace serve runs in a console that must stay open; every reboot/login repeats the step.
• The failure mode is silent for non-technical users of the host machine: the tunnel is up, the MCP URL is configured, and ChatGPT reports the connector is unreachable.
• Everything else in the documented chain is already durable across reboots except the server process.

Verified workaround (Windows, no code changes)

This is what I run today; it works reliably and needs no DevSpace changes:

schtasks /Create /TN "DevSpace" /SC ONLOGON /RU <user> /NP /DELAY 0000:30 /TR "cmd.exe /c cd /d C:\Users\<user> && C:\Users\<user>\AppData\Roaming\npm\devspace.cmd serve >> C:\Users\<user>\.devspace\auto.log 2>&1" /F

• /NP (S4U) runs the task in the background session: no console window, survives lock/logout, no stored password.
• Output lands in auto.log, which is the only practical way to debug a hidden server process.
• Tunnel side is covered by ngrok service install; startup order between tunnel and server does not matter, requests simply 502 until both are up.

So to be clear: users can already solve this. The question is whether DevSpace wants to own a supported path instead of leaving it to per-OS folklore.

Options considered

Deliberately listed smallest-first; happy to drop any of them.

1. Documented recipes only (no code): a short docs/auto-start.md with the systemd user unit, launchd plist, and the schtasks command above. Zero maintenance surface, aligns with how the tunnel is already documented.

2. devspace service install / uninstall / status (smallest code change that makes it a first-class command):

• Linux: systemd user unit (WantedBy=default.target), ExecStart resolved from the installed CLI, logs to journald
• macOS: launchd agent plist (RunAtLoad), logs to a file
• Windows: register the same schtasks task (S4U, logon trigger, log file)
• uninstall/status round it out. No new process model: it is still the same serve process, just launched by the OS at login.

3. Daemonize serve itself (agentd-style supervisor + IPC). Listed for completeness; it is the largest change, overlaps with the existing daemon work, and expands the runtime surface the project keeps deliberately tight.

Security considerations

No change to the security model in any option:

• serve still binds 127.0.0.1:7676; the public exposure path remains the user's own tunnel, unchanged
• Owner password, workspace allowlist, and OAuth behavior are untouched
• The feature is opt-in only, per-user (never a SYSTEM/root service), and writes nothing outside the user profile
• A documented auto-start arguably reduces a real-world risk: people hand-rolling worse hacks (e.g. running serve elevated, or from Startup-folder batch files with visible consoles) instead

What I'm asking

• Is this in scope at all for the project right now?
• If yes: which option (or which slice of option 2, e.g. one platform first)?