Deploying a Next.js or Node app

Modern JS frameworks blur the line between static and dynamic. Here is how to run them here.

Choose your mode

• Static export (next build && next export, or Next.js with output: 'export') — pure HTML/CSS/JS, no server. Fastest and simplest; host it as a static site.

• Server mode — runs a Node process that renders on demand. Needed for API routes, server-side auth or ISR. Runs behind our proxy as a Node app.

Server mode, step by step

1. Set the site runtime to Node in /panel/web.

2. Build command: npm ci && npm run build.

3. Start command: npm run start (Next.js) or your app's entry point.

4. Port: read it from the environment (process.env.PORT) so the proxy can route to it.

Set environment variables in the panel — database URLs, API keys, feature flags. Never commit them.

Database

Your app will likely need one. We offer managed PostgreSQL and MySQL, reachable over a private address. See Databases on HostingSwift for creating one and connecting safely. The Node Prisma client is a common choice; plain SQL drivers work equally well.

Common pitfalls

• Binding to the wrong port. Your app must listen on the port the panel expects, on 0.0.0.0 (or the provided interface), not 127.0.0.1 inside a container.

• Building on every boot. Build once at deploy; serve the built output at runtime.

• Leaving dev dependencies in production. Prune them; they add attack surface and size.

• Assuming the filesystem persists. Ephemeral writes vanish on redeploy. Use object storage for uploads — see Object storage basics.

• Ignoring cold starts. A serverless-style cold path is slower than a warm process; if latency matters, keep a process running.

Deploying updates

Push to your deploy branch, or re-run the build from the panel. Do it behind a staging site first for anything non-trivial — see Staging sites and safe deployment habits.

Related reading

• Databases on HostingSwift

• PHP and Node runtimes