Where this is going
Roadmap, and the gaps we already know about
Nothing here is a promise with a date on it. It is one person's list, published so you can see whether the thing you need is on it.
Being worked on
Next
Per site and per backend traffic numbers
The biggest gap. stub_status gives seven numbers for the whole
server and nothing per site. The generated log format already carries
$upstream_addr, $upstream_response_time,
$request_time, $status and $upstream_cache_status,
which is everything a log tailer would need for requests per second, the status code mix,
p50, p95 and p99 latency, cache hit rate and which backend served each request.
The setting exists in the database and nothing reads it. There is no log tailer and no dashboard page. This is written as a plan, not as a feature, because documentation promising something nobody has written is the worst kind of wrong.
Single sign on for proxied applications
Putting an identity provider in front of an application that has none of its own. We score one out of five on that row against four and five for the others, and it is a fair score.
Better JWT validation at the edge
The lua path works and the subrequest path works, and neither is as neat as a directive. Two out of five today.
Faster backend changes
Everything ends in a graceful reload. Reducing how often a reload is needed for the common cases would raise the ceiling for anybody whose backends change constantly.
Not planned
Things that are deliberately not going to happen
Packaged video streaming
HLS, DASH and f4f are modules compiled into the paid nginx binary. There is no way to add them from out here, and pretending otherwise would waste your time.
NTLM connection pinning
It keeps a connection pinned for the whole handshake and cannot be faked from outside the nginx process.
MQTT preread and filtering
Stream level protocol parsing that only exists in the paid build.
A request queue
Holding requests when every backend is busy. It is a genuinely useful feature and it is not something a manager outside the process can add.
Becoming a Kubernetes ingress controller
A different problem with good solutions already. This is for people running servers.
A paid tier
The whole point was that the commercial products cost more than a lot of good projects can spend. Adding a price would be an odd way to finish that thought.
Where it is weaker than it should be
From the comparison table in the product, these are the rows we score three or lower on and which are not on the not planned list above.
| Capability | Us | Best of the others | What it means in practice |
|---|---|---|---|
| Somebody to call | 0 | 5 | There is no support contract and no number. This will not change. |
| Single sign on for proxied applications | 1 | 5 | Planned. |
| Request queueing | 1 | 5 | Not possible from out here. |
| Runtime key value store | 1 | 5 | Maps do the same lookup and need a reload to change. Fine for a blocklist you change hourly. |
| JWT validation at the proxy | 2 | 5 | Works, and is not as neat as a directive. Planned. |
| Live activity monitoring | 3 | 5 | The log parsing work above closes most of this. |
| Sticky sessions | 3 | 5 | Works. The first request is not sticky, and a pool change means a reload. |
| Changing upstreams without a reload | 3 | 5 | Reloads are graceful. The limit is the rate, not the mechanism. |
| Where the nginx binary comes from | 3 | 5 | Building from source means you own the upgrade cycle. It also buys post quantum TLS and the WAF. |
| DNS based failover | 3 | 5 | It works and it is honest about the limits. Kemp does more with it. |
| Backend processor and memory | 3 | 1 | Ahead of everybody and still only reads what your servers already publish. |
| Taking a backup, and where it goes | 3 | 5 | One file, taken by hand. No scheduling and no remote target yet. |
The full table with the reasoning for every row is on the comparison page, and the same table ships inside the product.
Asking for something
The most persuasive thing is a description of what you are actually trying to do rather than the feature you think would solve it. Several things in the product exist in a different shape from the one first asked for, because the underlying problem had a better answer.
Two fresh servers is all it takes
Ubuntu 22.04 or newer, root access, and about twenty minutes. The installer does the rest and it is safe to run twice.