nixpacks

Nixpacks is a tool that transforms an application source directory into an OCI-compliant image. It achieves this by combining the application source, Nix packages, and Docker to create a deployable image. It is designed as an alternative to Buildpacks, leveraging the Nix ecosystem to manage system and language dependencies.

Note: This project is currently in maintenance mode and is not under active development. For new projects, it is recommended to use Railpack instead.

Nixpacks is a tool that takes a source directory and produces an OCI-compliant image suitable for deployment anywhere. It is designed with intuitive defaults that allow most applications to build and deploy without manual configuration, while remaining highly customizable via Nix packages and build/start commands.

Note: This project is currently in maintenance mode and is not under active development. The maintainers recommend using Railpack as a replacement.

Nixpacks automatically detects Python projects if any of the following files are present in the repository:

• main.py
• requirements.txt
• pyproject.toml
• Pipfile

A virtual environment (venv) is created at /opt/venv and the PATH is modified to use the venv's Python binary.

Nixpacks operates in two primary stages: Plan and Build.

1. Plan: Nixpacks analyzes your application source directory to generate a reproducible build plan in JSON format. It matches language providers to your code to suggest Nix packages, an install command, a build command, and a start command. Users can overwrite any of these suggestions.
2. Build: Nixpacks uses the build plan to create an OCI-compliant image using Docker BuildKit. The build process involves copying the source to a temporary directory and executing build phases in topological order.

Nixpacks automatically caches specific directories during the install and build phases to speed up subsequent builds. Common examples include ~/.npm for installs and ~/.cache/go-build for builds.

Key behaviors:

• Lifecycle: Cached contents are restored before the install/build phases and cleared afterward.
• Final Image: Cached directory contents do not appear in the final image.
• Default Identifier: Nixpacks uses a hash of the absolute path to the directory being built as the default cache identifier.

Luminus organizes middleware into specific namespaces:

• Custom Middleware: Place application-specific middleware in the clojure-luminus.middleware namespace. These are typically assembled in a wrap-base function.
• Development Middleware: Place middleware intended only for development environments in the clojure-luminus.dev-middleware namespace, located under the env/dev/clj/ source path.