Documentation menu

Deploy Next.js on Light Cloud - server-rendered behind the edge CDN by default, or as a static export served entirely from the CDN.

Deploy Next.js

Next.js deploys in one of two shapes, and detection picks the right one from your next.config.js:

ShapeWhenServes from
Server-rendered (default)Anything with server code: SSR, API routes, server actionsA container behind the edge CDN
Static exportoutput: 'export' in the configThe CDN only - no server at all

Server-rendered#

Push a Next.js repo and it builds into a container (generated image on Node 22, listening on port 3000).

Server-rendered frontends run under the SSR policy: pinned to the Micro size, scaling 0-3, in a tier-1 region, always behind the edge CDN. The edge serves your audience; the origin only renders cache misses, so a bigger origin would buy nothing.

Things to know:

  • Port. The server must listen where the platform routes - the generated setup handles it, and next start respects the PORT variable, which is set for you.
  • Runtime configuration. Server code reads process.env at runtime as usual - set values as environment variables, per environment.
  • Build-time inlining. Container images are built without your runtime variables, so NEXT_PUBLIC_* values are inlined from what exists at image build, not from the environment's variable set. Read configuration server-side at runtime where you can; if the client bundle must carry environment-specific values, prefer the static export shape, whose build runs with the variables set.

Static export#

Set the export mode in next.config.js:

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

module.exports = nextConfig;

The build writes plain files into out, and that folder is served from the CDN - free bandwidth, no region, no cold starts, no instance to pay for. NEXT_PUBLIC_* variables work normally here, because static builds run with the environment's variables set.

Static export drops the server features: no SSR, no API routes, no server actions. If you need an API next to a static frontend, deploy it as its own backend app - a monorepo with two apps and two root directories works well.

Which shape to pick#

  • Content sites, docs, dashboards against an external API: static export. Cheapest and fastest.
  • Apps that render per-request, use API routes, or need server actions: server-rendered.

You can switch later - change the config, push, and detection follows.