FastCGI: 30 years old and still the better protocol for reverse proxies

📝 Discussion Summary (Click to expand)

“I agree with the article, FastCGI is better than HTTP for these things.” — max_k
“All completely avoided with FastCGI.” — agwa

“If you expose an embedded HTTP app server directly to the Internet you're almost guaranteed to get pwned.” — nostrademons
“Putting security‑critical logic in proxies is a violation of the End‑to‑End Principle, not an example of it.” — agwa ### 3. Development‑production parity and explicit header whitelisting often require a dedicated proxy configuration
“Set proxy_pass_request_headers off, and then explicitly proxy_set_header each individual header you want to forward…” — nostrademons (via nginx)
“Or just use CloudFlare Tunnel, which gives you a bunch of other DDoS and abuse protection and keeps your app server off the public Internet.” — nostrademons

🚀 Project Ideas

Lightweight reverse proxy that automatically sanitizes and forwards only whitelisted headers.
Eliminates manual nginx config gymnastics for header forwarding.
Securely exposes embedded HTTP/FastCGI services to the internet without exposing the app directly.

Key	Value
Target Audience	Developers of internal services, homelab maintainers, small teams using embedded servers
Core Feature	Header whitelisting & stripping, configurable policies via YAML/JSON, automatic health checks
Tech Stack	Go (net/http), Viper for config, Prometheus for metrics
Difficulty	Low
Monetization	Hobby

HN users repeatedly asked for a way to “only pass specific headers” and worried about exposing embedded servers to the open internet.
The project directly addresses the security‑focused desire to “strip everything you aren’t explicitly expecting” and would let users safely expose FastCGI/embedded HTTP apps.
Provides a simple CLI and Docker image, making it instantly usable in dev and production environments.

Guarantees dev‑to‑prod configuration parity by using the same proxying logic in both contexts.
Auto‑reloads code changes and serves debug headers only in dev mode.

Key	Value
Target Audience	Web developers using Go, Python, Rust, or any language that can expose a FastCGI/SCGI interface
Core Feature	Seamless switching between `http.Serve` (dev) and `fcgi.Serve` (prod), hot‑reload, unified config file
Tech Stack	Rust (for performance), `ariang` crate for FastCGI, `tokio` runtime, TOML config
Difficulty	Medium
Monetization	Revenue-ready: {pricing model}

Commenters highlighted the pain of “having to setup a reverse proxy on their machine” and the need for “dev as similar to prod”.
This tool would let developers test header handling, rate limiting, and other proxy‑level concerns locally without external nginx setups.
Could be packaged as a VS Code extension or CLI, offering a clear upgrade path to production‑grade deployments.

Small Dockerized reverse proxy that caches HTTPS downloads (e.g., package managers, CI artifacts) to eliminate repeated downloads.
Provides TLS passthrough, configurable TTL, and simple API for adding new cache sources.
Runs on any workstation or home‑lab server with minimal configuration.

Key	Value
Target Audience	Developers, DevOps engineers, hobbyist CI/CD users, home‑lab owners
Core Feature	Transparent caching of outgoing HTTPS requests, customizable cache directories, health endpoints
Tech Stack	Go, `fasthttp` for performance, BoltDB for cache state, Docker SDK for easy deployment
Difficulty	Medium
Monetization	Hobby

Multiple users expressed frustration with “downloading same packages 100 times” and requested “local caching proxy for modern https‑infested world.”
Solving this pain point directly aligns with discussions about reducing redundant network traffic and improving developer experience.
Could later expand to offer a hosted SaaS cache with per‑user quotas, creating a potential revenue stream.