Rama 0.3, a story over four years in the making
A year ago we celebrated the release of 0.2, which was a milestone in itself after three years of hard work, but it was very much still a work in progress. And while we aim to continue to work together with the Rama and wider Rust community for decades still to come on the Rama framework, we are now at a point where you should be able to start building with Rama without us changing the entire world over and over again.
If you compare rama 0.3 against the release we made a year ago you will clearly recognise it as the same framework, but the migration cost of a project built on 0.2 to rama 0.3 will be very real. Easily a day's work at the very least. The net effect will however be very positive as we have come a long way. It is as such with pride as well as great gratitude that I may present you all today the release of rama 0.3 on a wonderful day full of victories.
Before we start to time travel, allow me to make you a promise already.
This will be the last release where we have such a big gap since the previous release. Starting from today — with the release of rama 0.3 — our goal is to do fluid release trains of two to eight weeks, keeping SemVer compatibility in mind.
For technical details please read the full CHANGELOG — including the rama 0.3 release notes — at https://github.com/plabayo/rama/blob/main/CHANGELOG.md. And at any time you can find a summary of what protocols and other features are supported in Rama at https://ramaproxy.org/#features.
Origins and history recap
If you open the "Why Rama" chapter from the Rama book (community contributions to help improve this community resource are greatly appreciated by the way), you will read that in a (Rust) world of many network protocols but without Rama there are for the most part only two real approaches for building network services of any kind, but especially proxies:
- Use an "off-the-shelf" solution;
- Build it "from scratch".
The first can come in the form of a binary or remote resource which you may or may not be able to configure to various degrees. The more established ones also allow you to write plugins — good luck understanding their contracts such as lifetimes though. But you also see this approach in the form of a library/framework where you get some kind of engine that you can hook into via some kind of limited "happy path" API, either with code or a config that tries to look like code. If you're lucky they offer escape hatches, but here be dragons.
The second approach, building it from "scratch", is in principle almost always a lie, unless you write it in Pony, in which case... good for you. For the rest of us it usually results in a duct-taped project of a universe of libraries, some more compatible than others, with a lot of shortcuts, mistakes made by everyone trying this approach over and over again and hoping there might be some other person prior to you that bumped into that issue compatible with (or exactly the same as) your stack / lib (collection) of choice and wrote down the solution to your problem or a hint towards one.
Regardless of the approach, neither of which is ideal, you usually get some kind of developer velocity equal to the team's satisfactory scale. Great at first, but sooner or later the teams that choose such approaches start to gradually spend more and more of their time and brain power in working around their own technology stack, and climbing ever higher limitations, instead of being able to work on what actually matters to their customers or users... A working, useful and hopefully privacy-friendly application. With features that work, regardless of how it was made.
Rama, the foundation for your network service
This brings us to Rama, with the aim to become the foundation that you build your network services on, be it clients, servers, gateways or whatever proxy you are aiming to build.
Rama often puts proxies in the spotlight and uses them as the context framing how we present ourselves in several locations. Some of it is explained by our history, but most importantly it is because providing good support for building all the different types of proxies out there opens the gate to faithfully and completely supporting protocols, utilities and abstractions that also work great for building clients and servers on top.
This is a beneficial relation that goes both ways. The more support we offer for building clients and servers, the more that proxies also benefit, both for their typical use-cases and for all kinds of useful and often unexpected ways that proxies, especially the "advanced" ones, can make use of it. Providing for example great support for building web services allows one to also offer internal dashboards, emulated hijack services and more within a proxy. Just to give an example that covers the illustrative tip of the iceberg.
A lot of you got a taste of building with Rama with the 0.2 release in May of 2025. It was for us however mostly a flag that we wanted to plant to mark an important point in history. The years prior could be compared to the origins of Earth. Shaping itself, slowly but with powerful motions. It started with many early prototypes, but right from the start with use in large-scale production systems. A north star that has all this time guided us, and will continue to, now even more than ever.
In this time we started out building directly on top of tower-rs and hyperium, with HTTP being at the time our core focus. As Rust continued to evolve however, we started experimenting in Rust Nightly with tower-async, preparing for the brave new world now known as Rust edition 2024. Several rewrites later and even more refactors and a lot of sweat, time and mental wormholes made us arrive finally at 0.2.
Going with a universe of libraries — such as by building on top of hyperium and tower-rs — also means that change in such ecosystems is slow, if it comes at all, as it involves a global community of developers, all on their own islands, yet bound by the same contracts.
In reality it means you are pretty stuck in your design, not evolving with the language or the business needs, and instead trying to solve it via ever more layers and fragmented crates... part of what we covered before.
It was at that point that we finally had a clear vision (minus some details and lessons still to be learned) of what Rama was to become. This led us to several alpha releases in the first half and then half a year of (release) silence after that.
Do not be fooled however, as it was our most productive and active year so far. A year where we at Plabayo started dedicating our full-time attention to Rama, winding down all unrelated and other contracting work. It was also the year in which Brecht Stamper became my 2nd in command within the Rama project.
Rama in production
Over the last few years more and more people, organisations and companies started building projects — big and small — using Rama. Some of these companies became our first partners (see ramaproxy.com), within industries such as the hospitality industry (Data Extraction), Security (Developer Security, anti-bot, ...), AI (LLM harness, AI proxy gateways, ...), Cloud Infrastructure, proxy networks, web services / platforms and more.
In short, a world of network services is being built, more every day.
Commercial Partnerships are mutually beneficial relationships. They help us fund protocol and other work within Rama (gRPC, L4 proxy support such as macOS Network Extension are just some of many examples of this). These relationships were important for us right from the beginning but only became of a significant enough scale starting about a year ago, which allowed us to work full time on Rama.
Even with the release of rama 0.3, we and our partners will for the most part continue to use Rama from a pinned commit hash following the main Rama branch. It is what allows us to keep our work honest, get instant feedback on our progress and at the same time allows our partners and ourselves to reap the fruits of our hard work as soon as it is available.
For everybody else, know that with our fluid release trains starting from today, even the less adventurous ones should be able to join in this feast with the rest of us, by updating the Rama dependency every 2 to 8 weeks. Please do, and as part of our community, please continue to provide us with feedback, and help us improve Rama by contributing.
We at Plabayo also use Rama for all our own projects. Examples of some of our own web services built with Rama are this website and our Netstack.FM podcast — about networking, Rust and everything in between — which we began to do right after the rama 0.3.0-alpha.4 release, with the same passion with which we write educational material such as The Rust Language Guide and of course... Rama.
Our FOSS offline-first web learning tool for the Flemish education system is another nice example of that.
Thank you
We would like to take this release as an opportunity to thank everyone that made and continues to make Rama possible: our contributors, the projects that we depend upon as well as those that we forked, the wider Tokio and Rust ecosystem, our Sponsors and of course our Commercial Partners.
We look very much forward to the releases that will continue to come.
Curious? You can take a look at our milestones.
You can also subscribe to this Blog RSS feed or subscribe to our very own newsletter, written by us and your emails stored with privacy in mind within our own system made with Rama.
Are you building something with Rama alone or with your organisation? Do share it with us by email or Discord.
Be empowered. Be the change.