The UniFi® Software-Defined Networking (SDN) platform is an end-to-end system of network devices across different locations — all controlled from a single interface.
NOTE: latest
may contain a beta release. If you wish for stability use a specific tag!
7.2.92
7.2.91
7.1, 7.1.68
7.1.67
7.1.66
7.1.65
7.1.61
7.0, 7.0.25
7.0.23
6.5, 6.5.55
6.5.54
6.4, 6.4.54
6.2, 6.2.26
6.2.25
6.2.23
- Where to get help: The UniFi Community Forums
- Where to file issues: https://github.com/stellirin/unifi-controller/issues
- Maintained by: Adam Farden
- Supported architectures:
amd64
The UniFi Network Controller is the front end for the UniFi Software-Defined Networking (SDN) platform, an end-to-end system of network devices across different locations.
This project is not an official container image, nor is it associated with Ubiquiti in any way. It was created by reverse engineering the original UniFi scripts.
Motivation for this project comes from the limitations of the source DEB. Specifically, the DEB is restricted to use obsolete versions of MongoDB because of how the UniFi scripts connect to a locally installed DB. However, UniFi runs perfectly fine on even the latest MongoDB v5.0 when connecting to a 'remote' MongoDB installation (i.e. via URI instead of socket).
By default the controller will generate untrusted TLS certificates. This container can also use trusted certificates, for example from Let's Encrypt. The container will also watch any provided certificates for changes and trigger a restart.
- Aarch64 for Raspberry Pi
This container image must be used in conjunction with an existing MongoDB installation. Despite the DEB provided by Ubiquiti being limited to MongoDB 3.6, the UniFi Network Controller works fine on the latest MongoDB 5.0 releases.
The simplest method is to use a MongoDB container image. See the examples folder for tested methods of running this image.
When you start the image, you can adjust the initialization of the instance by passing one or more environment variables.
Host name of the MongoDB installation.
Default value is localhost
.
Port of the MongoDB installation.
Default value is 27017
.
The database name on the MongoDB installation.
Default value is unifi
.
Username for authentication on the MongoDB installation.
No default value.
Password for authentication on the MongoDB installation.
No default value.
Additional MongoDB connection arguments.
No default value.
Full URI for the MongoDB installation. For more complex installations. It can be a single host or multiple hosts in a Replica Set.
Default value will be generated as mongodb://localhost:27017
unless other MongoDB variables are specified above.
Full URI to the MongoDB stat installation. For more complex installations. It can be a single host or multiple hosts in a Replica Set.
Default is to take the same value as MONGO_DB_URI
.
The port used for the controller UI. By default a container runs without the required privileges to bind to the default HTTPS port. If your container runs with privileges you can change this to use port 443
.
Typically port 443
is achieved at the container platform level (bind external port 443
to internal port 8443
) but this is useful if you are using Docker with --network="host"
and --cap-add="NET_BIND_SERVICE"
.
Default value is 8443
.
The path to a full chain certificate that is used for TLS connections to the UI. If no value is supplied then UniFi will generate an untrusted certificate for testing purposes.
No default value.
The path to a private key that is used for TLS connections to the UI. If no value is supplied then UniFi will generate an untrusted certificate for testing purposes.
No default value.
Provide an alternative source of randomness. Java will use /dev/random
on some linux systems, which is a blocking function and may cause slowdowns. A good alternative is to use /dev/./urandom
which will not block.
No default value.
Provide additional JVM options.
No default value.
As an alternative to passing sensitive information via environment variables, _FILE
may be appended to some of the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from secrets stored in /run/secrets/<secret_name>
files. For example:
docker run --name unifi-controller -e MONGO_DB_PASS_FILE=/run/secrets/mongo-db-password -d stellirin/unifi-controller:latest
Currently, this is only supported for MONGO_DB_HOST
, MONGO_DB_PORT
, MONGO_DB_NAME
, MONGO_DB_USER
, MONGO_DB_PASS
, MONGO_DB_URI
, and MONGO_DB_STAT_URI
.