The server target's next phase: hardening, open tabs across deploys, instant rollback, previews, HTTPS on the address

[Ragul2105]

The server target's next phase, in the order docs/roadmap.md records, each shipped and verified on its own.

What changes

• Hardened app containers. Read-only root filesystem, a 64 MB noexec /tmp, no capabilities, no-new-privileges, 512 processes. The December 2025 break-ins through CVE-2025-55182 rewrote next.config.js and ran miners from /tmp; none of that can persist now. Behaviour change: an app that writes outside .next fails with EROFS (documented).
• Cache guard. A timer keeps what each app writes at runtime under 10% of the disk (at least 1 GiB), least recently used first, never deleting a file the build produced.
• Open tabs keep working across a deployment. The replaced deployment keeps running for an hour, and Caddy sends it every request that names its build (x-deployment-id, ?dpl=). This sidesteps Server Action responses bypass deploymentId version skew detection, crashing stale tabs with "module factory is not available" vercel/next.js#99165. A retire timer stops it afterwards.
• Instant rollback to that deployment: a Caddy switch to the running container, about 210 to 240 ms.
• Previews. --preview <name> deploys and manages a second app on the same server, found again from the server record so CI needs only the committed nextship.json, with noindex and its own env. A workflow for one preview per pull request is in docs/vm.md §6.
• HTTPS on the server's address. On a public IPv4 server, the first app also answers https://<address> with Let's Encrypt's six-day IP certificate.
• Faster switch. The health wait went from 4.1 s to 1.1 s; a warm deploy is now about 13.5 s, most of it next build.
• doctor prints crontab lines for vercel.json crons, and a next.config snippet for the routes that carry over unchanged.
• Nightly compatibility suite on the newest canary, published to an evidence branch that the evidence page reads.
• macOS: the prune tests pass there now, and CI runs macOS.
• Recorded as not built: promoting one build to another environment (a spike showed Turbopack folds placeholder values), and stripping x-middleware-subrequest (no supported Next.js version is affected).

How it was verified

• conformance/vm/e2e.sh passes 25 of 25 on a local Ubuntu 24.04 stand-in, with new checks for hardening, the cache guard, skew routing, instant rollback, retire and previews.
• The cache guard was run on a 12 GB-disk stand-in, including evicting a live page and image.
• HTTPS on the address was verified against Pebble.
• Unit tests pass on Linux (347 of 348, 1 skipped) and macOS; the conformance tests and the site build pass.

Not yet verified (needs GitHub or a real server)

• The nightly publish job: runs only after this reaches main.
• The preview-per-pull-request workflow in docs/vm.md §6: never run in GitHub Actions.
• HTTPS on the address against Let's Encrypt itself, on a server with a public IPv4 address.
• Existing servers need nextship server add again for setup version 3 (cache guard and retire timers). server status says so.

🤖 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	543f4cf	Commit Preview URL Branch Preview URL	Oct 10 2026, 06:51 PM

[gowtham472]

Thanks for this, Ragul. The design is clear, the tests are real (25 of 25 in e2e.sh, CI green on Linux, Windows and macOS), and the "not yet verified" list is honest. Not ready to merge yet: keeping the previous container running adds a timer, a second container and a second file, and most of what follows is where those meet.

This is from reading the whole diff, not from running it on a server, so each item needs confirming, the Caddy one above all.

Must fix before merging

1. A server set up by 1.1.x keeps the previous container for good. vm-target.ts (the kept filter after recordLive). Deploy now leaves the replaced container running and relies on the retire timer, but a setup version 2 server has no timer, and deploy neither refuses nor warns: only server status mentions the old setup. The container runs with its full memory limit until the next deployment, and the @previous route stays. Deploy should refuse, or keep nothing, until server add has run again.

2. The retire timer can stop the live container. retire.sh, the docker stop. It stops whatever previous names once the time has passed, and never checks that the container is not the one Caddy serves. writeDeployments writes deployments.json and previous as two separate commands, and rollbackInstantly switches Caddy before either. A rollback near the hour, or a CLI that dies between the switch and the second write, leaves previous naming the container that is now live, and the timer stops it. --restart unless-stopped does not bring back a stopped container.

3. rollbackInstantly checks before it takes the lock. It reads the history and inspects the container, then locks, and does not check again. A deploy that goes live in between stops that container (it is no longer the kept one), and the rollback then points Caddy at it.

4. https://<address> may make plain HTTP redirect before a certificate exists. caddy.ts, the https://${options.ipCertificate} block. Caddy's automatic HTTPS adds an HTTP redirect for a host it manages a certificate for, and a host-specific redirect can win over the catch-all http://:80 site. If Let's Encrypt is slow or cannot issue (443 closed upstream, a rate limit), the only address a first deploy printed would redirect to a URL with no valid certificate. Pebble always issues, so the test cannot show this. Please check the rendered site with caddy adapt, and run once with issuance failing.

5. Destroying an app orphans its previews. destroyApp removes the named app only, and the plan does not mention previews. Afterwards nextship.json has no appId, so --preview <name> can never match previewOf again, and the previews keep running with their volumes and domains.

Should fix, or decide

6. The read-only root has no way out, and deploy cannot see the failure. An app that writes a SQLite file or uploads under its working directory deploys, passes the health check on a prerendered route, and then fails with EROFS on its first write. Either a declared writable path, or a check that warns at deploy time.

7. The memory limit does not count the kept container or previews. memoryLimit still divides 80% of RAM by the number of apps. One app on a 2 GB server gets 1600m, and for an hour two containers are each allowed that. Previews are full apps, and containers already running keep the larger share.

8. The docs describe HTTPS on the address as working. README and site/content/docs/vm.mdx say the first app answers https://<address>, while this pull request lists that as not yet run against Let's Encrypt. AGENTS.md §5: "Never claim a capability in docs or output that has not been observed working on a real target." Either run it on a public server first, or move the claim to the roadmap until then.

Minor

9. Cache eviction order depends on access times. cache-guard.sh sorts by %A@. Under relatime that changes at most once a day, and under noatime never, so the guard would evict by age, the hottest entries included.

10. A long app name with a preview name gives the wrong error. previewAppName can pass 63 characters, and the refusal that follows tells the user to rename the app.

Happy to look again once 1 to 5 are in. After the merge, the plan is a live run on a Droplet (the upgrade from a 1.1.2 server included), then 1.2.0, since the read-only filesystem changes behaviour.

[Ragul2105]

Thanks for the review, Gowtham. All ten points are addressed, and main (1.1.3) is merged in, so the conflicts are gone. e2e.sh passes 28 of 28 on a local Ubuntu 24.04 stand-in; unit tests pass on Linux (384 of 385, one skipped) and macOS.

Must fix

1. Servers set up by 1.1.x. A deployment reads the server's setup version. Below 3 it keeps nothing, stops the replaced container as 1.1.x did, writes no @previous route, and says to run server add again. Chosen over refusing so CI keeps deploying after a CLI upgrade. e2e marks the server as version 2, deploys, and checks one container runs and the site has no @previous.
2. The timer stopping the live container. Three layers: previous is emptied before Caddy is pointed anywhere; the history and previous are written in one remote command, each to a temporary file moved into place; and retire.sh stops nothing the Caddy site names on a new # live <container> line (or when that line is missing). e2e writes the live container into previous with its time up, runs the timer, and checks it refused and logged it.
3. Lock order in the instant rollback. It takes the lock first, then reads the history and inspects the container. A kept container that is no longer healthy falls back to starting its image.
4. The HTTP redirect. You were right. With a CA that could not be reached, http://<address> answered 308 to an address with no certificate. The site now names both http://<address> and https://<address>, which makes Caddy serve HTTP rather than redirect. Re-verified against Pebble in two phases: with Pebble down, HTTP on the address answered 200 with no redirect; with Pebble then started, Caddy's retry got the certificate within 60 s and both schemes answered 200. Still not run against Let's Encrypt.
5. Orphaned previews. destroy names each preview of the app in its plan and destroys them first, images included. e2e deploys a preview, destroys the app, and checks no container, app record or volume is left.

Should fix

6. Read-only root. Both halves: "writable": ["data"] in nextship.json gives a volume per folder, per app, that outlives a deployment (validated: relative, no leading dot, not under node_modules, no nesting), and doctor warns when the source looks like it writes files and none is declared. destroy says it deletes that data and server move says it does not copy it. e2e writes a note from the first build and reads it from the second.
7. Memory limit. Where the server keeps a replaced deployment, each app counts as two containers in the 80% share: one app on 2 GB gets 800m, not 1600m twice. Previews were already counted as apps. This lowers the default; --memory still overrides, and the plan shows the figure. Say if you would rather shrink only the kept container.
8. Docs. The README and the site no longer describe HTTPS on the address. design.md keeps the record as "built, not yet run against Let's Encrypt", and the roadmap holds it until a run on a public address.

Minor

9. Eviction order. Sorted by the later of last access and last write, so noatime evicts oldest written first.
10. Long names. previewAppName refuses a name over 63 characters with the length the preview name may be.

Found along the way

• My first fix for 2 wrote a lone newline when nothing was kept, which the timer would have logged as unreadable every minute. Fixed in the same commit.
• The hardening check in e2e.sh now allows the mount point Docker creates for a declared writable folder (A /src/data and its parent), and nothing else.

Still open, for the Droplet run

• The upgrade from a real 1.1.2 server.
• HTTPS on the address against Let's Encrypt itself.
• The nightly publish job and the preview workflow, which only run on GitHub.

Commits: 60d3c62 (9), f58c2b3 (5, 10), 543f4cf (1 to 4, 6 to 8).