Deploying Next.js

Vorynza runs Next.js with a plain next build — there's no separate adapter or compatibility layer to fall behind, so any Next.js version Next itself supports works on Vorynza.

Requirement: output: "standalone"

Your next.config.js (or .ts/.mjs) must set:

/** @type {import('next').NextConfig} */
const nextConfig = {
	output: "standalone",
};

export default nextConfig;

Without this, the build fails with a clear error telling you to add it. Vorynza needs the standalone server output to run your app as a self-contained Node.js process.

How it's detected

Vorynza looks for next in your package.json dependencies and automatically sets:

You can override any of these from Settings → Git & build on your app.

What happens on deploy

1. Vorynza clones your repo and runs your install/build commands in an isolated build environment.
2. .next/static and your public/ folder are extracted and served directly from a CDN — these never touch your running server.
3. .next/standalone/server.js is packaged and deployed as its own managed function for this deployment, running your Next.js server via the AWS Lambda Web Adapter (a thin process wrapper — you don't configure or see this directly).
4. Requests hit the CDN first: static assets are served from there, everything else is routed to your server.

Because each deployment gets its own function, rollback is instant — promoting an older deployment just repoints traffic at its already-running function, nothing rebuilds.

Cold starts

The very first request after a deployment (or after a period of inactivity) may take slightly longer while the function initializes — this shows up in logs as a labeled cold start. Traffic afterward is fast.

Environment variables

Server-only secrets, database URLs, and API keys all work as normal process.env reads in your Next.js server code. See Environment variables for how to set them and scope them to production vs. preview deployments.