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/web --variable-scope all✓ Frontend 'web' deployment started$volcano cloud frontends logs web --type buildnext build · node 24 · pnpm 9 · 41 routes$volcano cloud frontends get webStatus  active   https://<frontend-id>.frontends.volcano.run# 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 installs with the package manager your package.json declares, or the one your lockfile belongs to, 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 from your lockfile with the package manager and Node major your package.json declares. 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, pnpm or Yarn, at the version packageManager names
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. Push again while a deployment is still waiting to build and the newer one takes its place.

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 on any plan, 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

# A new frontend gets only the project variables you select, for the build
# and the server runtime: all of them, or the names you list.
volcano cloud variables deploy

# Single app, with every project variable
volcano cloud frontends deploy --name web --path ./apps/web --variable-scope all

# Monorepo: package the workspace root, build one member, select by name
volcano cloud frontends deploy --name web --path . --app-root apps/web --variable-scope scoped \
  --variable NEXT_PUBLIC_VOLCANO_API_URL --variable NEXT_PUBLIC_VOLCANO_ANON_KEY

# 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 one.
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, 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 out of the request into a function, or a durable function when they run long.

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 and its version come from the packageManager field in package.json, or from your lockfile when that field is absent. npm, pnpm and Yarn are supported.

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, on any plan. 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?

From the project variables you select for the frontend: pass --variable-scope all on deploy, or --variable-scope scoped with a --variable for each name. Selected variables reach both the build and the server runtime. 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

← Durable Functions

Databases & Vector →