This page explains how our proxy handles HTTP response compression, so you get better performance out of the box.
Content-Encoding header, we negotiate compression on your behalf based on the client’s Accept-Encoding header.
This behavior usually Just Works. But there are edge cases you might care about. Here’s how it works, what we support, and how to override it if needed.
What is Content Encoding?
Content encoding compresses HTTP response bodies (the data or content being sent by the server to the client). Clients include anAccept-Encoding header listing the algorithms they support. If the server supports any of them, it compresses the response and sets the Content-Encoding header to indicate the algorithm used. The client then decompresses the body before rendering it.
Common encodings include:
br(Brotli)gzipzstd(Zstandard)deflate
What the Fly.io Proxy Supports
The Fly.io proxy handles compression at the edge, automatically selecting the most efficient algorithm supported by both the client and the proxy. It prefers:- Zstandard (zstd) — Best all-around for performance and size. Supported in Chrome and Firefox.
- Brotli — Still excellent, especially for text. Smaller files than gzip in many cases.
- gzip — The fallback. Widely supported.
- deflate — Rarely used, but still supported.
Content-Encoding header. If your app sets one, the proxy passes the response through unmodified. You can also explicitly disable compression by setting Content-Encoding: none.
Configuration
Configure the HTTP handler to enable proxy-level compression: The http handler must be used in yourfly.toml file for the service. There are two ways to do this (choose only one!):
- http_service preconfigures the most common options for a service speaking HTTP. It will use the http handler implicitly for both ports 80 and 443 (and additionally, of course, the tls handler for port 443).
- A service block explicitly using the http handler. This example serves http only (no https) on external port 80:
When You Might Want to Customize Behavior
Most apps can rely on the defaults, but if you’re doing something more specific like streaming HTML, here is something to consider:Streaming HTML
The proxy buffers responses before compressing them. That can break HTML streaming—e.g., progressive server-side rendering. To avoid buffering, disable compression by settingContent-Encoding: none for those responses: