On 2025/11/05 20:17, Marc Chantreux wrote: > On Wed, Nov 05, 2025 at 01:43:30PM -0000, Stuart Henderson wrote: > > On 2025-11-05, Christoph Liebender <[email protected]> wrote: > > > I'm currently trying to migrate my nginx setup to relayd > > why? > > if you want to avoid nginx, I suggest looking at haproxy. > > why? This is not a rethorical question: maybe I chose it for bad > reasons? > > I'm an openBSD almost newbie and chose relayd because relayd is > default and I had the intuition that relayd, httpd and pf are designed > to work together in a modular way so it was the idiomatic choice. > > I have to admit It wasn't as easy as I expected to dive in but I blamed > my complete openBSD inexperience (no previous pf usage). I think I > now have a better understanding about how it works and my next step is > to setup SSL (if I correctly understand it, what I want is relayd to > deal with the encrypted trafic from/to internet and the local traffic is > plain). > > I have to admit a more didactic documentation is missing but my real > question is: is there a problem with relayd itself ? is it unmaintained? > suffer a bad design? have performance or consumption problem?
relayd does receive some occasional maintenance, but not a huge amount. originally it was mainly for manipulating PF tables (used to be called 'hostated'), grew some additional features for http inspection, which have been bent into being able to do a little more of what you need for more standard http reverse-proxying, but it's pretty awkward. configuration is idiosyncratic, and requires some mental gymnastics to do things which are simple in other software that is written from the ground up for that. > If so, why is it still default? not sure about the word "default". it is a tool which is available in base and it meets some use-cases. if it's a good fit for what you need to do then fine. otherwise there may well be something else that's more suitable. for those things which are part of the original use-case (host health checks and PF table manipulation based on that) I don't there's really anything else around. and those features are mostly not too tricky to work with. also for simpler TCP proxies where, after setup, the data stream can be passed directly without needing any changes, it can use the kernel "socket splicing" feature for higher performance. afaik nothing else currently supports this and I believe some installations make heavy use of it. (this is not useful when doing TLS offload of course).
