Deploy a Next.js application

What Lannzo expects

The build installs dependencies with the package manager your lockfile implies, runs your build script, and packages the result. Everything below is checked during the build, so a mismatch fails with a named error instead of a broken deployment.

Prepare the project

Declare the build script Next.js already generates for you:

{
  "scripts": {
    "build": "next build"
  }
}

Standalone output is the smaller, faster artifact: Next copies only the files the server needs, so the deployment stops carrying your whole dependency tree.

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;

Nothing else is required. Do not add a Dockerfile or a process manager: Lannzo runs the server directly and restarts it on its own.

Deploy it

Link the directory once, and deploy. Without flags the deployment goes to preview, which gets its own URL; --prod sends it to production.

lannzo link --project my-site
lannzo deploy
lannzo deploy --prod

To deploy from GitHub instead of your machine, connect the repository once. With --auto-deploy, every push to the production branch deploys on its own; without it, lannzo deploy --git deploys the head commit when you decide to.

lannzo repo connect --repository acme/my-site --branch main --auto-deploy
lannzo deploy --git

Both forms wait for the pipeline by default and print the deployment when it finishes. You can follow it or read the logs at any point:

lannzo inspect --wait --logs
lannzo logs --follow --level error

Environment variables

A variable has a target: build values are available while the build runs, runtime values only to the running server, and both to each. This matters for Next.js: NEXT_PUBLIC_* values are inlined at build time, so they have to be available to the build.

Secrets are written but never read back. Their values never appear in a listing, a log, or a pulled .env file.

lannzo env set NEXT_PUBLIC_SITE_URL --environment production --target build
lannzo env set DATABASE_URL --environment production --secret --target runtime

Monorepos

In a monorepo, tell Lannzo which directory to build. The path is relative to the repository root, and the build installs from the workspace root when your package manager needs it.

lannzo project set-root-directory apps/web

Override the configuration

Lannzo detects the framework on every deployment. Setting it explicitly marks the selection as manual, so detection stops overriding it, and it is what makes a custom build or start command take effect — commands saved without a manual framework are ignored by the build.

Use --auto-framework, --auto-build-command and --auto-start-command to clear a manual value and go back to detection and the framework defaults.

lannzo project config --framework nextjs
lannzo project config --framework nextjs --build-command "pnpm build"

When a build fails

`BUILD_SCRIPT_MISSING`

The package.json in the built directory has no scripts.build. In a monorepo this usually means the root directory points at the repository root instead of the application.

`NEXT_RUNTIME_OUTPUT_MISSING`

The build finished without producing a server Lannzo can run: no .next/standalone and no usable .next with the Next.js binary. A static export (output: "export") produces no server, so it cannot be deployed as a Next.js application.

Several frameworks detected

If the same package.json declares more than one supported framework, the build stops with FRAMEWORK_DETECTION_AMBIGUOUS instead of guessing. Pick one with lannzo project config --framework <framework>.