Why this exists
This started as a cost problem, not a security paper.
I was running a small production setup across two servers: a dedicated 1cpu/1GB RAM server running Redis, and a second OCI server — 2ocpu/12GB RAM — hosting a Postgres database alongside several NestJS app containers. Two servers, many services, and every one of them talking in plaintext by default. The app containers reached Redis over the private network; they reached Postgres on the same host they lived on. But "private network" and "same host" aren't the same thing as encrypted — I'd locked things down with iptables (as oracle compute manages firewall with iptables by default), restricting which hosts could even reach the Redis and Postgres ports, and routed the app-to-Redis traffic over a private IP instead of a public one. That's necessary hygiene, but it's not TLS. Anyone with a foothold on that private network, or one misconfigured firewall rule, would see everything moving in the clear.
So the real question became: how do I get Redis, Postgres, and my app containers actually encrypting traffic between them — without turning a two-server side project into one that also needs its own PKI team?
That's the situation most solo devs and small startups are actually in. You're setting up and managing Redis, Postgres, and maybe Kafka, and every one of them defaults to plaintext traffic between services. The "proper" answers people point you to — a managed PKI service, HashiCorp Vault, cert-manager on Kubernetes, a paid CA — all assume you already have infrastructure to run infrastructure on. That's not where you are on day one.
