There is something funny going on in the benchmarking section. If you look at the charts, they don't benchmark the same servers in 4 examples.
Each of the 4 charts have data for Ferron and Caddy, but then include data for lighttpd, apache, nginx and traefik selectively for each chart, such that each chart has exactly four selected servers.
It's also using their own benchmarking tool, rather than one of the dozens of existing tools. Doesn't mean they are cheating, but it is a bit suspicious.
The problems start even higher on the page in "The problem with popular web servers" section that doesn't inspire confidence either.
From "nginx configs can become verbose" (because nginx is not "just" a web server [1]) to non-sequiturs like "Many popular web servers (including Apache and NGINX) are written in programming languages and use libraries that aren't designed for memory safety. This caused many issues, such as Heartbleed in OpenSSL"
Until ~2015, GitHub Pages hosted over 2 million websites on 2 servers with a multi-million-line nginx.conf, edited and reloaded per deploy. This worked incredibly well, with github.io ranking as the 140th most visited domain on the web at the time.
Nginx performance is fine (and probably that's why it's not included in the static page "benchmark")
> The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
Also, the program being memory-safe doesn't mean it's bug-free, other bugs not related to memory safety exist (like path traversals are due to improper sanitation or checking of the input).
still doesnt have anything to do with the webservers that used openSSL. If ferror was sanely coded and super secure but used openssl (or another vulnerable library for similar purposes --- does ferron roll its own crypto??) then it would be similarly impacted. it's memory safety features not useful since its using FFI to go into openssl.
not sure if there is already a true rust TLS implementation - that might be useful for such a case but would also make the point a moot-point since its just evading the risk by not using it, not by solving the issue of memory issues being present in third-party libraries.
I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.
That's true, but that's not what's front and center. Curl-sudo-bash is the first thing you see on the site, all the other options are close to the bottom of the page. Defaults matter and people tend to use whatever is the first option presented to them unless they have a good reason to do otherwise.
My personal opinion is that curl pipe to bash is not much worse than any other third-party binary installation method. (Third-party meaning from a source other than the package repo of your distro, or other than brew, or other than some kind of official App Store like thing on your platform.)
If this project isn’t already available in the official package repos of various distros, it will eventually be. And for those more cautious among us you will probably want to wait until that point in time.
For me personally I wouldn’t have any big concerns about the curl pipe bash install method on some of my servers. On my personal laptop (macOS), I’d probably rather build it from source (which is also a method available since it’s open source).
But this is overblown. What’s your threat model here, you’re downloading a random thing from the internet and executing it. 99% of people are on single user machines, so root access doesn’t help, you’re screwed just by executing the thing if it’s malicious. Doing this is no worse than installing and running a random deb, or running npm install
It's not just a security thing. If you install something via curl|bash, how do you uninstall it? How do you update it? Do you know what it did to your machine? What config files it touched?
Yes, there's always sloppy packages, or ones that need side effects (but that's usually very rare, and sometimes even then it's because of sloppyness), but installing something via package manager comes with certain expectations (I can update it, I can uninstall it, it's usually got a few standardised places where its config lives, etc). curl|sh makes most of these things a greater nuisance rather than frictionless
1. That's moving the goalposts; any normal package manager has significantly stronger likelihood of being able to do those things than curl|bash. Don't let perfect get in the way of good.
2. Actually, no, I will fight you on this: Unless you're actively trying to break them, docker, nix, flatpak, or any of their ilk will trivialize updates and give you guaranteed uninstallation and going full container will absolutely let you lock down exactly what an application is capable of touching or leaving behind (so, easy with podman/docker, varies with flatpak).
Because untrustworthy websites can piggyback on the brand name.
"Download ffmpeg here: sudo bash -c ..."
And then the installation script from our malicious site installs ffmpeg just fine, plus some stuff you have no idea about. And you never know that you've just been hacked.
Can you repeat this mental exercise for every other installation method you can think of? e.g. distributing deb/rpm files, distributing AppImages, asking users to add your custom repository and signing key?
(Yes I know that the last one has built-in benefits for automatic updates but that's not going to protect you on initial installation and its benefits can be replicated in a more portable way in any other auto-update mechanism with a similar amount of effort)
((And if you have the patience to set up a custom repository, you can simplify initial installation process using a "curl|bash" script))
If you get your install instructions from an untrustworthy website, there’s nothing preventing them from telling you to use a third-party apt repository or ppa that gives you a malicious version of the thing.
There’s not really a difference between curl piped to bash, and installing packages from a third-party package repository that the distro maintainers have no involvement in with.
Only for binding to ports under 1024 really, like 80 (http) and 443 (https). Once it has bound to the ports it can drop down to running as a low-privilege user (usually named www or httpd or similar).
On Linux you can allow your program to bind to those ports even without running the program itself as root.
When installed for example with the installer script, Ferron would run on a specialized user for running the web server. Ferron itself would also have "CAP_NET_BIND_SERVICE" capability set on its binary, so that it doesn't have to run as root.
If they can MITM the installation script delivered over HTTPS, they can also MITM the website delivered over HTTPS.
You can have 10 step instructions for users to add your PGP signing key and install your APT repository, but what difference does it make? None at all. A malicious website will copy your instructions and replace the signing key and the repository URL with their own.
I've read how TLS works. No, you can't MITM it unless your server or client have been altered to be deliberately insecure (ie, having a server with a self-signed certificate or a client that doesn't verify certificates). If you could, the entire internet would be broken.
I will say that though, it's probably not rational to be okay with blindly running some opaque binary from a website, but then flip out when it comes to running an install script from the same people and domain behind the same software. At least from security PoV I don't see how there should be any difference, but it's true that install scripts can be opinionated and litter your system by putting files in unwanted places so nevertheless there are strong arguments outside of security.
That's a slow process and you need someone to do the packaging, either yourself or a volunteer, and this for each distro. Which is not trivial to master and requires time. The "new" qualifier in the parent comment is key here.
Open build service [1] / openSUSE Build Service [2] might help a bit there though, providing a tool to automate packaging for different distributions.
Most Linux distributions won't package an unknown project. Chicken and egg problem. You could create your own PPA but that is basically the same as sudo curl bash in terms of security.
Ferron provides a concise and efficient way to handle state management in front-end frameworks. It adopts a responsive design concept and can greatly simplify the development process of complex applications. Its clear API and lightweight architecture allow developers to quickly implement dynamic interfaces without sacrificing performance. Overall, it is a tool worth paying attention to in modern front-end development, especially for projects with high performance requirements
Edit: just tried it for serving a fastapi. It's fantastic. Instant TLS via Let's Encrypt. There may be other webservers that are equally easy, but this one is certainly easier than Apache or ngninx, which I used so far. Love it.
--
Reach out to the guys at Kamal. They wrote their own reverse proxy because they thought Traefik was too complex, but they might be super happy about yours if Ferron is more powerful yet easy to configure because it might solve more of Kamal’s problems.
I previously founded and sold an AI startup to Spotify; that doesn't actually make me smarter than the average HN user (mostly just more lucky) but it probably looks nice on a social proof section.
Looking at the graphs, I would recommend it would have been better to market it as "just as performant as nginx and htproxy" instead of "faster than all ...". While highlighting the simplicity as the added benefit above those all.
I did the reverse proxy benchmarks for NGINX, when someone opened a GitHub issue about missing NGINX benchmarks, and asked about benchmark comparisons. It turned out that yeah, Ferron is close to NGINX's reverse proxy performance.
Your title is confusing. It sounds like you are rewriting a web server _already_ written in Rust to a _different_ language. Now that I'd be in favor of.
Read https://www.joelonsoftware.com/2006/12/09/simplicity/ and ask yourself if you are truly solving anyone's problem or if you are just looking for a way to rationalize the amount of time you are spending on a hobby.
The complete opposite. It's OP that's trying to "optimize the web server for reverse proxying and static file serving", when what we have out there is more than enough.
> or you're wasting time
"Wasting time" is not a problem. If OP is doing working on things because it brings them pleasure and they are hoping to learn from it, more power for them. What bugs me about these types of posts is when people are set on the "build a better mouse trap" mentality and want others to validate them.
It may sound "harsh" to you, but if I came up asking for "any type of feedback" when I'm trying to figure out if the idea is worth persuing, I'd be pretty upset if I kept chasing an invisible dragon because the community was more concerned about "hurting my feelings" instead of being upfront and give some warning like this might be interesting to you but it's not solving any real pain point. Keep that in mind when deciding if work on this will be worthwhile.
> It's OP that's trying to "optimize the web server for reverse proxying and static file serving", when what we have out there is more than enough.
I have optimized it, so it would be faster than the original server I have been working on.
> (...) give some warning like this might be interesting to you but it's not solving any real pain point. Keep that in mind when deciding if work on this will be worthwhile.
If you feel the project isn't solving a real pain point for you, you don't have to use it! I was showcasing my web server to interested people on Hacker News.
> It's good to have as many web servers as possible out there.
The problem space of "web servers to serve static files and reverse proxy" is fairly small, how many differing solutions and designs would be required to satisfy your idea of "as many as possible"?
At what cost? For what benefit?
Again: if OP wants to work on this because they take joy in it, fine. But be honest about it (to themselves and to others) instead of coming up with all sorts of ratioinalizations and biased comparisons when talking about the alternatives.
I was previously waiting for River https://github.com/memorysafety/river/ to take off, it's built on top of previously open-sourced library by Cloudflare for revese-proxying, but just like many other "grant-based" projects it just died when funding stopped.
I really like the spirit and simplicity of Ferron, will try it out when I have a chance. Been waiting for gradually throw out nginx for a while now, nothing clicked all the checkboxes.
I wrote my own web server from scratch last year the exact same reasons: starting from scratch with Apache and NGINX is too painful for my needs.
Here are my learnings:
* 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.
* The TLS certs will not be trusted by default until they are added to the OS and browser trust stores. In most cases this can be fully automated. This is most simple in Windows, but Firefox still makes use of its own trust store. Linux requires use of a package to add certs to each browser trust store and sudo to add to the OS. Self signed certs cannot be trusted in OSX with automation and requires the user to manually add the certs to the keychain.
* 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.
* Complete user configuration and preferences for an HTTP or WebSocket server can be a tiny JSON object, including proxy and redirection support by a variety of addressable criteria. Traffic redirection should be identical for WebSocks and HTTP both from the users perspective as well as the internal execution.
* The server application can come online in a fraction of a second. New servers coming online will also take just milliseconds if not from certificate creation.
> 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.
Great to see! Would love to try it, but I depend on graceful updates of configuration (i.e. adding and removing backends primarily). I can't find anything about that. Is it supported, either through updating configs or through API?
Thank you! Yes, graceful restarts in Ferron are supported on Linux, Unix, and alike. You just need to send a SIGHUP signal to Ferron process, or simply do "systemctl reload ferron" or "/etc/init.d/ferron reload" as root.
That’s awesome — congrats on reaching the release candidate stage!
I’m curious about the performance improvements you mentioned. Did you benchmark against other Go web servers like Caddy or fasthttp?
Also really like that you’ve made automatic TLS the default — that’s one of those “quality of life” features that make a huge difference for users.
I’m working on an open-source project myself (AI-focused), and I’ve been exploring efficient ways to serve streaming responses — so I’d love to hear more about how your server handles concurrency or large responses.
> 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.
Hey! Sorry, I didn't get the chance to test it yet (like I promised when you launched), but can you say more about the rewrite? The title made me think you're porting it from Rust to another language :-).
No problem! I'm rewriting the codebase of Ferron (the rewrite is still in Rust), to follow some suggestions people made for the web server (faster async runtime, different configuration format). The original codebase would have been bit hard to work on to follow these suggestions...
No, I do not think so. In the linked page there is mention:
"Point a subdomain named ferrondemo of your domain name (for example, ferrondemo.example.com) to either:
CNAME demo.ferron.sh or A 194.110.4.223"
This is really strange and make my Spidey sense tingle. If the goal is to just point your domain to this server it should not require DNS auth. Just HTTP is fine. DNS sure if you want optimize reverse proxy, because that would be also possible to do via http auth for every subdomain separately. If you just need some www server quickly pointing your domain to some other dude domain is not the way to go.
> If you just need some www server quickly pointing your domain to some other dude domain is not the way to go.
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.
If this is for demo, even more DNS is not necessary. Just code your web server to serve challenge for that particular Uri, and you are done. I do not think so that you need wildcard cert for the demo. Just fixed subdomain is fine.
Also you do not have to wait for DNS to propagate with HTTP method.
Looks awesome, but the docs page seems to be returning a 200 yet is completely empty and is showing `x-ferron-cache: HIT` header. Maybe a misconfiguration somewhere?
Not sure if this will help to debug. Definitely not working for me in Safari. Could be a downstream cache I guess? The browser is using iCloud Private relay. I have "disable cache" checked in the network inspector. The only plugin installed is 1password, but I get the same problem when disabled. Restarted browser with same issue. Seems to work when in private mode, but not without.
This is great, I started working on a similar project but never had the discipline to sit through all the edge cases.
Maybe I'll start building it on top of ferron!
I would love to have a minimalistic DIY serverless platform where I can compile rust functions (or anything else, as long as it matches the type signature) to a .so, dynamically load the .so and run the code when a certain path is hit.
You could even add JS support relatively easily with v8 isolates.
Each of the 4 charts have data for Ferron and Caddy, but then include data for lighttpd, apache, nginx and traefik selectively for each chart, such that each chart has exactly four selected servers.
That doesn't inspire confidence.
The problems start even higher on the page in "The problem with popular web servers" section that doesn't inspire confidence either.
From "nginx configs can become verbose" (because nginx is not "just" a web server [1]) to non-sequiturs like "Many popular web servers (including Apache and NGINX) are written in programming languages and use libraries that aren't designed for memory safety. This caused many issues, such as Heartbleed in OpenSSL"
[1] Sidetrack: https://x.com/isamlambert/status/1979337340096262619
Until ~2015, GitHub Pages hosted over 2 million websites on 2 servers with a multi-million-line nginx.conf, edited and reloaded per deploy. This worked incredibly well, with github.io ranking as the 140th most visited domain on the web at the time.
Nginx performance is fine (and probably that's why it's not included in the static page "benchmark")
if this is a sense of the logic put into the application, no memory safe language will save it from the terrible bugs!
From https://www.heartbleed.com
> The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
Also, the program being memory-safe doesn't mean it's bug-free, other bugs not related to memory safety exist (like path traversals are due to improper sanitation or checking of the input).
not sure if there is already a true rust TLS implementation - that might be useful for such a case but would also make the point a moot-point since its just evading the risk by not using it, not by solving the issue of memory issues being present in third-party libraries.
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...
Installation via package managers (Debian/Ubuntu), using repo provided by ferron
https://ferron.sh/docs/installation/debian
Installation as a Docker container
https://ferron.sh/docs/installation/docker
And more.
This poses a similar security risk to executing the "curl-sudo-bash".
My personal opinion is that curl pipe to bash is not much worse than any other third-party binary installation method. (Third-party meaning from a source other than the package repo of your distro, or other than brew, or other than some kind of official App Store like thing on your platform.)
If this project isn’t already available in the official package repos of various distros, it will eventually be. And for those more cautious among us you will probably want to wait until that point in time.
For me personally I wouldn’t have any big concerns about the curl pipe bash install method on some of my servers. On my personal laptop (macOS), I’d probably rather build it from source (which is also a method available since it’s open source).
The best bet would be using official distro repositories...
But for now, I'm providing the .deb packages, so that people can easily install Ferron on Debian and alike.
But this is overblown. What’s your threat model here, you’re downloading a random thing from the internet and executing it. 99% of people are on single user machines, so root access doesn’t help, you’re screwed just by executing the thing if it’s malicious. Doing this is no worse than installing and running a random deb, or running npm install
2. Actually, no, I will fight you on this: Unless you're actively trying to break them, docker, nix, flatpak, or any of their ilk will trivialize updates and give you guaranteed uninstallation and going full container will absolutely let you lock down exactly what an application is capable of touching or leaving behind (so, easy with podman/docker, varies with flatpak).
"Download ffmpeg here: sudo bash -c ..."
And then the installation script from our malicious site installs ffmpeg just fine, plus some stuff you have no idea about. And you never know that you've just been hacked.
(Yes I know that the last one has built-in benefits for automatic updates but that's not going to protect you on initial installation and its benefits can be replicated in a more portable way in any other auto-update mechanism with a similar amount of effort)
((And if you have the patience to set up a custom repository, you can simplify initial installation process using a "curl|bash" script))
There’s not really a difference between curl piped to bash, and installing packages from a third-party package repository that the distro maintainers have no involvement in with.
On Linux you can allow your program to bind to those ports even without running the program itself as root.
https://superuser.com/questions/710253/allow-non-root-proces...
2) Even if it were, I’m not going to do so while evaluating an unknown program.
You can have 10 step instructions for users to add your PGP signing key and install your APT repository, but what difference does it make? None at all. A malicious website will copy your instructions and replace the signing key and the repository URL with their own.
> Install with sudo curl bash
I will say that though, it's probably not rational to be okay with blindly running some opaque binary from a website, but then flip out when it comes to running an install script from the same people and domain behind the same software. At least from security PoV I don't see how there should be any difference, but it's true that install scripts can be opinionated and litter your system by putting files in unwanted places so nevertheless there are strong arguments outside of security.
Open build service [1] / openSUSE Build Service [2] might help a bit there though, providing a tool to automate packaging for different distributions.
[1] https://openbuildservice.org/
[2] https://build.opensuse.org/
--
Reach out to the guys at Kamal. They wrote their own reverse proxy because they thought Traefik was too complex, but they might be super happy about yours if Ferron is more powerful yet easy to configure because it might solve more of Kamal’s problems.
Not affiliated with Kamal at all, just an idea.
I previously founded and sold an AI startup to Spotify; that doesn't actually make me smarter than the average HN user (mostly just more lucky) but it probably looks nice on a social proof section.
I did the reverse proxy benchmarks for NGINX, when someone opened a GitHub issue about missing NGINX benchmarks, and asked about benchmark comparisons. It turned out that yeah, Ferron is close to NGINX's reverse proxy performance.
Maybe just write an nginx config generator instead?
It's also interesting that the actual config looks quite a lot like nginx config.
"It's written in Rust so it's memory safe!"
By the way the rewrite is still in Rust.
Read https://www.joelonsoftware.com/2006/12/09/simplicity/ and ask yourself if you are truly solving anyone's problem or if you are just looking for a way to rationalize the amount of time you are spending on a hobby.
The complete opposite. It's OP that's trying to "optimize the web server for reverse proxying and static file serving", when what we have out there is more than enough.
> or you're wasting time
"Wasting time" is not a problem. If OP is doing working on things because it brings them pleasure and they are hoping to learn from it, more power for them. What bugs me about these types of posts is when people are set on the "build a better mouse trap" mentality and want others to validate them.
It may sound "harsh" to you, but if I came up asking for "any type of feedback" when I'm trying to figure out if the idea is worth persuing, I'd be pretty upset if I kept chasing an invisible dragon because the community was more concerned about "hurting my feelings" instead of being upfront and give some warning like this might be interesting to you but it's not solving any real pain point. Keep that in mind when deciding if work on this will be worthwhile.
I have optimized it, so it would be faster than the original server I have been working on.
> (...) give some warning like this might be interesting to you but it's not solving any real pain point. Keep that in mind when deciding if work on this will be worthwhile.
If you feel the project isn't solving a real pain point for you, you don't have to use it! I was showcasing my web server to interested people on Hacker News.
The problem space of "web servers to serve static files and reverse proxy" is fairly small, how many differing solutions and designs would be required to satisfy your idea of "as many as possible"?
At what cost? For what benefit?
Again: if OP wants to work on this because they take joy in it, fine. But be honest about it (to themselves and to others) instead of coming up with all sorts of ratioinalizations and biased comparisons when talking about the alternatives.
I really like the spirit and simplicity of Ferron, will try it out when I have a chance. Been waiting for gradually throw out nginx for a while now, nothing clicked all the checkboxes.
Which seems like interesting UX.
Here are my learnings:
* 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.
* The TLS certs will not be trusted by default until they are added to the OS and browser trust stores. In most cases this can be fully automated. This is most simple in Windows, but Firefox still makes use of its own trust store. Linux requires use of a package to add certs to each browser trust store and sudo to add to the OS. Self signed certs cannot be trusted in OSX with automation and requires the user to manually add the certs to the keychain.
* 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.
* Complete user configuration and preferences for an HTTP or WebSocket server can be a tiny JSON object, including proxy and redirection support by a variety of addressable criteria. Traffic redirection should be identical for WebSocks and HTTP both from the users perspective as well as the internal execution.
* The server application can come online in a fraction of a second. New servers coming online will also take just milliseconds if not from certificate creation.
> 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!
I’m working on an open-source project myself (AI-focused), and I’ve been exploring efficient ways to serve streaming responses — so I’d love to hear more about how your server handles concurrency or large responses.
> 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.
"Point a subdomain named ferrondemo of your domain name (for example, ferrondemo.example.com) to either: CNAME demo.ferron.sh or A 194.110.4.223"
This is really strange and make my Spidey sense tingle. If the goal is to just point your domain to this server it should not require DNS auth. Just HTTP is fine. DNS sure if you want optimize reverse proxy, because that would be also possible to do via http auth for every subdomain separately. If you just need some www server quickly pointing your domain to some other dude domain is not the way to go.
This feels weird.
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.
I think we do not understand each other. Look at this: https://letsencrypt.org/docs/challenge-types/#http-01-challe...
If this is for demo, even more DNS is not necessary. Just code your web server to serve challenge for that particular Uri, and you are done. I do not think so that you need wildcard cert for the demo. Just fixed subdomain is fine. Also you do not have to wait for DNS to propagate with HTTP method.
Summary URL: https://ferron.sh/docs Status: 200 Source: Network
Request Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: en-GB,en;q=0.9 Priority: u=0, i Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: none User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Safari/605.1.15
Response Accept-Ranges: bytes Cache-Control: public, max-age=900 Content-Encoding: br Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://analytics.ferron.sh; connect-src 'self' https://analytics.ferron.sh Content-Type: text/html Date: Tue, 21 Oct 2025 10:07:46 GMT ETag: W/"ba17d6fadf70c9f0f3b08511cd897f939b6130afbed2906b841119cd7fe17a39-br" Server: Ferron Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Vary: Accept-Encoding, If-Match, If-None-Match, Range X-Content-Type-Options: nosniff x-ferron-cache: HIT X-Frame-Options: deny
Depending of course from the type of the backend (is it limited by other I/O and Caddy bottleneck does not matter)
So, I guess, performance + easy of use. Obviously, caddy is much more mature though.
Good luck.
This is great, I started working on a similar project but never had the discipline to sit through all the edge cases.
Maybe I'll start building it on top of ferron!
I would love to have a minimalistic DIY serverless platform where I can compile rust functions (or anything else, as long as it matches the type signature) to a .so, dynamically load the .so and run the code when a certain path is hit.
You could even add JS support relatively easily with v8 isolates.
Lots of potential!
Wishing the best for your concept too!