Installation§

Prerequisites§

NGINX Unit is verified to compile and run on various Unix-like operating systems, including:

FreeBSD 10 or later
Linux 2.6 or later
macOS 10.6 or later
Solaris 11

Most modern instruction set architectures are supported, such as:

ARM
IA-32
PowerPC
MIPS
S390X
x86-64

App languages and platforms that Unit can run (including multiple versions of the same language):

Go 1.6 or later
Java 8 or later
Node.js 8.11 or later
PHP 5, 7
Perl 5.12 or later
Python 2.6, 2.7, 3
Ruby 2.0 or later

Docker Images§

To install and run Unit from our Docker image repository:

# docker pull nginx/unit
# docker run -d nginx/unit

By default, the :latest image tag is used that resolves into a -full configuration of the latest Unit version. Other tags available:

Tag	Description
`1.13.0-full`	Modules for all supported languages.
`1.13.0-minimal`	No language modules.
`1.13.0-<language>`	Specific language module only, for example `1.13.0-ruby2.3` or `1.13.0-python2.7`.

Note

Control socket is located here: /var/run/control.unit.sock.

For further details, see the repository page and our Howto.

Initial Configuration§

Our images support initial container configuration, done with an ENTRYPOINT script. First, the script checks the Unit state directory (/var/lib/unit/ in official images) of the container; if it’s empty, the script scans the /docker-entrypoint.d/ directory of the container for certain file types, processing them in this order:

File Type	Purpose/Action
`.pem`	Certificate bundles, uploaded under their respective names: `cert.pem` -> `certificates/cert`.
`.json`	Configuration snippets, uploaded to Unit as portions of the `config` section.
`.sh`	Shell scripts, executed within the container after `.pem` and `.json` files are handled.

Note

The script issues warnings about any other file types in the /docker-entrypoint.d/ directory.

This mechanism allows you to customize your containers at startup, reuse configurations, and automate your workflows, reducing manual effort. To use the feature, add COPY directives for certificate bundles, configuration fragments, and shell scripts to your Dockerfile derived from an official image:

FROM nginx/unit:1.13.0-minimal
COPY ./*.pem  /docker-entrypoint.d/
COPY ./*.json /docker-entrypoint.d/
COPY ./*.sh   /docker-entrypoint.d/

Note

Mind that running Unit populates its state directory; this prevents the script from executing, so this script-based initialization must occur before you run Unit within your derived image.

This comes in handy if you want to tie Unit to a certain application configuration for later use. For ad-hoc initialization, you can simply mount a directory with configuration files to a container at startup:

$ docker run -d --mount \
         type=bind,src=/path/to/config/files/,dst=/docker-entrypoint.d/ \
         nginx/unit:latest)

Community Repositories§

Warning

Distributions listed here are maintained by respective communities, not NGINX. Proceed with caution.

Alpine Linux§

To install core Unit executables using Alpine Linux packages:

# apk update
# apk upgrade
# apk add unit

To install service manager files and specific language modules:

# apk add unit-openrc unit-perl unit-php7 unit-python3 unit-ruby

Note

Control socket is located here: /run/control.unit.sock.

Arch Linux§

To install Unit using the Arch User Repository (AUR):

# pacman -S git
$ git clone https://aur.archlinux.org/nginx-unit.git
$ cd nginx-unit

Warning

Verify that the PKGBUILD and accompanying files are not malicious or untrustworthy. AUR packages are entirely user produced without pre-moderation; you use them at your own risk.

$ makepkg -si

Note

Control socket is located here: /run/nginx-unit.control.sock.

CentOS/RHEL SCLs§

If you use SCLo Software Collections in your environment, you can install Unit’s PHP modules as packages from the corresponding repo. Besides other dependencies, the packages require core Unit installation.

CentOS:

# yum install centos-release-scl
# yum install --enablerepo=centos-sclo-sclo-testing \
      sclo-php70-unit-php sclo-php71-unit-php sclo-php72-unit-php

RHEL:

# cd /etc/yum.repos.d/
# curl -O https://copr.fedorainfracloud.org/coprs/rhscl/centos-release-scl/repo/epel-7/rhscl-centos-release-scl-epel-7.repo
# yum install centos-release-scl
# yum install --enablerepo=centos-sclo-sclo-testing \
      sclo-php70-unit-php sclo-php71-unit-php sclo-php72-unit-php

FreeBSD§

To install Unit using FreeBSD packages, update the repository and install the package:

# pkg install -y unit

Note

Control socket is located here: /var/run/unit/control.unit.sock.

To install Unit using FreeBSD ports, update your port collection.

For portsnap:

# portsnap fetch update

For svn:

# svn update /usr/ports

Next, browse to the port path to build and install the port:

# cd /usr/ports/www/unit
# make
# make install

Warning

Here, make is used in port configuration. To make a Unit build using our repositories, see below.

Note

Control socket is located here: /var/run/unit/control.unit.sock.

Gentoo§

To install Unit using Portage, update the repository and install the package:

# emerge --sync
# emerge www-servers/nginx-unit

Note

Control socket is located here: /run/nginx-unit.sock.

NixOS/Nix§

To install Unit using the Nix package manager, update the repository and install the package:

$ nix-channel --update
$ nix-env -qa 'unit'    # check availability and version
$ nix-env -i unit

Note

Control socket is located here: /run/unit/control.unit.sock.

Remi’s RPM Repo§

Remi’s RPM repository, which hosts the latest versions of the PHP stack for CentOS, Fedora, and RHEL, also has the base Unit package and the PHP modules.

To use Remi’s versions of Unit packages, configure Remi’s RPM repo first. Remi’s PHP language modules also work with the base Unit package from our own repository.

Next, install Unit and the PHP modules you want:

# yum install --enablerepo=remi unit php54-unit-php php55-unit-php \
      php56-unit-php php70-unit-php php71-unit-php php72-unit-php php73-unit-php

Note

Control socket is located here: /var/run/unit/control.sock.

Source Code§

Getting Sources§

You can obtain Unit source code from our official Mercurial repository, its GitHub mirror, or in a tarball.

If you’d like to use Mercurial:

$ hg clone https://hg.nginx.org/unit
$ cd unit

If you prefer Git:

$ git clone https://github.com/nginx/unit
$ cd unit

To download sources directly from our site:

$ curl -O https://unit.nginx.org/download/unit-1.13.0.tar.gz
$ tar xzf unit-1.13.0.tar.gz
$ cd unit-1.13.0

Installing Required Software§

Before configuring and compiling Unit, install the required build tools plus the library files for available languages (Go, Node.js, PHP, Perl, Python, and Ruby) and the other features you want Unit to support.

The commands below assume you are configuring Unit with all supported languages and features; otherwise, skip the packages you aren’t going to use.

Debian, Ubuntu

# apt install build-essential
# apt install golang
# curl -sL https://deb.nodesource.com/setup_<Node.js version>.x | bash -
# apt install nodejs
# npm install -g node-gyp
# apt install php-dev libphp-embed
# apt install libperl-dev
# apt install python-dev
# apt install ruby-dev
# apt install openjdk-8-jdk
# apt install libssl-dev

Amazon Linux, CentOS, Fedora, RHEL

# yum install gcc make
# yum install golang
# curl -sL https://rpm.nodesource.com/setup_<Node.js version>.x | bash -
# yum install nodejs
# npm install -g node-gyp
# yum install php-devel php-embedded
# yum install perl-devel perl-libs
# yum install python-devel
# yum install ruby-devel
# yum install java-1.8.0-openjdk-devel
# yum install openssl-devel

FreeBSD

Ports:

# cd /usr/ports/lang/go/ && make install clean
# cd /usr/ports/www/node/ && make install clean
# cd /usr/ports/www/npm/ && make install clean && npm i -g node-gyp
# cd /usr/ports/lang/php73/ && make install clean
# cd /usr/ports/lang/perl5.28/ && make install clean
# cd /usr/ports/lang/python/ && make install clean
# cd /usr/ports/lang/ruby25/ && make install clean
# cd /usr/ports/java/openjdk8/ && make install clean
# cd /usr/ports/security/openssl/ && make install clean

Packages:

# pkg install go
# pkg install node && pkg install npm && npm i -g node-gyp
# pkg install php73
# pkg install perl5
# pkg install python
# pkg install ruby25
# pkg install openjdk8
# pkg install openssl

Solaris

# pkg install gcc
# pkg install golang
# pkg install php-71
# pkg install ruby
# pkg install jdk-8
# pkg install openssl

Also, use gmake instead of make when building and installing Unit on Solaris.

Configuring Sources§

First, run system checks and create the Makefile that you will update during language module setup:

$ ./configure <command-line options>

General ./configure options:

--help

Displays a summary of common ./configure options.

For language-specific details, run ./configure <language> --help or see below.

These options control the compilation process:

--cc=pathname

Specific C compiler pathname.

The default value is cc.

--cc-opt=options, --ld-opt=options

Additional C compiler and linker options.

The default values are empty strings.

The following option pair controls Unit’s runtime privileges:

--group=name, --user=name

Group name and username to run Unit’s non-privileged processes.

The default values are user’s primary group and nobody, respectively.

These flags enable or disable support of certain features:

`--debug`	Enables the debug log.
`--no-ipv6`	Disables IPv6 support.
`--no-unix-sockets`
	Disables Unix domain sockets support.
`--openssl`	Enables OpenSSL support. Make sure that OpenSSL (1.0.1 and later) header files and libraries are available in your compiler’s search path. To customize the path, provide the `--cc-opt` and `--ld-opt` options; alternatively, set `CFLAGS` and `LDFLAGS` environment variables before running ./configure. For details, see SSL/TLS and Certificates.

The last option group customizes Unit’s runtime directory structure:

`--prefix=prefix`
	Destination directory prefix for path options: `--bindir`, `--sbindir`, `--libdir`, `--incdir`, `--modules`, `--state`, `--pid`, `--log`, and `--control`. The default value is an empty string.
`--bindir=directory, --sbindir=directory`
	Directory paths for end-user and sysadmin executables. The default values are `bin` and `sbin`, respectively.
`--control=socket`
	Control API socket address; Unix (with `unix:` prefix), IPv4, or IPv6 socket can be used: # unitd --control unix:/path/to/control.unit.sock # unitd --control 127.0.0.1:8080 # unitd --control [::1]:8080 Warning For security reasons, avoid opening sockets on public interfaces in production. The default value is `unix:control.unit.sock`, created as `root` with `600` permissions.
`--incdir=directory, --libdir=directory`
	Directory paths for libunit header files and libraries. The default values are `include` and `lib`, respectively.
`--log=pathname`	Pathname for Unit’s log. The default value is `unit.log`.
`--modules=directory`
	Directory path for Unit’s language modules. The default value is `modules`.
`--pid=pathname`	Pathname for the PID file of Unit’s daemon process. The default value is `unit.pid`.

--state=directory

Directory path for Unit’s state storage. It contains runtime configuration, certificates, and other records; if you migrate your installation, simply copy the entire directory.

Warning

Unit state includes sensitive data; it must be owned by root with 700 permissions. Avoid updating the directory contents by outside means; instead, use Unit’s config API to ensure data consistency.

The default value is state.

Directory Structure§

To customize Unit installation and runtime directories, you can both:

Set the --prefix and path options (their relative settings are prefix-based) during configuration to set up the runtime file structure: Unit will use these settings to locate its modules, state, and other files.
Set the DESTDIR variable during installation. Unit’s file structure will be placed at the specified directory, which can be either the final installation target or an intermediate staging location.

Coordinate these two options as necessary to customize the directory structure. One common scenario is installation based on absolute paths.

Set absolute runtime paths with --prefix and path options:
```
$ ./configure --state=/var/lib/unit --log=/var/log/unit.log \
              --control=unix:/run/control.unit.sock --prefix=/usr/local/
```
This configuration will access its state, log, and control socket at custom locations; other files will be accessed by default prefix-based paths: /usr/local/sbin/, /usr/local/modules/, and so on.
For further packaging or containerization, specify DESTDIR at installation to place the files in a staging location while preserving their relative structure. Otherwise, omit DESTDIR for direct installation.

An alternative scenario is a build that you can move around the filesystem.

Set relative runtime paths with --prefix and path options:
```
$ ./configure --state=config --log=log/unit.log \
              --control=unix:control/control.unit.sock --prefix=movable
```
This configuration will access its files by prefix-based paths (both default and custom): <working directory>/movable/sbin/, <working directory>/movable/config/, and so on.
Specify DESTDIR while installing the build. You can relocate such builds when needed, making sure to move the entire file structure and start binaries from the base directory so that relative paths stay valid:
```
$ cd <DESTDIR>
# movable/sbin/unitd <command-line options>
```

You can combine these approaches; however, take care to understand how your settings work together.

Configuring Modules§

Next, configure a module for each language you want to use with Unit. The ./configure <language> commands set up individual language modules and place module-specific instructions in the Makefile.

Note

Unit can run apps in several versions of a language if you build and install a module for each version.

Configuring Go§

When you run ./configure go, Unit sets up the Go package that your applications will use to run in Unit. To use the package, install it in your Go environment. Available configuration options:

--go=pathname

Specific Go executable pathname, also used for targets in make commands.

The default value is go.

--go-path=directory

Custom directory path for Go package installation.

The default value is $GOPATH.

Note

The ./configure script doesn’t alter the GOPATH environment variable. The two paths (configuration-time --go-path and compile-time GOPATH) must be coherent at build time for Go to locate the Unit package.

Configuring Java§

When you run ./configure java, the script configures a module to support running Java Web Applications in Unit. Available command options:

`--home=directory`
	Directory path for Java utilities and header files (required to build the module). The default value is the `java.home` setting.
`--jars=directory`
	Directory path for Unit’s custom `.jar` files. The default value is the Java module path.
`--lib-path=directory`
	Directory path for the `libjvm.so` library. The default value is derived from JDK settings.
`--local-repo=directory`
	Directory path for local `.jar` repository. The default value is `$HOME/.m2/repository/`.
`--repo=directory`
	URL path for remote Maven repository. The default value is `http://central.maven.org/maven2/`.
`--module=filename`
	Name of the Java module to be built (`<module>.unit.so`), also used for targets in make commands. The default value is `java`.

To configure a module called java11.unit.so with OpenJDK 11.0.1:

$ ./configure java --module=java11 \
                   --home=/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home

Configuring Node.js§

When you run ./configure nodejs, Unit sets up the unit-http module that your applications will use to run in Unit. Available configuration options:

`--local=directory`
	Local directory path for Node.js module installation. By default, the module is installed globally (recommended).
`--node=pathname`
	Specific Node.js executable pathname, also used for targets in make commands. The default value is `node`.
`--npm=pathname`	Specific NPM executable pathname. The default value is `npm`.
`--node-gyp=pathname`
	Specific node-gyp executable pathname. The default value is `node-gyp`.

Configuring Perl§

When you run ./configure perl, the script configures a module to support running Perl scripts as applications in Unit. Available command options:

`--perl=pathname`
	Specific Perl executable pathname. The default value is `perl`.
`--module=filename`
	Name of the Perl module to be built (`<module>.unit.so`), also used for targets in make commands. The default value is the filename of the `perl` executable.

To configure a module called perl-5.20.unit.so for Perl 5.20.2:

$ ./configure perl --module=perl-5.20 \
                   --perl=perl5.20.2

Configuring PHP§

When you run ./configure php, the script configures a module to support running PHP applications in Unit via PHP’s embed SAPI. Available command options:

`--config=pathname`
	Pathname of the php-config script invoked to configure the PHP module. The default value is `php-config`.
`--lib-path=directory`
	Directory path of PHP’s embed SAPI library file (`libphp<version>.so` or `.a`).
`--lib-static`	Links the static embed SAPI library (`libphp<version>.a`); requires `--lib-path`. If this option is omitted, dynamic SAPI library (`libphp<version>.so`) is used.
`--module=filename`
	Name of the PHP module to be built (`<module>.unit.so`), also used for targets in make commands. The default value is `config`’s filename without the -config suffix (thus, `/usr/bin/php7-config` yields `php7`).

To configure a module called php70.unit.so for PHP 7.0:

$ ./configure php --module=php70 \
                  --config=/usr/lib64/php7.0/bin/php-config \
                  --lib-path=/usr/lib64/php7.0/lib64

Configuring Python§

When you run ./configure python, the script configures a module to support running Python scripts as applications in Unit. Available command options:

`--config=pathname`
	Pathname of the python-config script invoked to configure the Python module. The default value is `python-config`.
`--lib-path=directory`
	Custom directory path of the Python runtime library to use with Unit.
`--module=filename`
	Name of the Python module to be built (`<module>.unit.so`), also used for targets in make commands. The default value is `config`’s filename without the -config suffix (thus, `/usr/bin/python3-config` yields `python3`).

To configure a module called py33.unit.so for Python 3.3:

$ ./configure python --module=py33 \
                     --config=python-config-3.3

Configuring Ruby§

When you run ./configure ruby, the script configures a module to support running Ruby scripts as applications in Unit. Available command options:

`--module=filename`
	Name of the Ruby module to be built (`<module>.unit.so`), also used for targets in make commands. The default value is the filename of the `ruby` executable.
`--ruby=pathname`
	Specific Ruby executable pathname. The default value is `ruby`.

To configure a module called ru23.unit.so for Ruby 2.3:

$ ./configure ruby --module=ru23 \
                   --ruby=ruby23

Building and Installing Unit§

To build Unit executables and language modules that you have ./configure’d earlier and install them:

$ make
# make install

You can also build and install language modules individually; the specific method depends on whether the language module is embedded in Unit or packaged externally.

Note

For further details about Unit language modules, see Working With Language Modules.

Embedded Language Modules§

To build and install Unit modules for Java, PHP, Perl, Python, or Ruby after configuration, run make <module> and make <module>-install, for example:

$ make perl-5.20
# make perl-5.20-install

External Language Modules§

To build and install Unit modules for Go and Node.js after configuration, run make <go>-install and make <node>-install, for example:

# make go-install
# make node-install

Note

To install the Node.js module locally, run make <node>-local-install:

# make node-local-install

If you haven’t specified the local directory with ./configure nodejs earlier, provide it here: DESTDIR=/your/project/directory. If both options are specified, DESTDIR prefixes the local value.

However, the recommended method is global installation.

If you customize the executable pathname with go or node, use the following pattern:

$ ./configure nodejs --node=/usr/local/bin/node8.12
# make /usr/local/bin/node8.12-install

$ ./configure go --go=/usr/local/bin/go1.7
# make /usr/local/bin/go1.7-install

Startup§

We advise installing Unit from precompiled packages; in this case, startup is configured automatically.

Even if you install Unit otherwise, manual startup isn’t recommended. Instead, configure a service manager such as OpenRC or systemd or create an rc.d script to launch the Unit daemon using the options below.

Run unitd as root from the sbin installation subdirectory. Usually, default compile-time settings don’t require override; use the --help option to review their values. For details and security notes, see here.

General options:

`--help, -h`	Displays a summary of Unit’s command-line options and their default values that were configured at compile time.
`--no-daemon`	Runs Unit in non-daemon mode.
`--version`	Displays Unit version and ./configure settings it was built with.

The following options override compile-time settings:

`--control socket`
	Address of the control API socket. IPv4, IPv6, and Unix domain sockets are supported: # unitd --control unix:/path/to/control.unit.sock # unitd --control 127.0.0.1:8080 # unitd --control [::1]:8080
`--group name, --user name`
	Group name and user name used to run Unit’s non-privileged processes.
`--log pathname`	Pathname for the Unit log.
`--modules directory`
	Directory path for Unit language modules (`<module>.unit.so` files).
`--pid pathname`	Pathname for the PID file of Unit’s main process.
`--state directory`
	Directory path for Unit state storage.

Installation§

Prerequisites§

Docker Images§

Initial Configuration§

Official Packages§

Amazon Linux§

CentOS§

Debian§

Fedora§

RHEL§

Ubuntu§

Node.js at npm§

Startup and Shutdown§

Community Repositories§

Alpine Linux§

Arch Linux§

CentOS/RHEL SCLs§

FreeBSD§

Gentoo§

NixOS/Nix§

Remi’s RPM Repo§

Source Code§

Getting Sources§

Installing Required Software§

Configuring Sources§

Directory Structure§

Configuring Modules§

Configuring Go§

Configuring Java§

Configuring Node.js§

Configuring Perl§

Configuring PHP§

Configuring Python§

Configuring Ruby§

Building and Installing Unit§

Embedded Language Modules§

External Language Modules§

Startup§