Deploy Next.js on Nodion

Deploy Next.js step by step

1. Keep a lockfile and the usual scripts Commit package-lock.json, yarn.lock, pnpm-lock.yaml or bun.lock; the build fails without one. next start listens on the PORT that Nodion sets, so the default scripts work as they are. package.json

   "scripts": {
     "build": "next build",
     "start": "next start"
   }

2. Create the app In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository, pick the branch and the region EU Central. Keep the build strategy on Buildpacks; if the repository has a Dockerfile, the form picks Dockerfile instead.
3. Set environment variables Everything next build reads, such as NEXT_PUBLIC_*, needs the Build flag on the Environment tab; all other variables only exist at runtime. Mark API keys as secret.
4. Attach PostgreSQL and run migrations Create a database in the same region and attach it on the Environment tab; the app gets DATABASE_URL on the next deploy. A release: line in a Procfile runs once per build before the new version starts. Keep your migration tool in dependencies: dev dependencies are removed after the build. Procfile

   release: npm run migrate

5. Push to deploy Every push to the branch builds a new release. Traffic moves to it once it answers on / with a 2xx or 3xx status; if the release step fails, the running version stays live.

Good to know

• Static exportWith output: 'export' in next.config, Nodion serves out/ with a static web server and an index.html fallback. No Node server runs, so the smallest size is enough.
• Health check pathIf / answers 401 or 404, set a health check path that returns 200, for example a route handler at /api/health, in the app settings.
• MonoreposPoint the base directory at the Next.js app. The build only sees that directory, so the lockfile has to be in it.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Vercel Alternatives in Europe: 5 Options for Next.js Functions at the edge or an always-on Node.js server next to your database: five Vercel alternatives for Next.js, compared by runtime model and location.
• Preview Environments Explained: An App per Pull Request A running copy of your app for every pull request: what preview environments are good for, where they get tricky and how Nodion handles them.

Next.js on Nodion: questions and answers