How It Works/Build Configuration

Build Configuration

Jetpacked's detection engine automatically determines how to build and run your app. If it gets something wrong, or if your project has a non-standard setup, you can override any field from the Configure tab in your project settings.

Overrides are saved and applied to every subsequent deployment. The detection result is only used as the initial default.

Overridable fields

Build command

The command used to compile your app. Examples:

npm run build
pnpm build
bun run build:prod

Leave blank if your app has no build step.

Start command

The command used to start your app in production. Examples:

node dist/server.js
bun run start
node .next/standalone/server.js

Output directory

For static sites, the folder that contains the built output to be served. Examples:

dist
build
out
.next

Port

The port your app listens on internally. Defaults to 3000 for most frameworks. Jetpacked maps this to the external HTTPS port automatically — you do not need to change this unless your app listens on a non-standard port.

Node.js version

If Jetpacked detects the wrong Node.js version, you can pin it explicitly by adding a .nvmrc or .node-version file to your repository root:

20

Or via the engines field in package.json:

{
  "engines": {
    "node": ">=20"
  }
}

When to use overrides

Most apps deploy correctly without any overrides. You typically need them when:

  • Your build or start script has a non-standard name
  • Your app is in a monorepo subdirectory (see Monorepos)
  • You have a custom output path
  • Your app listens on a port other than 3000

© 2026 Jetpacked. All rights reserved.

PrivacyTerms