Nginx Proxy¶
Dokku uses nginx as its server for routing requests to specific applications. By default, access and error logs are written for each app to /var/log/nginx/${APP}-access.log and /var/log/nginx/${APP}-error.log respectively
nginx:access-logs <app> [-t] # Show the nginx access logs for an application (-t follows)
nginx:error-logs <app> [-t] # Show the nginx error logs for an application (-t follows)
nginx:report [<app>] [<flag>] # Displays a nginx report for one or more apps
nginx:set <app> <property> (<value>) # Set or clear an nginx property for an app
nginx:show-config <app> # Display app nginx config
nginx:start # Starts the nginx server
nginx:stop # Stops the nginx server
nginx:validate-config [<app>] [--clean] # Validates and optionally cleans up invalid nginx configurations
Usage¶
Warning
As using multiple proxy plugins on a single Dokku installation can lead to issues routing requests to apps, doing so should be avoided.
Request Proxying¶
By default, the web process is the only process proxied by the nginx proxy implementation. Proxying to other process types may be handled by a custom nginx.conf.sigil file, as generally described below
Nginx will proxy the requests in a round-robin balancing fashion to the different deployed (scaled) containers running the web proctype. This way, the host's resources can be fully leveraged for single-threaded applications (e.g. dokku ps:scale node-js-app web=4 on a 4-core machine).
Note
Due to how the plugin is implemented, if an app successfully starts up web containers but fails to deploy some other containers, nginx may eventually stop routing requests. Users should revert their code in these cases, or manually trigger dokku proxy:build-config $APP in order to ensure requests route to the new web containers.
Starting nginx¶
New
Introduced in 0.28.0
The nginx server can be started via nginx:start.
Stopping nginx¶
New
Introduced in 0.28.0
The nginx server can be stopped via nginx:stop.
Binding to specific addresses¶
New
Introduced in 0.19.2
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
By default, nginx will listen to all interfaces ([::] for IPv6, 0.0.0.0 for IPv4) when proxying requests to applications. This may be changed using the bind-address-ipv4 and bind-address-ipv6 properties. This is useful in cases where the proxying should be internal to a network or if there are multiple network interfaces that should respond with different content.
dokku nginx:set node-js-app bind-address-ipv4 127.0.0.1
dokku nginx:set node-js-app bind-address-ipv6 ::1
This may be reverted by setting an empty bind address.
Warning
Validation is not performed on either value.
Users with apps that contain a custom nginx.conf.sigil file will need to modify the files to respect the new NGINX_BIND_ADDRESS_IPV4 and NGINX_BIND_ADDRESS_IPV6 variables.
HSTS Header¶
New
Introduced in 0.20.0
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
If SSL certificates are present, HSTS will be automatically enabled. It can be toggled via nginx:set:
The following options are also available via the nginx:set command:
hsts(type: boolean, default:true): Enables or disables HSTS for your application.hsts-include-subdomains(type: boolean, default:true): Tells the browser that the HSTS policy also applies to all subdomains of the current domain.hsts-max-age(type: integer, default:15724800): Time in seconds to cache HSTS configuration.hsts-preload(type: boolean, default:false): Tells most major web browsers to include the domain in their HSTS preload lists.
Beware that if you enable the header and a subsequent deploy of your application results in an HTTP deploy (for whatever reason), the way the header works means that a browser will not attempt to request the HTTP version of your site if the HTTPS version fails until the max-age is reached.
Globally disabling the HSTS Header¶
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
HSTS Header can be disabled for all apps by setting the hsts property to false after passing the --global flag to nginx:set.
Once the HSTS setting is disabled globally, it can be re-enabled on a per-app basis by setting the hsts property as normal.
Running behind another proxy — configuring X-Forwarded-* headers:¶
Dokku's default Nginx configuration passes the de-facto standard HTTP headers X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port to your application.
These headers indicate the IP address of the original client making the request, the protocol of the original request (HTTP or HTTPS), and the port number of the original request, respectively.
If you have another HTTP proxy sitting in between the end user and your server (for example, a load balancer, or a CDN), then the values of these headers will contain information about (e.g. the IP address of) the the closest proxy, and not the end user.
To fix this, assuming that the other proxy also passes X-Forwarded-* headers, which in turn contain information about the end user, you can tell Nginx include those values in the X-Forwarded-* headers that it sends to your application. You can do this via nginx:set, like so:
dokku nginx:set node-js-app x-forwarded-for-value '$http_x_forwarded_for'
dokku nginx:set node-js-app x-forwarded-port-value '$http_x_forwarded_port'
dokku nginx:set node-js-app x-forwarded-proto-value '$http_x_forwarded_proto'
However, note that you should only do this if:
- Requests to your website always go through a trusted proxy.
- That proxy is configured to send the aforementioned
X-Forwarded-*headers.
Otherwise, if it's possible for clients to make HTTP requests directly against your server, bypassing the other proxy, or if the other proxy is not configured to set these headers, then a client can basically pass any arbitrary values for these headers (which your app then presumably reads) and thereby fake an IP address, for example.
There's also the X-Forwarded-Ssl header which a less common alternative to X-Forwarded-Proto — and because of that, isn't included in Dokku's default Nginx configuration.
But you can tell Nginx to send this header as well, if necessary.
# force-setting value to `on`
dokku nginx:set node-js-app x-forwarded-ssl on
# force-setting value to `off`
dokku nginx:set node-js-app x-forwarded-ssl off
# removing the value from nginx.conf (default)
dokku nginx:set node-js-app x-forwarded-ssl
Checking access logs¶
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
You may check nginx access logs via the nginx:access-logs command. This assumes that app access logs are being stored in /var/log/nginx/$APP-access.log, as is the default in the generated nginx.conf.
You may also follow the logs by specifying the -t flag.
Checking error logs¶
You may check nginx error logs via the nginx:error-logs command. This assumes that app error logs are being stored in /var/log/nginx/$APP-error.log, as is the default in the generated nginx.conf.
You may also follow the logs by specifying the -t flag.
Changing log path¶
New
Introduced in 0.20.1
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
The path to where log files are stored can be changed by calling the nginx:set command with the following options:
access-log-path(type: string, default:${NGINX_LOG_ROOT}/${APP}-access.log): Log path for nginx access logserror-log-path(type: string, default:${NGINX_LOG_ROOT}/${APP}-error.log): Log path for nginx error logs
The defaults should not be changed without verifying that the paths will be writeable by nginx. However, this setting is useful for enabling or disabling logging by setting the values to off.
The default value may be set by passing an empty value for the option:
In all cases, the nginx config must be regenerated after setting the above values.
Changing log format¶
New
Introduced in 0.22.0
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
The format of the access log can be changed by calling the nginx:set command as follows:
Prior to changing the log-format, log formats should be specified at a file such as /etc/nginx/conf.d/00-log-formats.conf. This will ensure they are available within your app's nginx context. For instance, the following may be added to the above file. It only needs to be specified once to be used for all apps.
# /etc/nginx/conf.d/00-log-formats.conf
# escape=json was added in nginx 1.11.8
log_format json_combined escape=json
'{'
'"time_local":"$time_local",'
'"remote_addr":"$remote_addr",'
'"remote_user":"$remote_user",'
'"request":"$request",'
'"status":"$status",'
'"body_bytes_sent":"$body_bytes_sent",'
'"request_time":"$request_time",'
'"http_referrer":"$http_referer",'
'"http_user_agent":"$http_user_agent"'
'}';
Next, the format should be set for the given app.
Finally, a proxy rebuild will change the format as desired.
Specifying a read timeout¶
New
Introduced in 0.21.0
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
When proxying requests to your applications, it may be useful to specify a proxy read timeout. This can be done via the nginx:set command as follows:
The default value is 60s, and all numeric values must have a trailing time value specified (s for seconds, m for minutes).
The default value may be set by passing an empty value for the option:
In all cases, the nginx config must be regenerated after setting the above value.
Specifying a custom client_max_body_size¶
New
Introduced in 0.23.0
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
Users can override the default client_max_body_size value - which limits file uploads - via nginx:set. Changing this value will only apply to every server stanza of the default nginx.conf.sigil; users of custom nginx.conf.sigil files must update their templates to support the new value.
The default value is empty string, which will result in nginx falling back to any configured, higher-level defaults (or 1m if unconfigued; all numerical values must have a size unit specified (k for kilobytes, m for megabytes).
The default value may be set by passing an empty value for the option:
In all cases, the nginx config must be regenerated after setting the above value.
Changing this value when using the PHP buildpack (or any other buildpack that uses an intermediary server) will require changing the value in the server config shipped with that buildpack. Consult your buildpack documentation for further details.
Showing the nginx config¶
For debugging purposes, it may be useful to show the nginx config. This can be achieved via the nginx:show-config command.
Validating nginx configs¶
It may be desired to validate an nginx config outside of the deployment process. To do so, run the nginx:validate-config command. With no arguments, this will validate all app nginx configs, one at a time. A minimal wrapper nginx config is generated for each app's nginx config, upon which nginx -t will be run.
As app nginx configs are actually executed within a shared context, it is possible for an individual config to be invalid when being validated standalone but also be valid within the global server context. As such, the exit code for the nginx:validate-config command is the exit code of nginx -t against the server's real nginx config.
The nginx:validate-config command also takes an optional --clean flag. If specified, invalid nginx configs will be removed.
Warning
Invalid app nginx config's will be removed even if the config is valid in the global server context.
The --clean flag may also be specified for a given app:
Customizing the nginx configuration¶
New
Introduced in 0.5.0
Dokku uses a templating library by the name of sigil to generate nginx configuration for each app. This may be overriden by committing the default configuration template to a file named nginx.conf.sigil in the root of the app repository.
When deploying a monorepo, it may be desirable to specify the specific path of the nginx.conf.sigil file to use for a given app. This can be done via the nginx:set command. If a value is specified and that file does not exist in the app's build directory, Dokku will continue the build process as if the repository has no nginx.conf.sigil.
For deploys via the git:from-image and git:load-image commands, the nginx.conf.sigil is extracted from the configured WORKDIR property of the image. For all other deploys - git push, git:from-archive, git:sync - will have the nginx.conf.sigil extracted directly from the source code. Both cases will respect the configured nginx-conf-sigil-path property value.
This property can also be changed globally, which will take into effect if there is no value at the app level.
In either case, the value can be reset by specifying an empty value.
Info
The default template may change with new releases of Dokku. Please refer to the appropriate template file version for your Dokku version, and make sure to look out for changes when you upgrade.
Disabling custom nginx config¶
Note
Changing this value globally or on a per-app basis will require rebuilding the nginx config via the proxy:build-config command.
While enabled by default, using a custom nginx config can be disabled via nginx:set. This may be useful in cases where you do not want to allow users to override any higher-level customization of app nginx config.
# enable fetching custom config (default)
dokku nginx:set node-js-app disable-custom-config false
# disable fetching custom config
dokku nginx:set node-js-app disable-custom-config true
Unsetting this value is the same as enabling custom nginx config usage.
Available template variables¶
{{ .APP }} Application name
{{ .APP_SSL_PATH }} Path to SSL certificate and key
{{ .DOKKU_ROOT }} Global Dokku root directory (ex: app dir would be `{{ .DOKKU_ROOT }}/{{ .APP }}`)
{{ .PROXY_PORT }} Non-SSL nginx listener port (same as `DOKKU_PROXY_PORT` config var)
{{ .PROXY_SSL_PORT }} SSL nginx listener port (same as `DOKKU_PROXY_SSL_PORT` config var)
{{ .NOSSL_SERVER_NAME }} List of non-SSL VHOSTS
{{ .PROXY_PORT_MAP }} List of port mappings (same as `DOKKU_PROXY_PORT_MAP` config var)
{{ .PROXY_UPSTREAM_PORTS }} List of configured upstream ports (derived from `DOKKU_PROXY_PORT_MAP` config var)
{{ .RAW_TCP_PORTS }} List of exposed tcp ports as defined by Dockerfile `EXPOSE` directive (**Dockerfile apps only**)
{{ .SSL_INUSE }} Boolean set when an app is SSL-enabled
{{ .SSL_SERVER_NAME }} List of SSL VHOSTS
Finally, each process type has it's network listeners - a list of IP:PORT pairs for the respective app containers - exposed via an .DOKKU_APP_${PROCESS_TYPE}_LISTENERS variable - the PROCESS_TYPE will be upper-cased with hyphens transformed into underscores. Users can use the new variables to expose non-web processes via the nginx proxy.
Note
Application environment variables are available for use in custom templates. To do so, use the form of {{ var "FOO" }} to access a variable named FOO.
Customizing via configuration files included by the default templates¶
The default nginx.conf template will include everything from your apps nginx.conf.d/ subdirectory in the main server {} block (see above):
That means you can put additional configuration in separate files. To increase the client request header timeout, the following can be performed:
mkdir /home/dokku/node-js-app/nginx.conf.d/
echo 'client_header_timeout 50s;' > /home/dokku/node-js-app/nginx.conf.d/timeout.conf
chown dokku:dokku /home/dokku/node-js-app/nginx.conf.d/upload.conf
service nginx reload
The example above uses additional configuration files directly on the Dokku host. Unlike the nginx.conf.sigil file, these additional files will not be copied over from your application repo, and thus need to be placed in the /home/dokku/node-js-app/nginx.conf.d/ directory manually.
For PHP Buildpack users, you will also need to provide a Procfile and an accompanying nginx.conf file to customize the nginx config within the container. The following are example contents for your Procfile
Your nginx.conf file - not to be confused with Dokku's nginx.conf.sigil - would also need to be configured as shown in this example:
client_header_timeout 50s;
location / {
index index.php;
try_files $uri $uri/ /index.php$is_args$args;
}
Please adjust the Procfile and nginx.conf file as appropriate.
Custom Error Pages¶
By default, Dokku provides custom error pages for the following three categories of errors:
- 4xx: For all non-404 errors with a 4xx response code.
- 404: For "404 Not Found" errors.
- 5xx: For all 5xx error responses
These are provided as an alternative to the generic Nginx error page, are shared for all applications, and their contents are located on disk at /var/lib/dokku/data/nginx-vhosts/dokku-errors. To customize them for a specific app, create a custom nginx.conf.sigil as described above and change the paths to point elsewhere.
Default site¶
By default, Dokku will route any received request with an unknown HOST header value to the lexicographically first site in the nginx config stack. This means that accessing the dokku server via its IP address or a bogus domain name may return a seemingly random website.
Warning
some versions of Nginx may create a default site when installed. This site is simply a static page which says "Welcome to Nginx", and if this default site is enabled, Nginx will not route any requests with an unknown HOST header to Dokku. If you want Dokku to receive all requests, run the following commands:
If services should only be accessed via their domain name, you may want to disable the default site by adding the following configuration to the global nginx configuration.
Create the file at /etc/nginx/conf.d/00-default-vhost.conf:
server {
listen 80 default_server;
listen [::]:80 default_server;
# If services hosted by dokku are available via HTTPS, it is recommended
# to also uncomment the following section.
#
# Please note that in order to let this work, you need an SSL certificate. However
# it does not need to be valid. Users of Debian-based distributions can install the
# `ssl-cert` package with `sudo apt install ssl-cert` to automatically generate
# a self-signed certificate that is stored at `/etc/ssl/certs/ssl-cert-snakeoil.pem`.
#
#listen 443 ssl;
#listen [::]:443 ssl;
#ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
#ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
server_name _;
access_log off;
return 444;
}
Make sure to reload nginx after creating this file by running systemctl reload nginx.service.
This will catch all unknown HOST header values and close the connection without responding. You can replace the return 444; with return 410; which will cause nginx to respond with an error page.
The configuration file must be loaded before /etc/nginx/conf.d/dokku.conf, so it can not be arranged as a vhost in /etc/nginx/sites-enabled that is only processed afterwards.
Alternatively, you may push an app to your Dokku host with a name like "00-default". As long as it lists first in ls /home/dokku/*/nginx.conf | head, it will be used as the default nginx vhost.
Other¶
Domains plugin¶
See the domain configuration documentation for more information on how to configure domains for your app.
Customizing hostnames¶
See the customizing hostnames documentation for more information on how to configure domains for your app.
Disabling VHOSTS¶
See the disabling vhosts documentation for more information on how to disable domain usage for your app.
SSL Configuration¶
See the ssl documentation for more information on how to configure SSL certificates for your application.
Disabling Nginx¶
See the proxy documentation for more information on how to disable nginx as the proxy implementation for your app.
Managing Proxy Port mappings¶
See the proxy documentation for more information on how to manage ports proxied for your app.
Regenerating nginx config¶
See the proxy documentation for more information on how to rebuild the nginx proxy configuration for your app.