Push install

What it does

The first time you add a host, the remote has no blueprint-svc binary. Push install fixes that without making you SSH in and run commands by hand.

The flow:

1. Blueprint reads the embedded blueprint-svc-linux binary from inside the desktop app (it's go:embed'd into the desktop binary at build time).
2. Over SSH/SFTP, copies that binary to the remote at ~/.blueprint/blueprint-svc.
3. Writes a small systemd unit file to ~/.config/systemd/user/blueprint-svc.service (user-level — no sudo required on most distros).
4. Enables + starts the service via systemctl --user.
5. Confirms the service is running by reading the bearer token at ~/.blueprint/svc-token and probing /v1/health through the SSH tunnel.

You never type anything on the remote. The whole flow is one button.

When to use it

Always, on every new host. Push install is the supported way to provision the svc.

The alternative (manually SCP the binary + configure systemd yourself) works but isn't tested by us; the embedded binary version will drift from what you compiled by hand, leading to subtle incompatibilities.

Re-push to upgrade

When you upgrade Blueprint on the desktop and a new blueprint-svc-linux ships with it, the hosts you previously push-installed still have the old version. The Push install button is idempotent — clicking it again upgrades the remote binary, restarts the service, and the host is current.

Tip: Push install before every release to a host you care about so the desktop + svc versions match. Drift between desktop and svc versions occasionally causes IPC field mismatches that show as "unknown field" warnings in the log.

How to run

1. Hosts → click a host → Push install.
2. The button shows progress through each step: copy binary, write unit, enable service, start service, probe.
3. On success, the host's status flips to "ready to connect."
4. Click Connect to drive it.

Common pitfalls

• systemctl --user requires lingering enabled: on some distros user services stop when you log out. The unit file Blueprint writes enables lingering automatically (loginctl enable-linger); on systems that don't support that, the user must add it manually with sudo loginctl enable-linger <user>.
• AppArmor / SELinux blocking the binary: hardened distros may flag the freshly-installed binary as unsigned. Add an exception or install to a directory that's already on the policy's allow list.
• GLIBC mismatch: the embedded binary is built against a reasonably recent glibc. Very old distros (Ubuntu 18.04 and older) may fail with GLIBC_2.32 not found. Upgrade the distro or build the svc binary from source against the target's glibc.
• Host is already running blueprint-svc as a system service: if someone previously installed it with sudo systemctl enable, the user-level service we install will conflict on the port. Stop the system one before push-installing.