The config file is typically found:


Can have as many server contexts as needed:

# main context

http {

    # http context

    server {

        # first server context


    server {

        # second server context



Generally these are configured in separate files in


Alias vs Root

be sure to include trailing slash with alias directives!



For local development environments, self signed is good enough. It makes sure that the application is configured correctly to work behind an HTTPS connection, but doesn't require an external certificate / local DNS entry.

Use OpenSSL to create a self signed certificate

openssl req -subj '/CN=localhost' -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem -days 365

Let's Encrypt

Once it's time to publish your application, you'll need a domain name. If you have that ready to go, you can use Let's Encrypt for a certificate

Static Content

When developing web applications, it's tempting to use the application server to serve static content:

This works for local development, but becomes a headache when it's time to deploy your application publicly.

Using a dedicated webserver like nginx for serving static files removes that burden from the application server.

See also:




Log files are typically stored in


With containers

docker-compose exec web bash


nginx -t 

is super helpful for debugging nginx configurations

To see if the nginx process is running:

service nginx status

(On the nginx docker container, ps is not available)

To reload nginx without reloading all of the containers:

docker-compose -p boilerplate exec web nginx -s reload

For netstat:

apt-get update
apt-get install net-tools

netstat -pan | grep LISTEN

See also dedicated section for nginx