Deploying — Docs

Supported projects

Node.js apps — anything with a package.json. Next.js, Express, Fastify, NestJS, Nuxt, Remix, SvelteKit with a Node adapter, and so on.
Static sites — a repository with no package.json is served as-is, with index.html as the entry point.

The repository must be reachable over plain HTTPS, such as https://github.com/you/site or https://gitlab.com/you/site.git. Private repositories are not supported yet.

How the build is worked out

With no build settings, Kernel6 reads your package.json:

Step	What runs
Install	`npm install`
Build	`npm run build`, only if a `build` script exists
Start	`npm start` if a `start` script exists; otherwise the `main` file (default `index.js`)

Your app is run by the pm2 process manager, which restarts it if it exits unexpectedly.

Listen on PORT

Your app must listen on the port in the PORT environment variable. Next.js and most frameworks do this already. For a hand-written server:

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on ${port}`));

Build settings

Open Build settings on the project page to override any step. Leave a field empty to keep the automatic behaviour. Changes apply on the next deploy.

Setting	Use it when	Example
Root directory	Your site lives in a subfolder, e.g. a monorepo	`apps/web`
Install command	You use pnpm, yarn, or need an extra step	`npm ci`
Build command	Your build is not the `build` script	`npm run build:prod`
Start command	Your app does not start with `npm start`	`node dist/server.js`

Resource limits

Running app: each app may use up to half of its server's memory, and never less than 512 MB. On the Dedicated plan's 4 GB server that is 2,048 MB. If the app exceeds it, it is restarted automatically.
Builds: where the server supports it, installs and builds run with a memory ceiling and at most 70% of the CPU, so a heavy build cannot starve the other sites on the server.

Reading the build log

Every step writes a line beginning with ==>. A successful deploy looks like this:

==> Deployment queued
==> Connecting to ec2-user@203.0.113.10 (your server)
==> Memory limit for this app: 2048 MB
==> Preparing $HOME/kernel6/apps/…
==> Pulling latest main
==> Writing 3 environment variable(s) to .env
==> Installing dependencies
==> Running build
==> Starting app with pm2 (npm start) on port 4001
==> Waiting for app to accept connections on port 4001
    responded with HTTP 200
==> App is up on port 4001
==> Routing https://a1b2c3d4.apps.kernel6.com to port 4001

==> Deployment successful: https://a1b2c3d4.apps.kernel6.com

The first deploy says Cloning … instead of Pulling latest …. Later deploys reset the server's copy to exactly match the branch on your Git host.

Downtime during a deploy

The running version of your app is stopped before the new version installs and builds. Your site is unavailable while the build runs, and if the build fails it stays unavailable until a deploy succeeds. Run your build locally before deploying to avoid surprises.

When a deploy fails

The log ends with ==> Deployment failed and the reason. The common ones:

What you see	What it usually means
Errors during clone or pull	The repository URL or branch name is wrong, or the repository is private.
Errors during install or build	The same error you would get running it locally — a missing dependency, a type error, or a missing environment variable needed at build time.
`App did not respond on port …`	The app started but never answered within a minute. It is usually not listening on `PORT`, or it crashed on startup. The last 50 lines of your app's output are printed right below — the answer is normally there.
`NOT reachable from the internet`	Your app runs on the server, but its public address did not answer from outside. The log explains what to check; if it persists, contact us.

Start, stop and restart

The buttons next to Deploy restart, stop and start the app without rebuilding it. A stopped app stops being served, and does not trigger downtime alerts — stopping it was your choice.

Deploy history

Each deployment is kept with its start time, status, duration, address and full build output. Select a row in Deploy history to read its log — useful for comparing a failed run with the last one that worked. To roll back, revert the change in Git and deploy again.

Next: Environment variables.