Building My Homelab Blog: From Cloud VM to Live Website

Building My Homelab Blog: From Cloud VM to Live Website
Photo by Taylor Vick / Unsplash

I wanted to create a homelab because I wanted to experiment with cybersecurity while also writing and hosting a blog. It seemed like a good idea to tackle both goals at once. So here I am, documenting the process of creating my first homelab.

The first major decision was choosing a cloud provider (because other than being more practical, I'm too broke to have my own actual server). I went with Oracle Cloud because they offer a free tier (surprise!) that is available indefinitely. This allowed me to experiment without worrying about costs and gave me access to a VM that is sufficient for running a blog and testing basic cybersecurity projects.

Once I selected Oracle, I created my first virtual machine. I chose a small instance that fit within the free tier limits. This kept costs at zero while providing enough resources for Nginx, Ghost, and any security experiments I wanted to run.

After provisioning the VM, I had to focus on networking and security before making it accessible on the internet. Oracle Cloud uses Network Security Groups (NSGs) and security lists to control incoming and outgoing traffic. I configured rules to allow only the essential ports: SSH (port 22) for secure remote access, HTTP (port 80) for the blog, and HTTPS (port 443) for encrypted traffic. Restricting other ports reduces the attack surface and is a critical first step in securing any server.

NSGs are more flexible and act as virtual firewalls at the VM or subnet level, allowing fine-grained control over which traffic can reach specific resources. Security lists, on the other hand, are simpler and apply at the subnet level, providing basic allow/deny rules for all resources within that subnet. By combining NSGs and security lists, I could control access precisely while still keeping the configuration manageable.

With the networking rules in place, I moved on to installing Nginx to act as a reverse proxy. The goal was to have Nginx handle incoming web traffic and forward it to the Ghost blog running on the VM. This setup also makes it easier to manage SSL termination and, eventually, multiple applications.

The tricky part came when I was moving my blog from HTTP to HTTPS. Ghost was running but none of the CSS or JavaScript loaded and the site looked broken. After some troubleshooting, I realized the problem was how NGINX was forwarding requests.

Ghost serves static assets from specific paths. If the proxy is not set up correctly, it can generate URLs pointing to 127.0.0.1 instead of the public domain. That is exactly what happened. Asset requests were being redirected incorrectly and returning 404 errors.

The fix was twofold. First, I set the correct URL in Ghost’s configuration so it uses the public domain instead of localhost. Second, I updated the NGINX configuration to proxy requests properly. The key parts look like this:

server {
    listen 443 ssl;
    server_name abrahamkristanto.dev;

    location / {
        proxy_pass http://127.0.0.1:2368;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
    }

    location ~* \.(?:css|js|jpg|png|svg)$ {
        proxy_pass http://127.0.0.1:2368;
        expires 30d;
        add_header Cache-Control "public";
    }
}

This setup forwards requests to Ghost on localhost and passes the correct headers so Ghost knows the request is HTTPS. It also caches static assets to make the site faster. Once these changes were in place, the blog finally rendered correctly. CSS and JavaScript loaded as expected and everything looked right.

Setting up the homelab and getting the blog running was a great learning experience. I not only got a functional Ghost blog online, but I also learned how to configure networking, secure a VM, and troubleshoot real-world issues with NGINX and HTTPS.

This process reinforced the importance of proper proxy configuration and understanding how applications like Ghost handle URLs and assets. With the blog finally working, I now have a platform to write, experiment, and document my cybersecurity projects, all while running everything in my own environment.

Overall, combining the blog setup with homelab experimentation turned out to be a practical and rewarding way to learn both web hosting and cybersecurity concepts hands-on.