Evidence

Everything below was produced by running something, not by reading code. Each row says where it came from, so you can disagree with the method rather than with the number. The last section is the honest list of what has not been proven.

The adapter compatibility suite#

The official Next.js adapter test suite is the arbiter of whether an adapter works. It builds a real container per test file and deploys it.

1.0.1's run passed 1051 of 1115 suites. Researching all 64 failures found most in our test harness rather than in nextship: the Docker build never received the variables a test sets or the flags Next.js's own deploy path passes, packages fixtures commit under node_modules were deleted before the build, and the container sat behind a remapped port. Two were real nextship defects, both fixed: a Next.js build cache shared between projects, and route module contexts missing from the image. The nine skipped tests, and why each cannot pass off Vercel, are in the results.

A full run now takes 319 runner-minutes against 788, in the same 32 groups.

The suite runs from GitHub Actions in this repository every night against the newest Next.js canary, and on demand, so a change in Next.js that breaks self-hosting shows up the day it lands rather than when it reaches a release. The table above is the result recorded for a release. The nightly one is below, read from the repository when you open this page:

Reading last night's result…

Streaming#

A buffering proxy leaves Suspense and partial prerendering apparently working while delivering none of the benefit: the page arrives complete, at the end. So streaming is a test rather than an assumption. A fixture renders its shell at once and its tail two seconds later, and the check fails unless the shell arrives first.

The live run passed three times out of three, sent chunked through DigitalOcean's Cloudflare edge with the cache bypassed.

The check is also known to fail when it should: it was run against a server that buffers, one that never answers, and one that drops the connection part way, and it reported each.

Edge runtime#

A route handler and a page declaring runtime = 'edge' both served from a nextship image, and the code in each saw the EdgeRuntime global and no Node.js version: Next.js runs it in its Edge runtime inside the server, not on the Node.js runtime. Measured on 2026-09-13 with nextship 1.0.0 and Next.js 16.3.4 in a local container, and checked on every push since, because the prune that builds the image could otherwise drop the Edge bundles without any other test noticing.

The runtime image#

Measured on a production project: Next.js 16.2.9, pnpm, 21 routes, next/image in 21 files.

@next/swc, 125 MB of compiler that no production server calls, is absent. Of the 591 MB that remain, 332 MB is the node:24-slim base image, which a node pulls once and shares across deployments.

Alpine was measured rather than assumed, and rejected: it saves 97 MB, and sharp resizes take 91.8 ms on it against 37.1 ms on slim, a median of 15 runs on identical libvips.

Against a live account#

Every day two command was verified against a real DigitalOcean account rather than a fixture:

• Deploy and rollback, including two rollbacks in opposite directions.
• Custom domains: certificate issued by Google Trust Services, TLS 1.3 negotiated, TLS 1.1 refused, plain HTTP redirected, every route 200.
• Image retention: a prune took the registry from 390.2 MiB to 286.1 MiB, freeing 104.2 MiB.
• Runtime logs, both the snapshot and --follow.
• Destroy, which refuses unless you name the app.

Before 1.1.0 was tagged, the same commands ran again against a throwaway app built with the release's code: deploy, a second deploy, rollback with no build or push, logs and logs --follow, env push read by the running app about a minute later, domain and images. The app and its registry were removed afterwards.

Your own server#

The server target, new in 1.1.0, ran on DigitalOcean Droplets between 2026-09-20 and 2026-09-23 (s-1vcpu-2gb-70gb, amd64, Ubuntu 24.04), after a local test server and a Proxmox VM. Ragul D ran these, apart from the last two rows, which Gowtham ran on 2026-09-24 while recording the README's demo and testing the fix.

Compared with Coolify#

Coolify is the tool most often suggested for self-hosting Next.js, so we deployed the same app with both, on 2026-09-26: two identical Droplets (s-2vcpu-4gb, 2 vCPU and 4 GB, Ubuntu 24.04, blr1), one running Coolify 4.3.23 with its own installer and deploying to itself, the other set up by nextship 1.1.2 with server add. The app was the streaming fixture in conformance/streaming/app, Next.js 16.3.4, from the same commit. Gowtham ran both. Every Coolify setting stayed at its default unless a row says otherwise.

How to read it:

• The health check is what separates the redeploy rows. Coolify leaves it off by default; with it on, one request failed in 1008, in a single run that cannot tell a failure during the container switch from one on the network between us and the Droplet. nextship always waits for the new container to pass before Caddy switches.
• The redeploys were not identical. nextship's rebuilt the app after a change; Coolify's reused its image, because a redeploy of an unchanged commit skips the build.
• The app had no start script, since nextship runs Next.js's server itself. Coolify's default build pack needs one, so its first deploy started an empty shell: we set the start command to npx next start -p 3000 and forced a rebuild. An app made with create-next-app has the script and would not hit this.
• One small app, one run of each. Image size and memory will differ for your app; the difference in what each tool runs beside it will not change much.
• Coolify does far more: a dashboard, databases, any kind of app, many servers. This compares one thing, deploying a Next.js app to one server, and nothing else.

An end-to-end test on macOS#

On 2026-09-11 we installed nextship 0.4.4 from npm on a MacBook Pro with an M3 Max, deployed a Next.js 16.3.4 app to App Platform, and measured it against the live URL. The app was built to be awkward: a streaming Suspense boundary, an ISR route, a Server Action, next/image on a raster source, a route reading a runtime environment variable, and a dynamic homepage.

The first deploy failed. Its dynamic homepage made nextship choose /_global-error as the health check path, which answers 500, and the deployment never went live. 1.0.1 fixes it; the second and third deploys went live. The test found eight things in all, and 1.0.1 fixes, pins with a test, or documents every one, as the changelog records.

Supply chain#

• Published with provenance, so the bytes on npm are linked to this repository and the exact commit that produced them, and anyone can verify it.
• Every release is staged and then approved with two factor authentication, which no workflow can do. A compromised workflow can stage a release; it cannot ship one.
• No npm token exists, in the repository or on a laptop.

What the CLI can reach#

• One outbound destination per target: your own cloud provider's API, or your own server over your SSH. There is no nextship server, no telemetry endpoint, no analytics, no update check and no crash reporting.
• The registry credential is written to a temporary directory at mode 0600 and removed afterwards, rather than passed on a command line where any local process could read it.
• shell: true appears nowhere in the codebase.

This site counts page views with Cloudflare Web Analytics, which sets no cookies. The CLI sends nothing.

What has not been proven#

• Middleware, Cache Components and PPR are proven by the compatibility suite alone. In the full run, 481 assertions pass in suites named for middleware and 122 in suites for Cache Components, in containers on the CI runner. Deploy mode skips most PPR tests, leaving 10. None has been exercised on a live App Platform app.
• Why a build session can drop right after server add is not known. It happened once in three fresh servers, and is tracked in issue #6. The retry that answers it, in 1.1.2, has run on a live server against a connection cut on purpose, not against the natural drop.
• The server target has not run on Hetzner, on an arm64 machine, on Debian 12, with a certificate for a real domain, or from the GitHub Actions workflow in its guide. Every real run so far was amd64, on DigitalOcean or Proxmox. Those are the next release's checklist.
• Multi-instance behaviour is not supported. One instance is correct; a shared cache is the next major version's work.
• No third party penetration test, and no dependency vulnerability scan in CI.
• No outside test yet. Every verification above, the macOS run included, was carried out by the people who wrote nextship. If you try it and something breaks, that is the most useful thing anyone can currently contribute.