10 GB free disk space for application data (actual requirement depends heavily on the use case, a scalable store solution is recommended)
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
File system based incremental backups of the data directory
Implement a fail-over strategy
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)
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:
"apiAuthorization": "Bearer 123456789123456789",
data: Absolute path (or relative from the installation path) of the data directory.
ssl: Either false to not use SSL or
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 "0.0.0.0" 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.