You built a quick Go service, dropped it on Cloud Run, and pointed a domain at it. The requests bounce, TLS acts up, or the headers just look wrong. Somewhere in the middle, Caddy and Cloud Run are silently arguing about who’s in charge of the proxy. That mystery layer is exactly what this post untangles.
Caddy is a modern web server that auto‑manages TLS, handles reverse proxying, and speaks clean configuration language. Cloud Run is Google’s managed container platform that scales your app from zero to thousands of instances. Each does its job well. But when you combine them, you get a powerful, minimal ops stack for secure public endpoints — if you wire it correctly.
When Caddy fronts Cloud Run, Caddy handles certificates, redirects, caching, and identity headers. Cloud Run handles ephemeral container execution. The logic works like this: Caddy accepts the external requests, applies HTTPS, validates identity (using OIDC or JWT from something like Okta), then forwards clean traffic to Cloud Run. Cloud Run sees a consistent header set and can verify identity without extra configuration.
A common mistake is double termination. You do not want Cloud Run generating TLS when Caddy already did. Instead, let Caddy terminate SSL and speak HTTP over Google’s internal network to your Cloud Run URL. That setup gives you reliable audit trails and stable certificate rotation managed directly by Caddy’s ACME automation.
For consistent authentication, map your identity provider into Caddy’s reverse proxy layer. If you use AWS IAM or OIDC tokens, refresh them with short TTLs and let Cloud Run validate via its built‑in identity APIs. Cryptographic freshness beats static API keys every time.
Caddy Cloud Run best practices:
- Use Caddy as the public edge, Cloud Run for compute. Separation of duties improves clarity.
- Let Caddy renew TLS automatically. Manual certificate rotation wastes time and risks expiry.
- Cache static assets at Caddy. Cloud Run only wakes the container for logic that matters.
- Log at both layers. Cross‑reference request IDs to get transparent latency insights.
- Run smoke tests after redeploys. Cloud Run cold starts can expose config mistakes instantly.
Developers love this flow because everything feels faster. You make changes locally, push to Cloud Run, and Caddy reflects them live without DNS pain. Policy handling becomes easy: identity goes through defined headers, not scattered scripts. Debugging becomes a five‑minute task instead of a mystery.
Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. Instead of passing tokens manually, hoop.dev standardizes how identity and session data flow between Caddy and Cloud Run. That means less chance of leaked credentials and more time spent shipping code.
Quick answer: How do I connect Caddy to Cloud Run securely?
Set Caddy as your HTTPS edge service, proxy requests to your Cloud Run URL using internal traffic, and manage identity through OIDC. This prevents double TLS termination and ensures Cloud Run receives verified requests from a trusted proxy.
As cloud apps scale, AI systems and deployment bots can interact through these proxies too. Configuring Caddy Cloud Run properly keeps machine‑to‑machine prompts consistent, avoids token sprawl, and lets your automated agents act safely without extra human oversight.
Security without slowdown is the real goal. When Caddy fronts Cloud Run, you get it all: speed, proper encryption, and clear identity boundaries that grow with your infrastructure.
See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.