Deploy a Next.js App on Launchverse Without Vercel

Vercel is a great host for Next.js. It's also the only host the framework's docs assume by default. If you've ever tried to take a Next.js project off Vercel — for cost reasons, billing reasons, or because your team is in Lagos and Vercel's free tier dies in production traffic — this guide is for you.

We'll deploy a real Next.js 16 App Router project on Launchverse with full support for:

App Router and Server Actions
ISR / on-demand revalidation
next/image optimisation (no third-party CDN)
Streaming SSR
Server-side env vars and secrets
Custom domain + automatic Let's Encrypt HTTPS

What you need

A working Next.js project (any version since 13.4 will follow the same pattern), a Git provider where the source lives, and a Launchverse project pointed at it.

1. Make sure your build is production-shaped

pnpm build (or npm run build) should already work locally — that's the same command Launchverse will run. Two gotchas to fix first:

Static export vs. node server. If your next.config.js has output: "export" and you're not actually serving a static site, remove it. We want the standalone Node server (output: "standalone" is fine; default also works).
Image domains. Add every external host you load images from to images.remotePatterns in next.config.js. Vercel was forgiving about this; the standalone build is not.

2. Wire the project to your repo

Create a project on Launchverse, point it at your Git URL, pick the branch, and let Launchverse auto-detect Next.js. The build pipeline recognises package.json + next and runs npm run build && npm run start out of the box.

If auto-detect picks the wrong build pack (some monorepos confuse it), force it: set the build pack to Nixpacks and the install/build/start commands explicitly.

3. Set environment variables

This is the step where most people lose three hours. Next.js has two flavours of env vars:

NEXT_PUBLIC_*: baked into the client bundle at build time.
Anything else: only available server-side at runtime.

The implication is that you must set NEXT_PUBLIC_* variables before triggering the first build, not after. If you set them post-build, the client will still see undefined until you redeploy.

Server-side vars can be added at any time — they're read fresh on each request.

4. Custom domain + HTTPS

Point an A record (or CNAME if your DNS supports it) to your Launchverse application's IP, add the domain in the Domains tab, and Launchverse provisions a Let's Encrypt certificate within ~30 seconds. Redirecting HTTP → HTTPS is a one-click toggle on the application.

5. ISR and on-demand revalidation

This is the part Vercel obscures by handling automatically. For Next.js to do ISR on a single-instance deploy:

The default file-system cache works out of the box. Pages re-render on the schedule you set with revalidate.
If you scale to multiple replicas, switch to a shared cache (Redis) — Next.js 16 supports a custom cache handler via next.config.js. Launchverse has a Redis marketplace add-on you can attach in two clicks.
On-demand revalidation (revalidatePath/revalidateTag from server actions) requires no extra config; it works the same as on Vercel.

6. Image optimisation

next/image works on a self-hosted Next.js server out of the box because the optimisation runs in-process. The catch is that the default Sharp library is heavy on memory. If you're on a 512MB plan, two things help:

Set images.minimumCacheTTL so optimised variants cache aggressively.
Crank container memory to 1GB if you serve more than a handful of images. Image optimisation is the single biggest source of OOM kills on small Next.js deploys.

7. Server Actions

Server Actions Just Work — they're regular HTTPS POSTs the framework wires up automatically. No edge runtime nonsense; they execute on your Node server. The only thing to watch is body size: if you accept large file uploads, raise the reverse-proxy body limit in Launchverse's project settings.

8. Logs and observability

Logs stream live from the application page. For long-form analytics (deploys, errors, build minutes), the Observability tab on Launchverse pulls real telemetry from the platform — no Datadog setup required for day one.

Done

Push to the connected branch and Launchverse builds, deploys, and routes traffic. Most Next.js teams who migrate from Vercel report the runtime works better on a single dedicated container (no cold starts) and is meaningfully cheaper at modest traffic. The trade-off is global-edge latency: you lose Vercel's automatic edge cache. For African / European / Asian audiences served from the closest region, that's usually a wash.