Nixpacks vs Buildpacks vs Dockerfile: Which Build Tool in 2026?

Dockerfiles are the standard but not always the best choice. Buildpacks and Nixpacks promise to build containers automatically without you writing a Dockerfile. After using all three in production, here's the real comparison.

What Each One Is

Dockerfile: You write explicit instructions. You control everything. Standard for 10+ years.

Cloud Native Buildpacks (CNB): Heroku's model, standardized. Detects your language and applies pre-built build logic. Used by Heroku, Google Cloud Run, Paketo.

Nixpacks: Open-source, built by Railway. Detects language like buildpacks but uses Nix packages for reproducibility. Simpler to understand than buildpacks.

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/index.js"]

Pros:

• Full control over every step
• Familiar — everyone knows Dockerfiles
• Works everywhere (Docker, Podman, BuildKit)
• Easy to debug
• Can optimize heavily (multi-stage, layer caching)

Cons:

• You have to write and maintain it
• Security: you choose the base image, you're responsible for updates
• Each language/framework needs its own patterns

Best for:

• Any team that needs control and customization
• Complex build requirements (custom compilers, native extensions)
• Security-conscious teams who vet base images

Cloud Native Buildpacks

# No Dockerfile needed - detects Node.js automatically
pack build myapp --builder paketobuildpacks/builder-jammy-base
 
# Or with Google Cloud
pack build gcr.io/myproject/myapp --builder gcr.io/buildpacks/builder

Buildpacks detect your language, download the right tools, and build the image. They follow the OCI image spec and work with any OCI-compatible runtime.

Pros:

• Zero Dockerfile to write or maintain
• Buildpack maintainers handle OS patches and dependency updates
• Standardized — same commands for Node.js, Python, Java, Go
• Rebase: update OS layer without rebuilding your app
• Bill of Materials (SBOM) built in

# Update just the OS layer without full rebuild
pack rebase myapp --run-image paketobuildpacks/run-jammy-full

Cons:

• Build times can be slower than optimized Dockerfiles
• Limited control — hard to add custom build steps
• The builder images are large
• Complex to debug when something goes wrong
• Requires pack CLI or buildpack-compatible CI

Best for:

• Platform engineering teams building internal PaaS
• Enterprise environments where security patches are mandatory
• Teams with many languages/frameworks who want consistency

Nixpacks

# Install
curl -sSL https://nixpacks.com/install.sh | bash
 
# Build without any config
nixpacks build . --name myapp
 
# Or with Railway (uses nixpacks automatically)
railway up

Nixpacks inspects your project, determines the language, downloads packages from the Nix ecosystem, and builds an OCI image.

For a Node.js project it detects package.json and runs:

1. Install Node.js from Nixpkgs
2. npm ci
3. npm run build
4. Set appropriate CMD

Customization with nixpacks.toml:

# nixpacks.toml
[phases.setup]
nixPkgs = ["nodejs_20", "python311"]  # add extra nix packages
 
[phases.install]
cmds = ["npm ci"]
 
[phases.build]
cmds = ["npm run build"]
 
[start]
cmd = "node dist/index.js"

Pros:

• Simpler than buildpacks to understand and customize
• Reproducible builds via Nix's pinned packages
• Works on Railway, self-hosted, or locally
• Good language detection out of the box
• Open source, fast-moving project

Cons:

• Younger project than buildpacks (less battle-tested)
• Nix learning curve if you need to customize
• Less tooling/ecosystem than Dockerfile
• Railway is the primary production user — limited other adopters

Best for:

• Teams using Railway for deployment
• Teams who want zero-config for standard apps
• Developer-facing platforms where simplicity > control

Real-World Comparison

Testing with a Node.js + TypeScript API (medium-sized, ~300 files):

My Verdict

Use Dockerfile if:

• Your team knows Docker well (most teams do)
• You have complex build requirements
• Image size matters
• You want maximum control and auditability

Use Buildpacks if:

• You're building an internal developer platform
• You manage many services and want standardized builds
• OS patch management/compliance is a requirement
• You're deploying to Google Cloud Run or Heroku

Use Nixpacks if:

• You're on Railway
• You want near-zero configuration for standard apps
• You want reproducibility without writing Dockerfiles

The honest answer: For 80% of teams, an optimized Dockerfile is the right choice. It's understood by everyone, debuggable, and flexible. Buildpacks shine specifically for platform engineering scenarios. Nixpacks is excellent if you're already on Railway.

Resources: Buildpacks.io | Nixpacks docs | Paketo buildpacks