Rama 0.3.0-alpha.4 - the last planned alpha
This is planned to be the last alpha release before Rama 0.3 moves into release candidates.
There is still work to do. In particular, we want rama-grpc support landed (#488), and we want the new URI implementation in rama-net to be used more deeply (#724). That URI work should improve Request itself and help replace RequestContext and TransportContext with scoped traits that can retrieve things such as path and URI from input in a simpler, more stateless way.
Those changes will unlock a few smaller improvements as well. The full milestone remains here: https://github.com/plabayo/rama/milestone/2. Not every issue in that list must land before 0.3. Some items may move, and some may be dropped. That is part of keeping a milestone honest.
Once URI, gRPC and a few remaining features such as multipart support are ready, we plan to start release candidates. The intention is one or two release candidates, then a final 0.3 release around the end of January 2026.
After that, the plan is to move Rama to a regular six-week release train. Whatever is ready on main can then ship as a patch or major release, depending on whether breaking changes are involved.
The main story: removing Context
The largest change in this alpha is architectural.
The centralized Context type has been removed. State, data and executors now move through extensions attached to the Request, Response or Connection. This brings Rama closer to standard Rust middleware patterns, and more importantly it makes complex service stacks less dependent on one large object being carried everywhere.
This was not a cosmetic rename. It touched the way state flows through services. Parts of the http request and response modules were integrated and forked so Rama can support its extension model properly. Extensions are now supported throughout rama-http-core for both HTTP/1.1 and HTTP/2. New utilities such as AddInputExtensionLayer, AddOutputExtensionLayer and IntoEndpointServiceWithState help with state injection.
During the work we also explored parent extensions. The design became simpler than that. At this point it is essentially a list of extensions that can be forked. That may sound small, but simplification after exploration is often where the real work is.
There may still be minor changes before 0.3 final, but the largest design movement around context, state and extensions is now behind us.
Service now speaks Input and Output
The Service trait now uses Input and Output instead of Request and Response.
That is a better fit for Rama. Services and layers do not only operate at the HTTP level. They also operate around transports, TLS and other protocol boundaries where the words request and response do not always make sense.
This is the kind of naming change that looks small in a changelog, but it changes how natural the framework feels when you build outside the common HTTP path.
Other important work
The CLI was reorganized around send, serve and probe. It gained stunnel-like TLS tunneling, request export to curl, HAR recording, probe tcp, and --resolve support. Windows CLI releases are signed through SignPath.
Protocol work continued with the RFC 863 discard service for TCP and UDP, Akamai HTTP/2 passive fingerprinting, post-quantum encryption support in BoringSSL, and OTLP/subscriber support directly in the core rama crate.
HTTP gained typed headers for X-Robots-Tag, X-Clacks-Overhead, DNT and Sec-GPC, support for NDJSON and improved JSON streaming, octet-stream responses, HSTS examples and tests, and redirect, rewrite and forward services.
ACME support gained DNS-01 challenges, TXT record lookup support, wildcard handling and raw PEM certificate download.
There were also many internal improvements: more consistent API naming, AddInputExtension and AddOutputExtension, faster hash maps through ahash, asynk-strim instead of async-stream, allocation improvements with SmallVec and SmolStr, syncs with upstream forks such as hyper, h2, tungstenite and tower-http, and an MSRV bump to Rust 1.91.
Important fixes include an HTTP/2 emulation bug around window update replay and early frame replay, gzip decompression with empty bodies and trailers, a new streaming compression option for SSE and chunked endpoints, and RFC 6265 cookie merging when downgrading HTTP/2+ requests to HTTP/1.x.
Some concepts were removed as well. RequestInspector is gone in favor of normal services and layers. The custom UDP socket wrapper was removed in favor of re-exporting tokio::net::UdpSocket. Extensions no longer support remove(), so information leaves a more predictable trail. ErrorWithExitCode was removed because it was not reliable enough for complex error propagation.
The full source release remains here: https://github.com/plabayo/rama/releases/tag/rama-0.3.0-alpha.4.
Community
Thank you to everyone who contributed to this release: Glen De Cauwsemaecker, Abdelkader Boudih, Nicolas Trippar, M-Kusumgar, Brecht Stamper, Ali Tariq, Camille Louédoc-Eyriès, sim-hash, Irfan - ئىرفان, Yukun Wang, hafihaf123, Aydan Pirani, Kenny Lau and MeerKatDev. Thank you also to the wider ecosystem and the maintainers of the third-party crates that make this work possible.
A special shoutout goes to Brecht Stamper for stepping up to help maintain Rama and for driving a large part of this release. His work was instrumental in the service and state API redesign, ACME support, TLS improvements, pooled connections and much more.
This kind of work is only possible because people use Rama, report what hurts, contribute fixes and fund parts of the roadmap. One of the planned remaining 0.3 features, gRPC support, is funded by a commercial partner. That is a good example of how open source work can move forward in a way that helps both one user and the wider community.
Looking ahead
The focus now is narrow: finish the remaining design work, ship release candidates, and make 0.3 stable enough that people can plan around it.
If you are already using Rama, this is a good moment to test the alpha and report migration pain. If you are waiting for 0.3, the project is getting close.
You can help by opening issues, contributing, improving documentation and examples, sponsoring Rama, or reaching out at partner@ramaproxy.org for support contracts, integration help or custom feature development.
Be empowered. Be the change.