Back

Ferron 3.0.0-beta.9 released

Published on:

Today, we’re releasing Ferron 3.0.0-beta.9, the ninth beta release of Ferron 3.

If the last few betas were about observability, resilience, and configuration ergonomics, beta.9 is about enterprise readiness, protocol correctness, and giving you more control over traffic routing and caching. This release introduces FIPS-certified cryptography builds, native canary deployments, persistent HTTP caching, and a major under-the-hood shift to our custom HTTP/2 and HTTP/3 implementations.

Here is what’s new.

Enterprise-ready: FIPS builds and SBOMs

For environments with strict compliance requirements, Ferron now offers FIPS-certified cryptography builds. By compiling with the fips feature (via AWS-LC and rustls), OCSP stapling, TLS cipher suites, key exchange groups, and HTTP basic auth password verification are restricted strictly to FIPS-approved algorithms.

FIPS artifacts are clearly marked with a +fips suffix (e.g., ferron+fips-<version>-<target>.tar.gz), and Docker images use the -fips tag. You can enable this via Cargo, our build tooling, or Docker build arguments.

Alongside this, every release archive now ships with a Software Bill of Materials (SBOM) in CycloneDX format (JSON and XML). This gives you full, automated visibility into the third-party Rust crates compiled into your binaries. FIPS releases ship with matching SBOM archives.

Native canary deployments

You no longer need an external load balancer or reverse proxy to run canary rollouts or A/B tests for static content. The new canary directive assigns each request a weighted variant with consistent-hash sticky affinity.

example.com {
    canary rollout {
        variant stable 90
        variant next 10
    }
}

Affinity can be based on IP, a cookie, or a request header. With the set_cookie sub-directive, Ferron can even generate and manage the sticky cookie for you, ensuring assignments survive client IP changes. Variants are exposed as variables like {{canary.variant}}, making it trivial to serve different document roots or proxy to different upstreams based on the rollout weight.

HTTP caching: persistence and RFC 9111 compliance

The HTTP cache engine has received a massive overhaul in beta.9, focusing on durability and strict specification compliance.

First, on-disk cache persistence. By setting persist <dir> in your cache block, Ferron writes cache mutations to a journal and periodic snapshots, allowing your HTTP cache to survive process restarts.

{
    cache {
        max_entries 4096
        persist /var/cache/ferron
        persist_interval "10s"
        zone "shared_assets" {
            max_entries 8192
            persist /var/cache/ferron-shared
        }
    }
}

example.com {
    cache {
        zone "shared_assets"
    }
}

Second, we’ve done a deep dive into RFC 9111 compliance and correctness. This includes proper freshness lifetime precedence, 304 revalidation header merging, Vary header normalization, scoped PURGE requests, and improved stale-while-revalidate (SWR) behavior with singleflight coalescing. We’ve also bounded cardinality for private keys and stripped query strings from fingerprints to prevent cache fragmentation and information leakage.

Under the hood: custom HTTP/2 & HTTP/3

Ferron’s HTTP/2 and HTTP/3 functionality now relies on vibeio-http’s in-house protocol implementations instead of Hyperium’s h2 and h3.

The new HTTP/2 implementation achieves higher space savings for headers (~95%), while the HTTP/3 implementation boasts improved protocol compliance (scoring 47/49 on h3spec). Furthermore, QUIC endpoints are now per-thread instead of single-threaded, which significantly improves throughput and tail latency for HTTP/3 requests.

We also wrote a detailed deep-dive on this transition: Building custom HTTP/2 and HTTP/3 implementations in vibeio-http.

To squeeze out even more performance, Profile-Guided Optimization (PGO) is now enabled by default for our pre-built GNU/Linux and musl binaries, specifically targeting improvements in p90/p99/max tail latencies.

Observability: StatsD, OTLP tuning, and drift hints

  • StatsD metrics export: the observability block now supports provider statsd over UDP, complete with DogStatsD extensions for metric tags and histograms.
  • OTLP tuning: the OTLP exporter (now a custom implementation replacing the OpenTelemetry SDK to lift previous limitations) supports gzip compression, metric exemplars, and fine-grained batching intervals.
  • Configuration drift hints: a new ferron.admin.config_drift metric and Admin API field detects when configuration source files have changed on disk but haven’t been reloaded, emitting a warn-level log so you know exactly when your running config is out of sync.
  • Dynamic log filenames: access_log and error_log directives now support variable interpolation (e.g., access_log /var/log/ferron/{{accesslog.header_host}}/access.log), making per-vhost or per-level logging effortless.

Quality of life and flexibility

  • .ferron file extension: You can now use .ferron as an alternative to .conf for your configuration files, for better editor support
  • Variable interpolation everywhere: Interpolation ({{name}}) now works in map results, CORS origins, and via new built-in variables like request.uri.query.<param> and request.cookie.<name>.
  • Honoring Cache-Control: Ferron now strictly honors RFC 9111 request directives like max-age, min-fresh, and only-if-cached during cache lookups.
  • ferron directives CLI: A new subcommand that dumps the entire registered configuration schema as structured JSON, perfect for building editor integrations and tooling.

A mountain of fixes

Beta.9 includes an extensive list of correctness fixes across the board. Highlights include:

  • Fixing a stall where poll listeners would only accept a single connection.
  • Correcting trailing slash redirection logic when index files are involved.
  • Fixing HTTP/2 Host vs :authority header handling to comply with RFC 9113.
  • Resolving memory and background task leaks during reverse proxy configuration reloads.
  • Fixing CORS Vary: Origin header overwrites and ensuring CORS headers are added for non-wildcard origins.
  • Ensuring weak ETags are stripped from 206 Partial Content range responses.

(See the full changelog for the complete list!)

Looking ahead

Beta.9 represents a massive leap in protocol correctness, caching reliability, and enterprise compliance. As we finalize these core engine upgrades, the remaining beta cycle will focus on final polish, ecosystem stabilization, and preparing for our first Release Candidate.

As always, feedback, bug reports, and testing results are welcome.

Full changelog

The complete changelog for Ferron 3.0.0-beta.9 is available in the release notes.

Try it

Install Ferron 3 using the installer:

sudo bash -c "$(curl -fsSL https://get.ferron.sh/v3)"
Share this post!
X Facebook Linkedin Threads
Newer Improving browser (and no-JS) compatiblity for the new site Older (Vibe?) building custom HTTP/2 and HTTP/3