#3: Life and Website Overhaul

Life!

Life has been quite busy recently, and I haven’t had much time to get around to my personal projects. However, I decided to start focusing again and get back up and running. It's been super enjoyable really throwing myself into the Homelab environment again and starting to learn new things.

One of the things that has long been on my list to learn and start messing with was Docker and containers as a whole. I had never really looked into it or tried to use it—I’ve mostly been a Windows and Mac guy with very little Linux experience until I started building my Homelab. That forced me to learn basic Linux and troubleshooting, which has been a lot of fun and has even helped me in other areas at work.

A co-worker mentioned off-hand that he was hosting one of his websites via Caddy on his home network. This piqued my interest once I started looking into it, as I had no idea what Caddy was or what it did. I quickly learned that it’s a very lightweight and dynamic web server and reverse proxy. That led me down the rabbit hole of asking myself: What do I want to build, and why?

So, what did I decide to build and set up? Way too much, honestly... I decided I was going to take my website off Vercel, move away from Create-React-App (which is now deprecated), and instead build an HTML5 site that I’d self-host and serve content to from an API that didn’t yet exist. For me, this was an ambitious project I knew very little about. I needed to learn Caddy, Docker, more networking, and more Python, since I was a bit rusty.

This all really excited me—it gave me space to thrive and start learning, which I love. Side note: I didn’t like school growing up, and it wasn’t until college that I realized what I was missing by not studying or paying attention in classes I didn’t care about. Now that I can focus on things I am passionate about, I’ve really started to blossom and enjoy learning.

Caddy

I’m not really sure where to start with my now never-ending journey with Caddy as a web server and reverse proxy. My networking skills before this were okay—I’d set up OPNSense and had a fair bit of infrastructure with VLANs, etc.—so I wasn’t totally out of my depth. Still, deploying Caddy on my server via Docker came with a steep learning curve.

I decided I was going to set up a true dev environment and do CI/CD. Was that the wisest choice? Definitely not. But I was determined to go down this road, to learn, and to make it work for me. I started from scratch and began reading through the Caddy Documentation, which is quite extensive. If you're only looking to create a reverse proxy (and not a full web server), and you’re running OPNSense, there's a fantastic built-in plugin you can check out here.

Once I’d committed to setting up my dev environment, I started figuring out how Caddy worked and what value it could bring. Up until that point, I had only accessed my services locally via Twingate VPN. That still works well for me, and I’ll continue using it for sensitive resources—but I also wanted to publicly expose my website and some services, like UptimeKuma.

After getting familiar with Caddy, the next piece of the puzzle was Docker. Honestly, I still don’t think I’ve scratched the surface of what Docker can do. But I wanted to learn it so I could containerize things and reduce the number of VMs/containers I was spinning up in Proxmox. After watching a few YouTube videos—this one from Jim's Garage was especially helpful (even though I didn’t end up setting up Portainer)—I started getting the hang of Docker Compose and Dockerfile and managed to create a small semblance of a web server.

Before that, I started building a simple Python API to serve up my Wordle game and content from Contentful (which you’re reading right now!). I know this post is more of a stream of consciousness than a proper tutorial, but it lets me share what I’ve been working on. I think I’ll put together a more tutorial-style post soon, with a public GitHub repo to go along with it.

Back to the API, created a simple RESTful API that connects to a local Postgres DB to store data, just so I could learn how it works. This was a fun project because I’d never done anything like it before. That’s where Caddy came in again, as I needed an easy way to serve this traffic without exposing everything directly to the Internet. I got everything running, but I kept hitting a specific issue where the DNS challenge would fail. I’m handling A records and TLS through Cloudflare. It would create the challenge TXT records, but then would try to route to the 127.0.0.11 DNS server instead of using my network’s DNS. Super strange—and not at all clear why it was happening.

After a bunch of troubleshooting, I figured out that the failure was due to my AdGuardHome setup via OPNSense. I ended up switching from AdGuardHome to just using Unbound DNS to handle everything—including blocklists. It wasn’t my preferred solution, but I just wanted to get everything running. I’ve since found documentation that might help me get AdGuardHome working again, so I’ll be looking into that. I really like the data and UI that AdGuardHome provides, so if I can bring it back, I will.

Once that was fixed, it was off to the races—and now you’re here, reading this fun blog post (if you’ve made it this far!). I’m really looking forward to writing more posts like this and giving myself a place to jot down my thoughts and express my ideas—however messy they may be. My next project is getting Authentik working (spoiler: it is) and putting some apps behind it—mostly to add API endpoint authentication so I can keep building things out!