Show HN: I built a memory-safe web server in Rust

I suspect that people don't like changing web servers, and perhaps that's why it took the industry so long to move away from Apache. Ferron actually looks great — great performance, automatic TLS, easy reverse proxy configuration and more. Congrats on shipping this!

Please consider out-of-the-box way to analyze slow queries, analysis by endpoints (ideally with some patterns to group by), ideally to not generate gigabytes of access logs but rather give some already-aggregated in-memory stats.<p>Maybe batteries included would be great (web UI similar to HAProxy but way-way better).

I’d love your opinion on how you found working with Rust’s memory model for something like a web server. Did your design fit naturally with ownership and borrowing, or did you find yourself fighting the language?

I&#x27;d mention fearless concurrency on the website&#x2F;blog post, as that distinguishes your webserver from, say, caddy.

Is it susceptible to slow loris?<p>Hyper, the http library, did not handle it well.

Awesome :) Best of luck with the project!

thanks for sharing. what&#x27;s the commercial plans?<p>i will add to the pile of cgi hosts in our CI for weird and borderline hostile php projects and report back.

Have you heard of axum[1] or actix-web[2]? What does this do that existing Rust web servers don&#x27;t?<p>I think the &quot;web server&quot; ecosystem in Rust is pretty mature by now, so you should probably state in what way your project is novel on the website.<p>Edit: OK, I realized that this is supposed to be an nginx&#x2F;caddy replacement, so a complete, configurable web server&#x2F;proxy. Maybe check out <a href="https:&#x2F;&#x2F;github.com&#x2F;memorysafety&#x2F;river">https:&#x2F;&#x2F;github.com&#x2F;memorysafety&#x2F;river</a> or <a href="https:&#x2F;&#x2F;github.com&#x2F;sozu-proxy&#x2F;sozu">https:&#x2F;&#x2F;github.com&#x2F;sozu-proxy&#x2F;sozu</a><p>[1] <a href="https:&#x2F;&#x2F;docs.rs&#x2F;axum" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;axum</a><p>[2] <a href="https:&#x2F;&#x2F;docs.rs&#x2F;actix-web" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;actix-web</a>

This web server is probably awesome. However &quot;memory-safe&quot; isn&#x27;t distinguishing within the Rust ecosystem. There&#x27;s... a lot... of Rust web servers out there, all of which are presumably memory-safe, because Rust:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;flosse&#x2F;rust-web-framework-comparison">https:&#x2F;&#x2F;github.com&#x2F;flosse&#x2F;rust-web-framework-comparison</a><p>How does Ferron distinguish itself from these? I didn&#x27;t get that from skimming the landing page.

I use caddy and I&#x27;m quite happy with it over apache and nginx, but I&#x27;d happily give my opinion if this helps OP to make this something different and hopefully even better than caddy.<p>I love auto TLS and caddyfiles are easy to understand. Modularity is important and templates can be very useful. Serving files and using caddy as reverse proxy are the most common uses I make of it in production, but I also use caddy in dev and it&#x27;s a boon. Ease of config means my team can easily pick up my work and continue from there, even if they are not as proficient with the tool.<p>I don&#x27;t love caddyfile directive ordering: sometimes my colleagues are confused because directives have an implicit order that is not obvious: instead of reordering directives, I&#x27;d rather have a warning&#x2F;error message saying &quot;this config doesn&#x27;t make sense because you cannot do this and that&quot;, or just follow the order used in the config file + warnings.<p>I use it a lot to prototype and mock APIs during development, e.g. to have endpoints returning html pages or json documents: static files and templates are useful for this and I wouldn&#x27;t consider something without this feature, though go templates aren&#x27;t that great and&#x2F;or caddy docs are a bit lacking (e.g. a simple loop over 0,1,2,3... Is not obvious!)<p>I don&#x27;t find caddy great (or I don&#x27;t know how to use it) to debug things when they are not working as expected. I often find myself replacing parts of the infra with netcat so that I can inspect what is going on. It would be great to have a &quot;debug endpoint&quot;, like a webpage I could connect to and inspect all the traffic like MITM proxy, it would be awesome. Being able to inject myself in a route and manually change headers, responses, requests etc, it would be fantastic and a great help in debugging issues. Also, being able to start this &quot;inspection mode&quot; while in production would be nice, without having to restart the server (something is off -&gt; I ssh-port-forward to the server host -&gt; connect my browser to the server and inspect the errors -&gt; find the issue and fix the config).<p>Management of certs could be improved in some edge cases. For example, I&#x27;d be happy if it was easier to manage certs in a private subnet. For example, say host A could acquire certs for my domain example.com with DNS challenge, then a host B, not public facing but in a subnet with A, could ask A to manage its certificates and still have valid https (letsencrypt provided certs) inside the network.

I see that it&#x27;s written in Rust, besides that, what&#x27;s your ambition for why an end user would choose this project over one of the established players like Caddy&#x2F;Traefik&#x2F;nginx?

I think for this web server to compete with caddy&#x2F;nginx (if the goal is getting other people to use it, if built for fun, please ignore) this needs a good reason to exist.<p>Memory-safe is nice compared to Nginx, but pretty moot when comparing to Caddy. OTOH, perhaps this could aim for better&#x2F;comparable performance to Nginx (and better than Caddy) whilst being memory safe? It’s still quite a niche use case though.

How many memory safety issues are found per year in the established servers (Apache and nginx)?<p>Why does the front page benchmark not include nginx?

1) The graph still shows karpacz, which is super confusing.<p>2) Where&#x27;s nginx in this graph? It feels very disingenuous. Esp when serving a default nginx page

As welcome as the efficiency and performance features are, the convenience of lets encrypt integration in Caddy wins the decision almost all the time. No more certbot cron jobs or worries about having the certs in the right place or permissions etc. for this to be equivalent to Caddy, that is the most important convenience feature.