Introduction

After much deliberation, indecision, and a good while of no action I finally said “Enough is enough!” and purchased myself the domain name - fearempty.com . I needed this domain name because when I initially setup this website I did so with a subdomain created by a friend who owned another full domain! With my own full domain, I’m able to upgrade and improve my self-hosting setup with sub domains that can routing traffic to specific services. This post will go into detail on some of the setup involved with the domain migration I completed in my self-hosting enviornment and this website in particular blog.fearempty.com .

Setup

CloudFlare

The first step in the domain migration process was to create the DNS records that would be used for the specific services. I’m using CloudFlare as my DNS registrar and the administration console was very easy to use for this part. I won’t bother to post all the subdomains. However, one that I created was minecraft.fearempty.com

Nginx Proxy Server

Setting this up required the most research as I did not understand much about it at all to start. I’m not ashamed to admit I did use ChatGPT for some of that investigation and for the actual setup. The first mental hurdle I had to get over was my initial assumption that the Nginx proxy server would be running containerized. The web server runs on the host itself and facilitates forwarding internet traffic to the docker container’s exposed internal port.

server {
    listen 80;
    server_name blog.fearempty.com;

    location / {
        proxy_pass http://localhost:##REDACTED##;   # Forward to the Docker container
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The snippet above is a configuration file used by the Nginx proxy server.

Hugo

It was a fantastic moment when my vision of having specific services routed through my owned subdomains was now a reality. However, in standard fashion, it was quickly met with an issue. The title and navigation links within my blog were still routing to the old now defunct subdomain! So, you would attempt to click the title of a post to view it’s full content and you’d be met with an error. Yikes!

Luckily, it was an easy fix because of how Hugo works. The links embedded in the title of the blog posts are configured to begin with whatever the website administrator (me) has set the baseURL parameter to in the Hugo website’s config.toml file. With the baseURL set to the old sub-domain, the links within the project contents were incorrect. Therefore, all I had to do was update the baseURL to blog.fearempty.com, regenerate the website with Hugo, and restart the docker container to serve the reconfigured site!

Conclusion

While I had my reservations about this process and forsaw it potentially taking longer than it did I think it went well overall. In all honestly, I think all the success here was due to the amount of planning and time taken to map out what I had to do. This way, I knew what things I needed to gather understanding on before I began trying to use them.