Gruxi Web Server

Appearance

Gruxi Release - 1.0.0 ​

Post date: 23 Apr 2026

We are excited to announce that Gruxi 1.0.0 is now available. This release marks a significant milestone for the project, and we are happy to finally ship a major release. We have been using Gruxi on the gruxi.org production website from the beginning to validate its stability and performance with real-world traffic, and it feels good to now bring it to a 1.0 release.

Want to try it out? ​

Check out the Getting Started guide to get started with Gruxi 1.0.0, and let us know what you think. We are excited to see how Gruxi performs in real-world scenarios and to hear your feedback on the release.

Features in 1.0.0 ​

The feature list below is from the project README, as it provides a good summary of what is included in the 1.0.0 release.

Core ​

  • Event‑driven architecture with low per‑request CPU and memory overhead
  • Extremely fast static file serving
  • High‑performance in‑memory file cache
  • Content compression

Protocols & networking ​

  • HTTP/1.1 and HTTP/2 support
  • Reverse proxy with TLS offloading
  • Load balancing and health checks
  • Caching headers and conditional requests
  • Range request support

TLS & security ​

  • Built-in TLS support
  • Automatic certificate issuance and renewal via Let’s Encrypt

Administration ​

  • Built-in web interface for administration, configuration, and monitoring
  • Live metrics and server status
  • Windows service support and Linux systemd integration
  • Prometheus metrics support

Application support ​

  • PHP support via PHP‑FPM
  • Managed PHP‑CGI on Windows, with easy version switching

Logging ​

  • System logging
  • Access logging
  • Built-in log rotation, with no external tools required

Performance in 1.0.0 ​

Performance has been a key focus throughout development, and we are proud to say that Gruxi 1.0.0 delivers excellent results across a variety of scenarios. We have made significant improvements to request handling, reduced latency, and optimized resource usage. We are especially proud of the tight latency curve, with very few outliers. To us, that tells the story of a predictable and stable system, which is exactly what we are aiming for. Even with a few thousand concurrent connections, we are seeing strong performance with low CPU usage. This reflects the efficiency of our async execution model and the careful attention we have paid to minimizing allocations on hot paths.

We run benchmarks continuously during development on our dev machines to make sure we are on the right track and to catch performance regressions early. To give a sense of the current results, here are a few numbers we are happy with.

Test environment ​

  • CPU: AMD Ryzen 9 9950X3D 4.3 GHz
  • Memory: DDR5 4800 MHz
  • Storage: Samsung 9100 PRO 4TB
  • Operating system: Windows 11

Benchmark setup ​

  • Tooling: Oha (https://github.com/hatoo/oha)
  • Tested version: 1.0.0
  • TLS: Disabled (to focus on raw request handling)
  • File cache: Enabled
  • Content type: Static file (default index.html for Gruxi)
  • Concurrency: 100
  • Request count: 1,000,000
  • Operation mode: "PRODUCTION" (request/response logging disabled except for errors)
  • Command executed: .\oha-windows-amd64.exe -c 100 -n 1000000 --no-tui http://127.0.0.1

For this release, with 100 concurrent connections, we see around 187,000 requests per second, with a median latency of around 0.5 ms and 99% of requests completing within 1 ms. Combined with low CPU usage, this shows that Gruxi can handle heavy load with very strong performance.

Performance test results for static files

In our benchmark suite, which measures only the code path and takes TCP out of the equation, we see around 600,000 requests per second. This shows that the core of Gruxi is highly efficient and can handle high load with very low latency.

We are happy with this performance on the machine we are using for testing. Most servers will likely perform even better, and we are excited to see how Gruxi behaves in real-world scenarios as more users start running it in production. We are committed to continuing to optimize Gruxi in future releases, and we are always looking for ways to make it even faster and more efficient.

What’s next for Gruxi ​

This first major release is a significant milestone and signals that we consider Gruxi production-ready. That said, we have been doing this long enough to know that bugs will still turn up, and we are committed to fixing them as quickly as possible.

We also have many features on the drawing board for later releases, such as:

  • HTTP/3 support
  • Rate limiting
  • Improved redirects and rewrites
  • Easier deployment options, such as Proxmox scripts and MSI packages
  • User management
  • And more.