The HTTPS Layer

By the time I got to the reverse proxy, most of the hard work had already been done.

The hosts had been rebuilt. Internal DNS was working. Services had names. I could reach what I needed to reach. Dashy was beginning to give the lab a shape that felt more human and less like a collection of private addresses and half-remembered ports. In one sense, everything already worked.

But “works” is not always the same thing as “feels finished.”

I could open Dashy, Open WebUI, Technitium, and the Jekyll development environment. I just had to remember which name went with which port. Some lived on 4000, some on 5380, some on 8080. That is not difficult, exactly, but it is friction. And friction is one of those things that accumulates quietly. A system can be perfectly functional while still asking more of your attention than it should.

That is where the reverse proxy started to matter.

I chose Caddy. Partly because it is good software, but mostly because it felt like the right size for the problem. I did not need something sprawling or heavily abstracted. I did not need dynamic orchestration or a control plane for a whole fleet. I just needed a clean way to say that home.forge.cdilks.com should mean Dashy, ai.forge.cdilks.com should mean Open WebUI, jekyll.forge.cdilks.com should mean the Jekyll development environment, and dns-admin.forge.cdilks.com should mean the Technitium interface.

That is a small sentence to write down. It is also a meaningful thing to make real.

I set up a dedicated VM called proxy and gave it a fixed place in the lab. That mattered to me. I could have folded the reverse proxy into something else, but by this point I had started to appreciate the value of giving important roles their own home. DNS had its place. AI had its place. Writing had its place. It felt right for the proxy to have one too.

Once Caddy was in place, the first win was immediate. I no longer had to remember ports.

That may sound trivial, but it changed the feel of the lab straight away. There is something calming about typing home.forge.cdilks.com instead of remembering where Dashy lives today, and something even better about knowing that the same pattern holds across the rest of the environment. A reverse proxy does not usually get celebrated as a glamorous service, but what it gives you is a cleaner way to enter the systems you already have. That matters.

Then came HTTPS.

At that point I had a choice. I could use internal certificates and trust an internal CA, or I could go a step further and use publicly trusted certificates from Let’s Encrypt. The internal CA path would probably have been simpler. But I wanted to understand the more complete solution, and I wanted the result to feel as clean as the naming already did.

That meant DNS challenge.

Because these names are internal, HTTP validation was never going to be the right answer. The services are not publicly exposed in the normal way, and I did not want them to be. But the domain is mine, and the DNS is under my control, so DNS-01 challenge made sense. In theory, at least.

In practice, that turned into one of those moments where the system teaches you something you did not know you needed to learn.

At first, the certificate requests failed in a way that looked confusing. The token was right. The Cloudflare side looked right. The Caddy build had the right DNS plugin. But Let’s Encrypt still would not issue certificates. It took a bit of digging before the actual problem became clear: the proxy VM was using my internal DNS server, which quite reasonably believed that forge.cdilks.com was the authoritative zone. Cloudflare, of course, knew only about cdilks.com. Internally, the logic made perfect sense. Publicly, it was wrong.

That was a useful lesson.

It reminded me that once you start building layered systems, truth becomes contextual. Internal truth and external truth are not always the same thing. Something can be correct inside your environment and still be the wrong answer for a public validation flow. The fix, once understood, was simple enough: make the proxy use public DNS resolvers so it could see the same public zone boundaries that Let’s Encrypt and Cloudflare expected.

After that, things began to fall into place.

Certificates started issuing. The service names that already existed internally started working cleanly over HTTPS. home.forge.cdilks.com felt like a real front door. ai.forge.cdilks.com felt less like a port on a machine and more like a service with a place. Even the Technitium admin interface, which had its own opinions about redirects and proxy headers, eventually settled down once the forwarding behavior was made explicit enough.

That is often the nature of this kind of work. The final result looks simple because a number of small complications have already been dealt with and pushed out of sight.

I think that is one of the reasons I find infrastructure satisfying. When it is working well, it looks obvious. But obviousness is often the visible surface of a lot of quiet decisions.

The reverse proxy did not add a dramatic new capability to the lab. It made access cleaner. It reduced one more layer of unnecessary remembering. It made the lab easier to trust, because the path into each service now felt more deliberate.

And HTTPS did something similar, but at a different level. It did not just encrypt traffic. It made the environment feel more settled. More complete. There is a psychological difference between “this works” and “this feels properly put together.” Trusted certificates, clean names, and consistent entry points all contribute to that feeling.

That is what I keep noticing through this rebuild. A lot of the work is not about adding power. It is about reducing friction. It is about turning a set of working parts into something you can move through without constantly paying small cognitive costs.

Internal DNS gave the lab names.

The reverse proxy and HTTPS gave those names a cleaner, safer way to be used.

It is not the loudest layer in the system. But it may be one of the ones that changed the feel of the lab the most.