Next.js Frontends

Deploy Next.js straight from source

Volcano builds Next.js 15 and 16 on its own machines, serves the output from a global CDN over HTTPS, and never lets a failed build replace what is running.

Start building

frontends

$volcano cloud variables deploy4 variables synced · NEXT_PUBLIC_* inlined at build time$volcano cloud frontends deploy --name web --path . --app-root apps/webbuild   next 16 · node 24 · pnpm 9deploy  static assets to the CDN · server routes on demand✓ live   https://<frontend-id>.frontends.volcano.run$volcano cloud frontends logs web --type build# the previous deployment served every request while this one built

Overview

What deploying Next.js actually involves

Running next build takes one command on any machine. The work is elsewhere: pinning the Node major the build uses, packaging a pnpm workspace so shared packages still resolve, deciding which variables get inlined into the client bundle, and keeping a broken build from taking the live site with it.

Volcano runs the build in its own infrastructure. It reads your lockfile to pick npm, pnpm or Yarn, takes the Node major from package.json engines, and serves the output from a global CDN with HTTPS. Server routes run on demand. A failed build leaves the running deployment in place.

Build

The build runs on Volcano's machines

You upload source, and Volcano installs dependencies with the package manager your lockfile names, on the Node major your package.json asks for. There is no CI image to patch and no build box that drifts away from what production expects.

Node 22 or 24, read from engines.node
npm 10, pnpm 9, Yarn 1.22 or Yarn 4
No adapter, no plugin, no config to add

cloud build

packaging ~/acme            workspace rootapp root  apps/webruntime   node 24 · pnpm 9next build · 41 routes · 12 prerendered✓ artifact ready · promoting behind the CDN

Delivery

Cached at the edge, rendered on demand

Build output and optimized images come from the CDN and never reach your code. Server components, route handlers and server actions run when a request needs them.

next/image resized and served by Volcano
No third-party image loader to configure
HTTPS enforced, IPv6 enabled, TLS provisioned

Releases

A failed build never reaches production

The running deployment keeps answering while the next one builds, and a build that fails is recorded with its logs instead of shipped. Deploy three times in a minute and only the newest one is built; the ones behind it are skipped.

Every deployment keeps its status and its logs
A newer push replaces one still waiting to build
redeploy ships again from what you already uploaded

deployment history

d-43   active       next 16 · node 24 · 2m agod-42   failed       type error in apps/web/app/page.tsxd-41   skipped      d-42 arrived before this one builtd-40   replaced     served every request until d-43 was ready✓ traffic moves only when a build succeeds

Capabilities

What every frontend gets

Next.js 15 and 16

App Router, Pages Router, server components, route handlers, server actions and ISR, with no adapter.

Global CDN with TLS

Output cached close to users, HTTPS enforced, IPv6 on, and a certificate provisioned for the hostname.

Image optimization

next/image is resized and re-encoded by Volcano, so there is no loader to configure.

Monorepo builds

Package the workspace root and build one member with --app-root, so shared packages resolve as they do locally.

Custom domains

Attach one custom domain per frontend, using a certificate and private key you supply.

Deployment history

Every deployment keeps its status and build log, and redeploy ships the artifact you already uploaded.

Code

Deploy it, protect it, put it on your domain

Shell

# Single app
volcano cloud frontends deploy --name web --path ./apps/web

# Monorepo: package the workspace root, build one member
volcano cloud frontends deploy --name web --path . --app-root apps/web

# Project variables cover the build and the server runtime. NEXT_PUBLIC_*
# is inlined into the client bundle during the build, so changing one needs
# a redeploy. That is Next.js behaviour, not a Volcano limitation.
volcano cloud variables deploy
volcano cloud frontends redeploy web

volcano cloud frontends list
volcano cloud frontends get web
volcano cloud frontends logs web --type build
volcano cloud frontends logs web --type runtime --follow

Use cases

What people host on it

next build

○  /                    static     prerendered●  /blog/[slug]         SSG        ISR 3600sƒ  /api/subscribe       dynamic    route handler✓ static output cached at the edge

Platform

Works with the rest of Volcano

Databases and vector

Data behind your routes
Route handlers and server actions query the project's database with the same client the browser uses.

Authentication

Protected routes
Middleware helpers validate the session at the edge, so a protected page redirects before it renders.

File storage

User uploads
Upload from the browser straight to a policy-gated bucket, and serve public objects from a stable URL.

Functions and agents

Long work in a function
Move exports, imports and image pipelines into a function with up to 180 seconds and 1 GB of scratch disk.

Frequently asked questions

Read the docs

Which frameworks can I deploy?

Next.js, and only Next.js: versions 15.x and 16.x. A standard project deploys without an adapter, a plugin or code changes.

Which Node version and package manager does the build use?

Node 22 or 24, taken from engines.node in your package.json and defaulting to 22. The package manager comes from your lockfile: npm 10, pnpm 9, Yarn Classic 1.22 or Yarn Berry 4.

How do I deploy from a monorepo?

Package the workspace root and name the member: volcano cloud frontends deploy --name web --path . --app-root apps/web. Workspace packages resolve during the cloud build the same way they do on your machine.

Can I use my own domain?

Yes. You attach one custom domain per frontend and supply the certificate and private key as PEM files, then point a CNAME at the target the CLI prints. The Volcano hostname keeps working alongside it, which helps while DNS propagates.

What happens when a build fails?

The running deployment keeps serving and the failed build is recorded with its logs. If you start another deploy while one is already waiting, the newer one replaces it rather than both being built.

How do environment variables reach the build?

Project variables cover both the build and the server runtime: run volcano cloud variables deploy, then deploy the frontend. NEXT_PUBLIC_* values are inlined into the client bundle while it builds, so changing one needs a redeploy — that is Next.js behaviour rather than a Volcano limitation.

Ready to deploy your frontend?

Build, deploy, and scale on Volcano's global platform — free to start, with no infrastructure to manage.

Start building free

Checkout more features

← Functions & Agents

Databases & Vector →