[marcellosso]

Prepares v0.5.0, Machines over SSH: another computer's Projects in the same window, reached through the system's ssh (#67), with docs, a guide and a landing section (#70). Closes #73.

Important

Merging this PR does not release anything. release.yml runs only on a v* tag push or when a release is published. Do not merge, tag or publish without Marcel's ok.

What changed

One line: site/src/content/changelog/0.5.0.md now says released: true. The date (2026-11-05) and bullets stay as they are. I checked the bullets against #67/#70: Settings → Machines, the ~/.ssh/config host suggestions, Forwards bound to loopback with PortConflict, typed MachineProblem wording, reconnecting (on wake on macOS only: NSWorkspace.didWakeNotification), the quit prompt, the incompatible shared core message and the stacked empty state. They are accurate, so I didn't reword them.

No version numbers were bumped. Connected · localhost 0.5.0 in site/src/content/docs/machines.md already matches. The localhost 0.4.0 is still running example on that page is meant to name an older version, so it stays as it is.

⚠️ One decision: the released flip

Since 8b3a566, site/src/lib/changelog.ts treats an entry as released when GitHub's latest published release is at or past its version. It uses entry.data.released || published. That is why 0.3.0.md and 0.4.0.md still say released: false even though both are published: that is intended, so I left them alone.

So the flip isn't needed. It also has a side effect: a push to main deploys the site to production on Vercel. If this PR is merged before v0.5.0 is published, the changelog shows v0.5.0 as released while the download links still point to 0.4.0. I confirmed this with a local build: dist/changelog.html shows v0.5.0. You can choose either option:

• drop this commit and follow the 0.3.0/0.4.0 convention: publishing the release marks it released through the deploy hook; or
• keep it and merge only after the release is published.

How releases work (evidence)

1. Where the version comes from: the tag, and nothing else. RELEASING.md › Versions: "The tag is the only place the version lives: v0.3.1 builds version 0.3.1 … MARKETING_VERSION in the Xcode project and version in apps/desktop/src-tauri/tauri.conf.json are only what local builds say. The bundled localhost command gets it through LOCALHOST_VERSION at build time." In release.yml, the version job sets version=${GITHUB_REF_NAME#v} and rejects anything that isn't X.Y.Z. The macOS job passes it to scripts/build-release.sh. The Linux and Windows jobs inject it with tauri build --config '{version: …}' and LOCALHOST_VERSION, and check that localhost --version reports it.
2. What starts a build: a v* tag push only. release.yml runs on: push: tags: ["v*"] and release: types: [published]. The second trigger only writes the Homebrew cask. There is no push: branches, so merging to main does not run it. The v0.3.0/v0.4.0 releases were built by tags pushed after their merges.
3. Why tauri.conf.json says 0.1.0 and server.json says 0.2.0 while GitHub is at 0.4.0:
   • tauri.conf.json, apps/desktop/package.json, the Cargo workspace (core/Cargo.toml, src-tauri/Cargo.toml) and Xcode MARKETING_VERSION stay at 0.1.0 on purpose. The release overrides each of them, and they only label local builds.
   • server.json and packages/cli/package.json are a separate product: the npm package @getlocalhost/cli and its MCP Registry entry. They have their own SemVer line and are published by hand (publish-cli.yml). packages/cli/test/server-json.test.js keeps them in lockstep with each other, not with the app.
   • Don't "fix" these numbers. It changes no shipped artifact, and bumping the CLI would require a new npm and Registry publish.
4. Merging this PR does not start a release. On merge: CI and the Site workflow run on main (site.yml: push: branches: [main]), and Vercel deploys the site to production (ignore-build.sh always builds production). release.yml does not run, and nothing is tagged, built, drafted or published.

CLI / server.json: kept at 0.2.0

git diff v0.4.0 origin/main -- packages/cli is empty. Machines/SSH is a core and app feature. @getlocalhost/cli mcp serve launches the app's bundled localhost mcp, so users get the new core with the app and need no new npm version. The only change since v0.4.0 is in server.json: an icons entry (553eb88), which is Registry metadata only. If the Registry should show that icon, it needs a CLI 0.2.1 and a Registry publish. That is separate from this release and your call.

Checks

• cd site && pnpm install --frozen-lockfile && pnpm build: 36 pages built, no errors
• cd packages/cli && npm test: 53 passed, 0 failed
• No Rust, Swift or desktop code changed, so those suites didn't run.

After merge, in order (Marcel)

1. Confirm CI is green on main.
2. Run Linux packages on the release commit and watch it:

   gh workflow run packages.yml -R marcellosso/localhost --ref main
   gh run watch -R marcellosso/localhost "$(gh run list -R marcellosso/localhost --workflow packages.yml --limit 1 --json databaseId -q '.[0].databaseId')"

3. Tag the release:

   git switch main && git pull
   git tag -a v0.5.0 -m "localhost 0.5.0" && git push origin v0.5.0

4. Wait for the Release workflow to finish. It drafts "localhost 0.5.0".
5. Smoke-test the DMG, the .deb/.rpm/AppImage and the Windows installer with WSL, per RELEASING.md step 5. Then Publish release.
6. Publishing triggers two things:
   • the Homebrew cask update job (marcellosso/homebrew-tap);
   • the Site deploy hook. Changelog 0.5.0 then shows as released whether or not this commit is in.
7. npm and the MCP Registry: nothing to do, because the CLI isn't bumped.

Related: #67 (Machines), #70 (Machines docs), #71 (README badge), tracking #73.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
localhost-web	Ready	Preview	Nov 5, 2026 9:41pm UTC