Host a static site with Nginx subdomains and SSL

This is the beginning of a new series in which I will incrementally evolve an accessible and green static website. In order to optimize costs, save up energy and memory, we will mutualize hosting of several static sites on the same server. To do so we will configure nginx to host the static sites on different (sub)domains and secure them with SSL.

Also, having this kind of knowledge is a first step to own our own content and later, be able to create and IndieWeb site.


In this series, I will migrate my own website ( to a fresh new site ( I will later switch "next" to the main domain when the new site is ready.

I want to create a frugal website (following the 115 Green-IT best practices). I also want to make it accessible (following RGAA recommendations).

Since I want to learn Green IT and web accessibility, I think that "eating my own dogfood" is one of the best way to proceed. Beginning from scratch and moving incrementally in baby steps will help me not to be overwhelmed.

Also, I believe that making internet accessible and frugal as fast as we can is a way to help reaching the objectives of Paris Climate Aggrements. This should be at reach for anyone with a few development skills.

Accessibility and Green IT should be accessible.


  • 01 - Host a static site with Nginx subdomains and SSL


In this example my host provider is Linode. Nevertheless, the content of this article is mostly true for any linux based hosting machine (even a RaspberyPi).

If you want to do the same thing, you will need to fulfill some pre-requisites:

  • buy a domain
  • have ssh and sudo access to a linux machine (hosting service or self-hosted is OK)
  • git, make, certbot and Nginx service installed on the hosting machine

HTML content

I first created an initial basic index.html page. Later in the series, we may generate html files and perhaps have a few dynamic pages for specific purposes.


<!DOCTYPE html>
<html lang="en">
  <meta charset="UTF-8">
  <meta name="viewport"
        content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
<p>Hello World</p>

Deployment tasks with Makefile

To deploy this site will be very simple for now, we will just copy next/src/index.html to next/dist/index.html.

I update of the Makefile to "deploy" our simplistic site. I my current case, I just copy an index.html file in the location where the subdomain will lookup ofr html files.

Why do I use an old technology such as Makefile? It is commonly present in any linux machine. It can automate almost anything. It can hide multiple package managers and build commands(npm, maven, dotnet ...) behind a single entrypoint.


all: build next_deploy
# added next_build

changes=git diff-index --quiet HEAD

	git fetch

detect_changes: fetch
	$(shell ${changes})
ifneq (0,$?)
	@echo changes detected
	@echo no changes detected

checkout: detect_changes
	$(shell ${changes})
ifneq (0,$?)
	git reset --hard origin/master

# added
	rm -rf next/dist

# added
next_deploy: next_clean
	mkdir -p next/dist
	cp -r next/src/index.html next/dist/index.html

	npm install

build: install
	npm run build

	rm -rf node_modules

Deployment shell entry point

I use a runner bash script in order to

  • change directory to a specific folder
  • checkout latest git version and reset hard to HEAD of the main branch
  • build and deploy the main site (in my case
  • deploy the next site (in my case

Why this command? It allows to run predefined command with arguments from the CI/CD tool (in my case Gitlab). It hides the implementation details of the build and deploy commands (they are hidden in both and Makefile)

this_command_path=$(realpath $0)
this_folder=$(dirname $this_command_path)
cd $this_folder
make checkout
make build
# added here
make next_build

Hosting Dns configuration

Now we have some content, we want to host it online. I order to be found on the internet our site need to have an URL.

Setup multiple sites in the same host using nginx and subdomains.

Thanks to this article, I configured my DNS entries and Nginx virtual hosts.

Let's see what it looks like.

DNS Records

In the Dns panel of my domain provider, I added entries to match the IP adresses of the hosting machine to my main domain and a subdomain.

A/AAAA Records

First you need to know the public IP address of the hosting machine. In this example say the IP v4 is 999.999.999.999 and the IP v6 is xxxx:xxxx::xxxx:xxxx:xxxx:xxxx.

Your A/AAAA Dns entries may look like this:

Hostname IP Address Note 999.999.999.999 ip v4 xxxx:xxxx::xxxx:xxxx:xxxx:xxxx ip v6
next 999.999.999.999 ip v4
next xxxx:xxxx::xxxx:xxxx:xxxx:xxxx ip v6

CAA Records

See DNS Certification Authority Authorization.

In this entries I specify the authority to provide SSL certificates. In this case, wa are using Let’s Encrypt. If like me you love using this service, consider making a donation to make the web safer and more secure for everyone.

Name Tag Value issue
next issue

HTTP Server with Nginx

In my case, I use nginx to expose HTML content through HTTP. Since I use a subdomain, I need to configure it accordingly.

In this article I assume Nginx is already installed and runs as a service (sudo service nginx start|stop|restart).

Nginx static site with LetsEncrypt SSL certificate configuration file template.


server {
    server_name  {{server_name}};

    root   {{root_path}};
    index  index.html index.htm;

    location / {
       try_files $uri $uri/ =404;

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/{{root_cert_common_name}}/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/{{root_cert_common_name}}/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


server {
    if ($host = {{server_name}}) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name {{server_name}};
    listen 80;
    listen [::]:80;
    return 404; # managed by Certbot

Option 1: Replace manually {{server_name}} {{root_cert_common_name}} and {{root_path}} values with your own depending on your hosting.

Option 2 : Mustache compatible template engine

You can use a template engine such as mustache to automatically replace variable with actual value from a json or yml file. Example of values for the template variables:


  "server_name": "",
  "root_path": "/path/to/baldir/dist",
  "root_cert_common_name": ""


  "server_name": "",
  "root_path": "/path/to/next/baldir/dist",
  "root_cert_common_name": ""

In my case both and sites are static sites. I can generate 2 configuration files from the same template but with different values for {{server_name}} and {{root_path}}.

I chose a python implementation of the mustache templating engine called Chevron.

chevron -d infra/nginx/ infra/nginx/static-site-ssl-lets-encrypt.nginx.conf.mustache > /tmp/
chevron -d infra/nginx/ infra/nginx/static-site-ssl-lets-encrypt.nginx.conf.mustache > /tmp/

I also create a "catch all" configuration for when a wrong subdomain is queried.


server {
    listen 80 default_server;

    server_name _;

    return 410;

Moving generated nginx configuration files to nginx configuration folders.

sudo cp /tmp/ /etc/nginx/conf.d/
sudo cp /tmp/ /etc/nginx/conf.d/

# verify nginx configuration
sudo nginx -t

# expected result:
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

sudo service nginx restart

You can go to both and (to be replaced with your own domain). The content is visible, but the page is not secured.

Configure Let's Encrypt SLL certifiates with certbot

In order to be secured, you sites need to rely on a valid SSL certificate to secure the connection with HTTPS.

Don't worry, some smart people have made really cool tools to make it very simple.

Certbot command automates and simplifies configuration of SSL certificates from LetsEncrypt. Please refer to installation instructions of certbot to install the command line.

The first time you may configure your sites for nginx automatically with sudo certbot --nginx. Then you add or revoke certificates, you may use sudo certbot.

In my case I already have run sudo certbot --nginx once, so I will use sudo certbot.

The command and results should look like this.

sudo certbot

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Requesting a certificate for

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/
Key is saved at:         /etc/letsencrypt/live/
This certificate expires on 2022-07-11.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for to /etc/nginx/conf.d/
Congratulations! You have successfully enabled HTTPS on

Successfully deployed certificate for to /etc/nginx/conf.d/
Congratulations! You have successfully enabled HTTPS on

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:
 * Donating to EFF:          
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

You can now visit both and (replace with your own domain name). The sites should be secured in your browser.


  • We created very basic HTML content so that we can have a very simple baseline to be compliant with Accessibility and Green IT;
  • We used Makefile and bash to provide a 1 command deployment process that can be used in a CI/CD pipeline;
  • We set up DNS records for main domain and subdomain
  • We created an Nginx configuration template that can help generate static site virtual hosts on subdomains;
  • We made it customizable with mustache template engine
  • We promoted HTTP to HTTPS using certbot to add Let's Encrypt SSL certificate for our sites;

Sources are available here.

This is far from perfect but should be enough for our current needs. Next time, before we go to far, we will make an initial Accessibility audit of both and It will be an occasion to play with Frago an Hugo theme by Bertrand Keller focused on automating the presentation of RGAA audit reports.