Part 4 · Production Infra — Redis, Docker, Kubernetes

quill works on your laptop. Part 4 is about making it run somewhere that isn’t your laptop — and survive there. This is the part the user asked for by name: how Rust actually integrates with Redis, Docker, and Kubernetes. We add each in the order a real service adopts them: a cache and rate limiter first (Redis), then reproducible packaging (Docker), then an orchestrator that keeps it alive and scales it (Kubernetes).

What you’ll build

                       ┌──────────────── Kubernetes ────────────────┐
                       │   Deployment (quill)   Deployment (worker)  │
                       │        │  ▲ HPA scales on load    │         │
   Internet ─► Ingress─┼──► Service ─► pods ◄── probes ──► pods      │
                       │        │                          │         │
                       │        ▼                          ▼         │
                       │   ┌────────┐   ┌────────┐   ┌───────────┐   │
                       │   │Postgres│   │ Redis  │   │ Secrets/  │   │
                       │   │        │   │(cache/ │   │ ConfigMap │   │
                       │   └────────┘   │ queue) │   └───────────┘   │
                       │                └────────┘                   │
                       └─────────────────────────────────────────────┘

• Redis, three ways: cache rendered post pages, rate-limit the AI endpoints per user, and back the Part 3 job queue with a real store instead of an in-process channel.
• Docker: a multi-stage build that compiles the Rust workspace and ships a tiny, non-root image (distroless or scratch-ish), plus a docker-compose.yml that brings up quill + Postgres + Redis for local development.
• Kubernetes: Deployments for the web and worker binaries, a Service and Ingress, ConfigMaps and Secrets for config, liveness/readiness probes wired to your /health, rolling deploys, graceful shutdown, resource requests/limits, and a HorizontalPodAutoscaler.

The stack, and why each piece is here

Tool	Role in quill	Why it earns its place
Redis	cache · rate limit · queue	shared, fast, atomic ops other pods can see
Docker	reproducible packaging	”runs on my machine” → “runs anywhere,” tiny attack surface
Kubernetes	orchestration	restarts, rolls out, and scales pods without you watching
probes	health signaling	K8s only routes traffic to pods that say they’re ready
HPA	autoscaling	more load → more pods → back down when quiet

The chapters

Ch	Title	You add	The idea it teaches
1	Redis	cache, per-key rate limit, queue	when to reach past Postgres for a shared, fast store
2	Docker	multi-stage build, compose	small non-root images, caching layers, local infra
3	Kubernetes	Deployments, Service, probes	the reconcile loop, config vs secrets, rolling deploys
4	Scale & resilience	HPA, limits, graceful shutdown	autoscaling signals, backpressure, zero-downtime deploys

Rust’s unfair advantage here

A Rust binary has no interpreter and no VM, so its container image can be just the binary — often under 30 MB, sometimes single-digit. That means faster pulls, faster pod starts, a smaller attack surface, and honest resource limits. The language you chose in Part 1 pays a dividend in Part 4.

The thread

Once it compiles, what does it take to run for real users? Part 4’s answer: make failure and scale someone else’s problem — declaratively. You stop running the process and start describing the state you want; Kubernetes reconciles reality to match. Your job becomes writing honest health checks and resource limits so the orchestrator can do its job.

Next: Part 5 · Observability →