fix(helm): raise workerRlimitNofile to 2x workerConnections

[Eric Hibbs (flowstate)]

What & why

The chart ships workerConnections: 8192 against workerRlimitNofile: 2048. nginx spends two file descriptors per proxied connection — one to the client, one to the upstream — so a worker exhausts descriptors at roughly a quarter of its configured connection ceiling. Past that point it fails accept() with Too many open files instead of reaching the limit an operator tuned, and the failure surfaces as refused or hung connections rather than as anything naming the real cause.

16384 is the ratio Socket's own hosted firewall deployments already run against the same 8192 connection count, on the same image.

Testing

helm lint helm/ passes. helm template test helm/ renders worker_rlimit_nofile: 16384 into the generated socket.yml configmap, alongside the unchanged worker_connections: 8192.

Notes

Raising the value only raises the ceiling nginx requests via setrlimit; container hard limits sit far above 16384 and workers allocate descriptors on demand, so nothing is reserved at startup.

---

Note

Low Risk
Default tuning only in Helm values; it raises nginx’s soft FD ceiling without changing auth, routing, or application logic.

Overview
Raises the Helm chart default nginx.workerRlimitNofile from 2048 to 16384 so it matches 2× workerConnections (8192). Proxied traffic uses two file descriptors per connection (client + upstream); with the old ratio, workers could hit “Too many open files” well below the configured connection limit.

Adds a short comment in helm/values.yaml documenting that workerRlimitNofile should be at least 2× workerConnections. The value still flows into the generated socket.yml as worker_rlimit_nofile via the chart ConfigMap.

^{Reviewed by Cursor Bugbot for commit af77c2c. Configure here.}