Builds & start commands · Naijacloud docs

Deploy

Builds & start commands

Naijacloud inspects your repository, works out how to build and run it, and fills in the commands. When your project is unusual, the same two fields let you take over.

5 min read

How detection works

When a build starts, we inspect the repository for the markers that identify a stack: a lockfile, a manifest, a framework config. From those we compose the build, picking the right language runtime and package manager, then an install step, a build step and a start command.

You do not need a Dockerfile. The two fields you see on the form are the parts worth overriding:

Build and start

npm run build     # build command: runs once, at build time
npm start         # start command: runs the service, must stay alive

Package managers

The lockfile in your repository decides the package manager, so committing it matters:

Lockfile	Manager used
`package-lock.json`	npm
`yarn.lock`	Yarn
`pnpm-lock.yaml`	pnpm
`bun.lockb`	Bun

Commit your lockfile. Without one, the manager is a guess and installs are not reproducible. A build that works today can break tomorrow, as soon as a transitive dependency publishes.

The start command must stay alive

A web service is considered healthy when its process is listening and answering requests. That means the start command has to be a long-running server.

Common mistakes:

A build command in the start field. npm run build exits, so the health check never passes.
A dev server in production. Development servers are not built for production traffic and often bind to the wrong interface.
A preview server for a static build. If the output is HTML, CSS and JS with no server logic, deploy it as a static site instead. You get a faster deploy and pay for bandwidth rather than an instance.

Listening on the right port

Bind to the port supplied in the PORT environment variable, and to all interfaces rather than only localhost:

server.js

const port = process.env.PORT || 3000;

// 0.0.0.0, not localhost. The health check comes from outside the process.
app.listen(port, '0.0.0.0');

A service that binds to 127.0.0.1 starts cleanly and still fails its health check, because nothing outside the container can reach it.

Monorepos

For a service that lives in a subdirectory, set the root directory to that package. Install, build and start then all run from there, and the rest of the repository is still available for shared code.

Monorepo layout

apps/
  web/          # root directory for the web service
  api/          # root directory for the API service
packages/
  ui/           # shared, resolved from either app

Deploy each app as its own service, pointing at the same repository with different root directories.

Static output from a framework

Frameworks that can build either a server or a static bundle need the mode to match the service kind:

Building a server (SSR, API routes) → deploy as a web service, with a start command that runs the built server.
Building static files → deploy as a static site and point it at the output directory.

If a build succeeds but the service will not stay up, read the tail of the build log first, where the failing line is highlighted. Then check whether the start command is a server, and whether it binds to PORT on 0.0.0.0.

Next steps

Environment variables →

Values and secret files, and how scoping works.

Deploys, logs & rollbacks →

Watch a build, cancel one, or roll back to an earlier release.

← Previous

Connecting a source

Environment variables