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:
| Shape | When | Serves from |
|---|---|---|
| Server-rendered (default) | Anything with server code: SSR, API routes, server actions | A container behind the edge CDN |
| Static export | output: 'export' in the config | The 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 startrespects thePORTvariable, which is set for you. - Runtime configuration. Server code reads
process.envat 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.