[gowtham472]

Two defects in the server target, and the roadmap section that says where the CLI goes next.

Fixed

Closing the terminal part way through a deployment left the app locked. deploy and rollback handled Ctrl+C by giving the release back: the new container removed and the server's deploy lock released. A closed terminal (SIGHUP), kill and a cancelled CI job (SIGTERM) ended the process where it stood, and the lock stayed until someone removed it by hand.

• interrupt.ts: one untilStopped both commands use. SIGINT, SIGHUP, SIGTERM, and SIGBREAK on Windows, abort the signal the release already watches.
• The listeners are attached before the release starts, so a stop that arrives while the lock is being taken is acted on once the release can be given back.
• After a stop, a failed write to a terminal that is gone is ignored rather than ending the process before the lock is released.

A remote build from Windows opened the server's Docker on a local port. Windows' OpenSSH cannot forward to a Unix socket, so the build used 127.0.0.1:<port> with nothing authenticating it. For the length of a build any local process could drive the server's Docker, which is root on the server, and so could a web page in a browser by rebinding a name to 127.0.0.1.

• docker-bridge.ts: nextship listens on a named pipe with a random name, and each connection the Docker client opens is carried by its own ssh ... docker system dial-stdio, under the pinned host key. No port is opened on either machine, and a browser cannot open a named pipe.
• A pipe Node creates takes Windows' default permissions, read from one on Windows 11: full control for the user who made it, SYSTEM and Administrators, read only for everyone else.
• The warning the old forward printed is removed, and so is ImageBuilder.warning, which nothing else set.
• Other platforms are unchanged: an SSH forward to a socket in a private directory.

server add could not start from Windows. Found by the live run below. The ssh-keyscan Windows ships cannot scan a current server: choose_kex: unsupported KEX method sntrup761x25519-sha512@openssh.com against Ubuntu 24.04. When the scan fails, the host key is now read by letting ssh record it, in one connection that offers no way to authenticate. It goes through the same printed fingerprint and --yes.

Docs

• docs/roadmap.md gains "Where the CLI goes next": machine-readable output, and more than one instance of an app. The fourth sequencing principle names the user the server target brought.
• docs/design.md §9.3, docs/vm.md, the README, the site's server page and the CHANGELOG describe the fixes and record the live runs.

How it was verified

• pnpm typecheck and pnpm test pass: 336 CLI tests, 0 failures.
• Live, on a Droplet (s-2vcpu-4gb, Ubuntu 24.04, blr1), 2026-10-09:
  • From Windows 11 with its own OpenSSH, no WSL: server add --yes in 61 s, a first deploy --yes in 127 s and a second in 73 s. The image was on the server (411 MB) and not on the Windows machine, no port warning was printed, streaming passed three runs of three (first byte 113 to 209 ms). The fingerprint server add printed matched the server's own. This is the first time --build remote has run from Windows.
  • A terminal closed mid-deployment, from Linux: an app made to take three minutes to start was deployed in a terminal of its own, closed once the lock was held. With 1.1.2 from npm the lock stayed, naming a dead process, with the new container left running. With this branch the lock was gone 25 s later, the new container removed, the previous one still answering 200. A normal deployment afterwards needed nothing removed by hand.
• Signals in a test: a real process holding a stand-in lock, sent SIGHUP, SIGTERM and SIGINT in turn on Linux, released it each time.
• Bridge in tests: on Windows (a named pipe) and Linux (a socket), and the real Docker client building through it against a local daemon.

Not yet verified

• Closing a console window on Windows part way through a deployment. Windows ends the process a few seconds after the window closes, and giving a release back takes two or three SSH logins. One attempt closed its window during the build, before any lock was taken, and showed nothing either way.

Conflicts to expect

This and pull requests 7 and 8 all add to the CHANGELOG's Unreleased section, and 7 also changes deploy.ts, vm-target.ts and target.ts. Whichever merges second needs a rebase.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	nextship	7d9ead4	Commit Preview URL Branch Preview URL	Oct 09 2026, 05:30 PM