Rama 0.2 - 3+ years in the making
Rama 0.2 is finally here.
It took more than three years of work to get to this point. Not three years of writing code in a straight line, but three years of trying things, throwing things away, using it in anger, listening to partner companies, and shaping the project until it started to feel like something we could stand behind.
That matters to us. Software is a craft. It should not be rushed just because the market likes noise, or because a version number looks nice on a planning board. Rama exists because we kept running into the same problem: people who build serious network infrastructure often have to choose between a finished product that cannot quite be shaped, or a blank file where every low-level wheel has to be built again.
Rama is our attempt at a third option.
It gives you reusable building blocks for clients, servers and proxies, while still leaving the final shape of the system in your hands. Not a black box. Not a configuration-only wall. A framework you can read, adapt, compose and, when needed, fork.
What 0.2 means
This release is a checkpoint. It is not the end of the design, and it is certainly not the end of the work. It is however a point where we can say: the foundation is real.
Rama is already used in production by multiple companies, handling serious amounts of traffic. It remains experimental in the Rust sense: APIs can still move, and we still reserve the right to improve the shape of things when reality teaches us something. But experimental does not mean toy. It means we are honest about the fact that good infrastructure matures through use.
The central idea is simple:
- compose small services and layers instead of building one giant machine;
- keep common protocol work available as reusable crates;
- make the internals understandable enough that users can reason about them;
- optimize for ownership, not lock-in.
That last point is important. Rama is not trying to own your stack. It aims to help you own it better yourself.
What is included
The detailed technical release notes remain available in the original Rama 0.2 discussion, and the documentation lives at https://ramaproxy.org/.
In broad strokes, Rama 0.2 gives you:
- transport support for TCP, UDP, and stream middleware;
- HTTP support across servers, clients, routing, middleware, health checks, redirects and filesystem serving;
- TLS through Rustls and BoringSSL;
- DNS, HAProxy, and HTTP CONNECT proxying support;
- Tower-like Service and Layer abstractions;
- built-in tracing, metrics and OpenTelemetry;
- user-agent emulation, TLS profiles, JA3, JA4 and JA4H fingerprinting;
- connection pooling, graceful shutdown, Tower compatibility and a prebuilt CLI.
There are many crates in the Rama ecosystem, but for most users the starting point is simply https://crates.io/crates/rama.
And if you prefer learning from working code, the examples are here: https://github.com/plabayo/rama/tree/main/examples.
Why release now
Because at some point a project needs checkpoints. You cannot only keep carving in private forever.
0.2 gives users and partners something concrete to build against. It gives the community a shared base for feedback. It gives us a place from which the next design steps can be taken without pretending everything is still fluid.
The release also makes it easier to talk about Rama as more than a collection of features. It is becoming a way of building networked systems where the framework helps, but does not hide too much. For proxies especially, that balance matters. The details are often the product.
Looking at 0.3
The next cycle continues in the same spirit: small alpha releases, early feedback, and no fear of changing APIs when the change makes the long-term shape better.
The initial 0.3 plans include improved BoringSSL support, a stronger crypto story, WebSocket support, SOCKS5 support, and a reworked internal service design that removes the centralized Context.
You can follow the full 0.3 milestone here: https://github.com/plabayo/rama/milestone/2.
Community and support
Rama would not be where it is without the companies and individuals already using it, breaking it, asking sharp questions and funding parts of the work. That direct feedback matters even more to us because we do not build our products around tracking people. We depend on real conversations.
If Rama helps you, there are a few good ways to help it back:
- try it and open issues when something hurts;
- contribute fixes, examples or documentation;
- tell us what you are building, especially when Rama almost fits but not quite;
- sponsor the project;
- reach out at partner@ramaproxy.org for integration help, support contracts or custom feature development.
We build Rama because we believe programmable network infrastructure should be more open, more inspectable and more in the hands of the people operating it.
Be empowered. Be the change.