I was working a lot on it recently...

https://ferron.sh/blog/ferron-3-0-0-beta-2-released

> # SKILL: Web Server Replacement > > ## Description > > Replace Ferron web server with Claude. > > ## Steps > > 1. Receive HTTP request > > 2. ... > > 3. Wait, I don't have access to TCP sockets > > 4. I literally cannot bind to port 80 > > 5. I am a language model, not a systems process > > 6. I cannot handle 10,000 concurrent connections > > 7. I do not have an event loop > > 8. I cannot serve static files from disk > > 9. I am not compiled to native code > > 10. I run in a datacenter behind... a web server > > 11. The irony is not lost on me > > 12. Please close this file > 13. > > 13. ## Conclusion > > 14. No. Just no.

Also, the "Clawd"... :)

In 2025, I have learned Rust by creating a project in it (a web server), and learned a lot about web servers and reverse proxies along the way. I have seriously leveled up as a developer.

I have also created what's now the most popular project I have ever created.

I think in 2026, I'll go even further!

Now that I released Ferron 2, I'm sharing the announcement blog post.

What do you think?

By the way the rewrite is still in Rust.

You can read how Rustls compares to other TLS implementations, when it comes to implementation vulnerabilities, from the Rustls manual: https://docs.rs/rustls/latest/rustls/manual/_01_impl_vulnera...

Yeah. But as I said before, people installing Ferron on their servers don't need to use this demo. Oh, and people using this demo don't need to install Ferron on their servers.

I just added two notices to this demo:

> Note: After completing the demo, it's recommended to delete the subdomain you have just created to prevent security issues.

> This demo setup is optional and exists only to demonstrate automatic TLS functionality. You do not need to point any subdomain to demo servers for normal use of Ferron.

Wishing the best for your concept too!

> Did you benchmark against other Go web servers like Caddy or fasthttp?

I have already benchmarked Ferron against Caddy! :)

> so I’d love to hear more about how your server handles concurrency or large responses.

Under the hood, Ferron uses Monoio asynchronous runtime.

From Monoio's GitHub repository (https://github.com/bytedance/monoio):

> Moreover, Monoio is designed with a thread-per-core model in mind. Users do not need to worry about tasks being Send or Sync, as thread local storage can be used safely. In other words, the data does not escape the thread on await points, unlike on work-stealing runtimes such as Tokio. > For example, if we were to write a load balancer like NGINX, we would write it in a thread-per-core way. The thread local data does not need to be shared between threads, so the Sync and Send do not need to be implemented in the first place.

Ferron uses an event-driven concurrency model (provided by Monoio), with multiple threads being spread across CPU cores.

> TLS (HTTPS) can be easily enabled by default, but it requires certificates. This requires a learning curve for the application developer but can be automated away from the user.

Yeah, these certificates can be obtained from Let's Encrypt automatically.

> Everything executes faster when WebSockets are preferred over HTTP. An HTTP server is not required to run a WebSocket server allowing them to run in parallel. If the server is listening for the WebSocket handshake message and determines the connection to instead be HTTP it can allow both WebSocket and HTTP support from the same port.

Oh, seems like an interesting observation!