The past few years of software development and architecture have witnessed multiple revolutions. The rise of containers, unruly package management ecosystems, and one-click-deployments holds an unspoken narrative: most people probably don’t care about how things work beneath the top layer. Sure, advancements in application infrastructure have undoubtedly made our lives easier. I suppose I find this lack of curiosity and unwillingness to dig deeper into the innards, an unrelatable trait. Yet I digress.
I’ve never found web server configurations to be particularly tricky, but apparently, most consider this enough of a nuisance to make something even easier to use. That’s where I came across Caddy.
Caddy is a web server and free SSL service in which most of the actual work happens via their download GUI. It’s great. Even though I never expected us to reach a place where
apt install nginx and
apt install certbot is considered too much of a burden, it only took a few minutes of wrestling with a Docker container running on a VPS that I realized there was a better way.
In my particular example, the Docker container I was running produced an API endpoint. For some reason, this service forcefully insists that this endpoint is your machine’s localhost, or it simply won’t work. While scoffing at vanity URLs for APIs is fine, what isn’t fine is _you can’t assign an SSL certificate to an IP address. _That means whichever app consuming your API will fail because your app _surely _has a cert of its own, and HTTPS > HTTP API calls just aren’t gonna happen.
#devops #caddy #containers #ssl