[Feature Request] fly-proxy required_headers for Pre-App Request Filtering

[M-Faleij]

I’d love to suggest a small feature for the Fly Proxy that could make a big difference in security and efficiency.

Idea

Add support for required HTTP headers at the proxy level — before a request ever reaches (or starts) the app.

For example:

[services.ports.http_options.required_headers]
    X-My-App-Header = "expected-value"

or:

[services.ports.http_options]
    required_header_keys = ["X-My-App-Header", "X-Auth-Token"]

This would make the proxy reject any request that doesn’t include these headers (or header key/value pairs), similar to how http_service.checks.headers works.

Why this matters

When an app scales down to zero, any incoming request, even unauthenticated ones, can trigger it to start or scale up.
For public-but-protected apps, that means unwanted traffic could cause unnecessary scaling, startup delays, or extra cost.

With this feature, the proxy could immediately drop unauthenticated or malformed requests — preventing them from waking up apps that shouldn’t respond to the public internet.

Benefits

• Prevents unauthenticated requests from starting or scaling up apps

• Reduces unintended scaling and resource usage

• Protects “public endpoint but internal use” scenarios

• Simplifies setups that currently need a separate Fly app acting as a gatekeeper using fly-replay

Current workaround

Right now, the only way to achieve this is by:

1. Running a small public app that validates requests and replays only the authenticated ones via fly-replay.

2. Keeping the protected app internal.

That works, but it’s more complex and less efficient than letting the proxy enforce basic header checks.

---

Would this kind of header-based prefiltering be feasible for the Fly Proxy?
It would be a huge quality-of-life improvement for apps that scale down to zero but still need lightweight protection at the edge.