# Buildpacks

Salus buildpacks are the default, in-house builder. Connect your repository and Salus detects your stack — JavaScript/TypeScript frameworks (React, Vue, Next.js, and others), .NET (C#) applications, and Python apps with a `requirements.txt` and a `Procfile` — and runs the right commands. No build files to write, and no Dockerfile needed. You tune this under **Build Configurations** in your project settings; see [Builds](https://salus.cloud/docs/pipelines/builds/) for how builds are triggered.

Where it helps to be explicit, you can override any of these in Build Configurations:

-   **Install command** — how dependencies are installed. If you leave it empty, Salus auto-detects it from your lockfile (for example `npm ci`, `yarn install`, `pnpm install`, or `bun install`).
-   **Build command** — the command that produces your production build. If you leave it empty, no build step runs.
-   **Output directory** — the folder your build writes its final files to, relative to the project root. Salus serves or packages what it finds there.
-   **Test command** — the command that runs your test suite during the [unit testing](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/) stage.

Note

Salus sets sensible defaults for these based on the framework it detects, so you usually only set them when your project does something non-standard.

## Example build settings

Salus detects these for you — the values below are shown for reference:

| Framework | Build command | Output directory |
| --- | --- | --- |
| React (Vite) | `npm run build` | `dist` |
| Vue (Vite) | `npm run build` | `dist` |
| Create React App | `npm run build` | `build` |
| Astro | `npm run build` | `dist` |

Server-side apps (for example Express, ASP.NET Core, or Next.js in server mode) run continuously and don’t serve a build-output directory. Set a **test command** such as `npm test` to run your suite in the [unit testing](https://salus.cloud/docs/pipelines/quality-and-security/unit-testing/) stage.

## Need more control?

If a buildpack can’t express your build — a specific environment, complex system dependencies, or custom steps — build from your own Dockerfile instead. See [Custom Docker Builds](https://salus.cloud/docs/pipelines/builds/custom-docker/).

## Troubleshooting

-   **Nothing was built.** An empty **build command** means no build step runs. Set it if your framework needs a build.
-   **Deploy is missing files / serves the wrong thing.** Check the **output directory** — it must point at the folder your build actually writes to, relative to the project root.
-   **Wrong runtime version.** Set the correct language version in Build Configurations — see [Supported Stacks](https://salus.cloud/docs/getting-started/supported-stacks/).