Ninox Private Cloud on Premise - Installation

System Requirements

Supported Operating Systems
  • Windows Server 2008 or later

Minimum Hardware Requirements:

  • 4 GB RAM
  • 2 vCores
  • 100 MBit network connection
  • 120 MB free disk space for the installation files
  • 10 GB free disk space for application data (actual requirement depends heavily on the use case, a scalable store solution is recommended)

Environment dependencies:

  • DNS name
  • Free port (e.g. 80 or 443, other ports can be configured as well)
  • HTTP(S) connectivity client => server
  • SSL certificate (#PKCS12 / .pfx) with or without private key passphrase (note: passphrase will be stored as plain text in the configuration file)
  • SMTP server with or without authentication


  • Ninox data files should be stored on SSD storage
  • Implement a backup strategy, we recommend to have at least two layers of backup
  • VM snapshots
  • File system based incremental backups of the data directory
  • Implement a fail-over strategy

Network Configuration:

Ninox client/server communication is based on HTTP(S).
There are multiple ways to configure a Ninox installation, however the following properties must be given:
  • Clients must be able to connect to the Ninox server by HTTPS via TCP/IP.
  • A DNS name for the Ninox server (or the first component in the configuration that terminates the client connection) that reliably resolves to the server's IP.
  • Static IP addresses are highly encouraged, DynDNS is not recommended.
  • If clients connect from the Internet and intranet, they need to use the same address / DNS name.
A) Simple setup
Client —HTTPS—> Server
The basic configuration requires, that Ninox Server exposes a port for HTTP communication on the internet or private network.
B) Forward Proxy setup
Client —HTTPS—> Forward Proxy —HTTPS—> Server
This setup is recommended for installing a Ninox server in a corporate intranet.
C) DMZ setup
Client —HTTPS—> Reverse Proxy —HTTP—>Server
In a DMZ environment, a reverse proxy will terminate any client-side communication. This is the recommended configuration for environments that already implemented a DMZ. There are multiple advantages: Centralized certificate management on the reverse proxy Reverse proxy can act as a security component with traffic inspection

Requirements for reverse proxy:

  • Allow all HTTP methods (GET, PUT, POST, DELETE, OPTIONS, HEAD)
  • TCP timeouts must be higher than 60 secs
  • No path rewriting rules, Ninox cannot be mounted on a sub-path
  • Ninox may use heavily parallel TCP connections. Make sure that the reverse proxy is capable of handling those (calculate at least 2 concurrent connections per concurrent client)

Configuration File

Edit the server-config.json file in the installation directory.
Remarks: The file must be a UTF-8 encoded JSON format compliant file. It must not involve proprietary UTF-8 encoding headers. On Windows, please don't use Notepad to edit this file, instead use Notepad++ or SublimeText to edit the file.
The file provides the following configuration options:
"data": "data",
"ssl": false,
"host": "localhost",
"port": 8080,
"bindPort": 8080,
"bindInterface": "",
"redirectPort": 9090,
"workers": 2,
"emailHost": "",
"emailPort": null,
"emailSecure": true,
"emailUser": "",
"emailPassword": "",
"emailFrom": "",
"apiAuthorization": "Bearer 123456789123456789",
"die": 60000
data: Absolute path (or relative from the installation path) of the data directory.
ssl: Either false to not use SSL or
"passphrase": "passphrase"
"key": "private.key"
"ca": "ca.pem"
"cert": "cert.pem"
passphrase: Passphrase of the encrypted key
key: Path of the key file
ca: Path of the CA certificate (if not included in the certificate file)
cert: PEM encoded certificate (may include chain)
host: The publicly visible domain name
port: The publicly visible port
bindPort: The local port, the HTTP server should bind to (usually the same as port)
bindInterface: The local network interface, the HTTP server should bind to (use "" to make available on all interfaces.
redirectPort: If set and SSL is activated, the server will start a secondary HTTP server on that port which redirects any request to the SSL port.
workers: the number of HTTP worker processes, at least one, should not exceed the number of available cores. 4 should be sufficient even for major setups.
emailHost: The host of the outgoing SMTP server
emailPort: The port of the outgoing SMTP server
emailSecure: Use SSL
emailUser: SMTP authentication user
emailPassword: SMTP authentication password
emailFrom: The sender's address, e.g. [email protected]
apiAuthorization: An optional authorization method for Ninox API calls. The value will be compared to the HTTP Authorization header.
die: The number of milliseconds, a Ninox team will be kept alive after the latest request has ended. Should be at least 60000.
Though not required, it's encouraged to secure Ninox client/server communication with SSL. This requires to deploy a SSL certificate with the server. Ninox supports two types of certificate formats:
"ssl": {
"pfx": "certificate.pfx",
"passphrase": "secret"
"ssl": {
"ca": "ca-certificates.cer",
"cert": "certificate.cer",
"key": "private.key",
"passphrase": "secret"
Export as PDF
Copy link