Additional Build Types Free

Build applications with Railpack, Heroku Buildpacks, or Paketo Buildpacks — in addition to Coolify's built-in Nixpacks, Dockerfile, Docker Compose, and Static options.

Overview

Coolify uses Nixpacks by default to auto-detect your application's language and build a Docker image. Additional Build Types adds three more options, each with different strengths:

Build Type	Tool	Best For
Railpack	railpack CLI	Fast builds with excellent caching, modern language support
Heroku Buildpacks	pack CLI	Heroku-compatible apps, existing Heroku configurations
Paketo Buildpacks	pack CLI	Cloud Native Buildpacks with broad language support

Selecting a Build Type

1. Navigate to your application's settings
2. Go to General > Build Pack
3. Select from the dropdown: Nixpacks, Dockerfile, Docker Compose, Static, Railpack, Heroku Buildpacks, or Paketo Buildpacks
4. Save and deploy

The build type can also be selected when creating a new application from the New Resource page.

Railpack

Railpack is Railway's next-generation builder, designed as a successor to Nixpacks with better caching and faster builds.

Key features:

• Automatic language and framework detection
• Excellent build caching — subsequent builds are significantly faster
• Active development with frequent improvements
• Installed on-demand (downloaded automatically on first deploy)

Supported languages: Node.js, Python, Ruby, Go, Rust, Java, PHP, Elixir, and more.

How it works:

1. Railpack analyzes your repository
2. Detects the language, framework, and dependencies
3. Builds a Docker image using BuildKit
4. No configuration needed — it auto-detects everything

When to choose Railpack

Choose Railpack if you want the fastest builds with the best caching, or if Nixpacks doesn't detect your stack correctly. Railpack is actively developed by Railway and often supports newer language versions first.

Heroku Buildpacks

Heroku Buildpacks use the heroku/builder:24 image with Cloud Native Buildpacks (pack CLI).

Key features:

• Full compatibility with Heroku deploy configurations
• Mature, battle-tested buildpacks
• Procfile support
• Wide language support through the Heroku ecosystem

Supported languages: Node.js, Python, Ruby, Java, Go, PHP, Scala, Clojure, and more.

How it works:

1. The pack CLI detects buildpacks for your language
2. Builds using the heroku/builder:24 base image
3. Respects Procfile, runtime.txt, and other Heroku conventions

When to choose Heroku Buildpacks

Choose Heroku if you're migrating from Heroku and want to keep your existing Procfile and build configuration, or if you need a specific Heroku buildpack that isn't available elsewhere.

Paketo Buildpacks

Paketo Buildpacks use the paketobuildpacks/builder-jammy-base image, part of the open-source Cloud Native Buildpacks ecosystem.

Key features:

• Open-source, vendor-neutral buildpacks
• Ubuntu Jammy (22.04) base image
• Strong Java/JVM ecosystem support
• Bill of Materials (SBOM) generation

Supported languages: Java, Node.js, Go, Python, Ruby, .NET, PHP, and more.

How it works:

1. The pack CLI selects appropriate Paketo buildpacks
2. Builds using the paketobuildpacks/builder-jammy-base image
3. Outputs a production-ready OCI image

When to choose Paketo

Choose Paketo for Java/JVM applications where Paketo's buildpacks excel, or when you need vendor-neutral Cloud Native Buildpacks with SBOM generation.

Comparison

Feature	Nixpacks	Railpack	Heroku	Paketo	Dockerfile
Auto-detection	Yes	Yes	Yes	Yes	No
Build caching	Good	Excellent	Good	Good	Manual
Configuration needed	None	None	None/Procfile	None	Full
First build speed	Fast	Medium	Slow (large image pull)	Slow (large image pull)	Varies
Subsequent builds	Fast	Very fast	Fast	Fast	Varies
Custom build steps	Limited	Limited	Procfile	Limited	Full control
Language coverage	Broad	Broad	Broad	Broad	Any

Builder Image Sizes

Heroku and Paketo builder images are large (500–800 MB). The first deployment pulls the builder image, which may be slow. Subsequent deployments use the cached image.

Environment Variables

All build types automatically pass your application's environment variables to the build process. No additional configuration is needed — variables defined in your application settings are available during the build.

Pull Request Deployments

All three additional build types support Coolify's pull request deployment feature. When a PR is opened, the correct build type is used for the preview deployment.