3 ms·

Show HN: Sentinel – a Pingora-based reverse proxy (inspired by River)

8 points by raskelll 8mo ago

I’d been watching River (Pingora-based) and hoping it would mature, because I think Rust + Pingora (from Cloudflare) is a really solid foundation for a future-proof reverse proxy. Progress stayed quiet, so I started building the “practical reverse proxy layer” on top of Pingora myself: config/routing + operational defaults + a way to plug in extra request/response logic without patching the core. Sentinel: https://github.com/raskell-io/sentinel https://github.com/raskell-io/sentinel River: https://github.com/memorysafety/river https://github.com/memorysafety/river Quick try: curl -fsSL https://getsentinel.raskell.io https://getsentinel.raskell.io | sh If you’ve operated proxies: what’s one default you’d change to make them less surprising (timeouts, retries, header handling, etc.)?

hotbird 8mo ago
[dead]
wasuli_official 8mo ago
The agent architecture is clever. Crash isolation for WAF/auth means a buggy plugin cant take down the proxy, which has bitten me with nginx modules before.
- raskelll 8mo ago
  Appreciate that! That exact failure mode is why I went with out-of-process agents. A bit like Envoy's ext_proc filter. Sentinel treats agents like separate services (timeouts, circuit-break-ish behavior, w/ explicit fail-open/fail-closed choice), so a crash/hang in WAF/auth shouldn’t take the data plane with it. Out of curiosity: when the nginx module bit you, was it mainly crashes, memory leaks, or latency spikes under load?
  - wasuli_official 8mo ago
    Memory leaks mostly. Ran ModSecurity and memory would creep up over days until we hit OOM. Ended up with scheduled restarts as a band-aid which felt wrong.
erdemkoca 8mo ago
I’m building a multi-tenant business app (auth, roles, invoicing, time tracking). Curious whether you see Sentinel agents as a good place for tenant-aware auth / RBAC enforcement (e.g. fail-closed auth agent, fail-open observability agent), or if you’d still keep that strictly in-app.
- raskelll 8mo ago
  Good fit for coarse auth at the edge (who is this? what tenant? basic scopes, and so on). I’d still keep object-level/domain rules in-app. Fail-closed for auth, fail-open for observability is the right mental model. Biggest multi-tenant footguns are header spoofing + tenant-unaware caching. The proxy should own identity headers and include tenant in any cache key.

8 points by raskelll 8mo ago

hotbird 8mo ago

[dead]

wasuli_official 8mo ago

The agent architecture is clever. Crash isolation for WAF/auth means a buggy plugin cant take down the proxy, which has bitten me with nginx modules before.

raskelll 8mo ago
Appreciate that! That exact failure mode is why I went with out-of-process agents. A bit like Envoy's ext_proc filter. Sentinel treats agents like separate services (timeouts, circuit-break-ish behavior, w/ explicit fail-open/fail-closed choice), so a crash/hang in WAF/auth shouldn’t take the data plane with it. Out of curiosity: when the nginx module bit you, was it mainly crashes, memory leaks, or latency spikes under load?
- wasuli_official 8mo ago
  Memory leaks mostly. Ran ModSecurity and memory would creep up over days until we hit OOM. Ended up with scheduled restarts as a band-aid which felt wrong.

erdemkoca 8mo ago

I’m building a multi-tenant business app (auth, roles, invoicing, time tracking). Curious whether you see Sentinel agents as a good place for tenant-aware auth / RBAC enforcement (e.g. fail-closed auth agent, fail-open observability agent), or if you’d still keep that strictly in-app.

raskelll 8mo ago
Good fit for coarse auth at the edge (who is this? what tenant? basic scopes, and so on). I’d still keep object-level/domain rules in-app. Fail-closed for auth, fail-open for observability is the right mental model. Biggest multi-tenant footguns are header spoofing + tenant-unaware caching. The proxy should own identity headers and include tenant in any cache key.