Nixpacks
Nixpacks detects the application's language and framework from its codebase and generates a Dockerfile. Coolify builds the application image from those generated instructions.
Use Nixpacks when the codebase follows a supported convention and does not need a custom Dockerfile. Nixpacks is available for Git-based applications.
Railway states that Nixpacks is not under active development and recommends Railpack as its successor.
Coolify still supports Nixpacks. For a new application, evaluate Railpack first, but note that Coolify currently labels Railpack as Beta. Test the generated image before switching an existing application because the two builders use different configuration files and can produce different results.
When to use Nixpacks
Nixpacks is a good fit when:
- the application uses a language or framework supported by Nixpacks
- its manifest and lockfile are available inside the configured Base Directory
- automatic install, build, and start command detection is sufficient
- the build needs only small command, package, or phase overrides
Use Dockerfile when the image needs exact base images, operating-system configuration, copy instructions, users, or build stages.
Follow Deploy with Nixpacks for the complete setup procedure.
How Coolify uses Nixpacks
For each deployment, Coolify gives Nixpacks the application source directory and build configuration. Nixpacks detects providers, packages, and commands, then generates the Dockerfile used to build the image.
For a server application, Coolify starts a container from that image and routes requests to the configured internal port.
For a static application, Nixpacks builds the frontend and Coolify copies the selected Publish Directory into an Nginx image.
Configure Nixpacks
Coolify shows the detected Install Command, Build Command, and Start Command under Configuration > General. Override only the command the application needs to change.
Nixpacks can also read nixpacks.toml or nixpacks.json from the application source directory. Use a configuration file when the build needs packages, phases, or behavior that cannot be expressed through the Coolify command fields.
Nixpacks environment variables use the NIXPACKS_ prefix. Add build configuration under Configuration > Environment Variables and keep Build Variable enabled.
Refer to the Nixpacks configuration documentation for the supported file schema.
Static applications
When Is it a static site? is enabled, Coolify serves the selected publish directory through Nginx.
Use Configuration > General > Nginx Configuration only when the default static-server configuration is insufficient. Redeploy after saving a change because Coolify copies the configuration into the final static image during the image build.
Node.js versions
Nixpacks selects Node.js from repository configuration such as engines.node, .nvmrc, or .node-version, or from NIXPACKS_NODE_VERSION.
Read Node.js versioning before depending on a specific minor or patch version.
Use multiple CPU cores with Node.js
A plain Node.js process uses one CPU core. Read Node.js multi-core scaling when a Node.js or Bun application should use multiple cores from one Nixpacks deployment.
Troubleshoot detection
If the build uses the wrong provider or command:
- confirm Base Directory contains the application manifest
- inspect the generated plan in the deployment log
- remove conflicting lockfiles or manifests from that source directory
- add a Nixpacks configuration file or override the affected command
- use Dockerfile when the build needs complete image control
Nixpacks resolves an older package
Nixpacks can resolve an older package from its selected nixpkgs archive. For Node.js, read Node.js versioning. For other packages, refer to the upstream nixpkgs archive setting and test an archive change before using it in production.