docs.nginx.com/nginx/…/serving-static-content/

I happened across this tool to help you create configs, it looks pretty good, easier than piecing together all the parameters separately: www.digitalocean.com/community/tools/nginx

Seems like it has directions for certbot and generating dhparams, etc. as well.

apt install nginx
cp -r my-files/* /var/www/

The trickier part here his connecting your domain to your raspberry pi and allowing the big internet to access it. You have a few options:

• Set up dynamic DNS to direct your domain name to your (presumably dynamic) home IP address. Assign the rpi a static IP address on your home network. Forward ports 80 and 443 to that address. The world knows your home IP address, and you’re dependent on your router for security. No spam or DDOS protection.
• Use a service such as cloudflare tunnel. You’re dependent on cloudflare or whoever, but it’s an easier config, you don’t need to open ports in your firewall, and your home IP address is not public. (I recommend this option.)

Either way, don’t forget to set up HTTPS. If you aren’t dead-set on using nginx, caddyserver does this entirely automatically.

I know it’s not self hosting, but I went with a Hugo site hosted on Cloudflare pages. That way I don’t have to port forward or worry about uptime or security.

name: Deploy Hugo site to Github Pages

on:
  push:
    branches:
      - main
    workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: "0.119.0"
          extended: true

      - name: Build
        run: hugo --minify

      - name: Configure Git
        run: |
          git config --global user.email "you@example.com"
          git config --global user.name "Your Name"
      - name: Deploy to GitHub Pages
        env:
          GITHUB_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: |
          cd public
          git init
          git remote add origin https://user/:${{ secrets.DEPLOY_TOKEN }}@github.com/USER/USER.github.io.git
          git checkout -b main
          git add .
          git commit -m "Deploy site"
          git push -f origin main

Just use a GitHub page. Super simple and driven by your source code.

.

By default nginx will serve the contents of /var/www/html (a.k.a documentroot) directory regardless of what domain is used to access it. So you could build your static site using the tool of your choice, (hugo, sphinx, jekyll, …), put your index.html and all other files directly under that directory, and access your server at https://ip_address and have your static site served like that.

Step 2 is to automate the process of rebuilding your site and placing the files under the correct directory with the correct ownership and permissions. A basic shell script will do it.

Step 3 is to point your domain (DNS record) at your server’s public IP address and forwarding public port 80 to your server’s port 80. From there you will be able to access the site from the internet at mydomain.org

Step 3 is to configure nginx for proper virtualhost handling (that is, direct requests made for mydomain.org to your site under the /var/www/html/ directory, and all other requests like http://public_ip to a default, blank virtualhost. You may as well use an empty /var/www/html for the default site, and move your static site to a dedicated directory.) This is not a strict requirement, but will help in case you need to host multiple sites, is the best practice, and is a requirement for the following step.

Step 4 is to setup SSL/TLS certificates to serve your site at https://my_domain (HTTPS). Nowadays this is mostly done using an automatic certificate generation service such as Let’s Encrypt or any other ACME provider. certbot is the most well-known tool to do this (but not necessarily the simplest).

Step 5 is what you should have done at step 1: harden your server, setup a firewall, fail2ban, SSH keys and anything you can find to make it harder for an attacker to gain write access to your server, or read access to places they shouldn’t be able to read.

Step 6 is to destroy everything and do it again from scratch. You’ve documented or scripted all the steps, right?

As for the question “how do I actually implement all this? Which config files and what do I put in them?”, the answer is the same old one: RTFM. Yes, even the boring nginx docs, manpages and 1990’s Linux stuff. Each step will bring its own challenges and teach you a few concepts, one at a time. Reading guides can still be a good start for a quick and dirty setup, and will at least show you what can be done. The first time you do this, it can take a few days/weeks. After a few months of practice you will be able to do all that in less than 10 minutes.