The State of rrweb: Coming Home

A Promise Kept#

Six months ago, I wrote about leaving Kilo Code. In that post I said something that, at the time, felt like a footnote:

"I've neglected rrweb, another open-source project I maintain. It's time to step back."

That wasn't a footnote. That was a promise. And today I'm writing to tell you what happened when I finally kept it.

I've been an rrweb core team member since 2021. For most of that time, I was also running other ventures: RecordOnce, consulting gigs, and then the intense six-month sprint at Kilo Code that consumed every waking hour. rrweb kept growing despite my partial attention, which is a testament to the incredible community around it, but it also meant the project was running on inertia when it deserved intention.

When I stepped away from Kilo Code, I didn't immediately jump into the next thing. I spent time with my family. I picked my kid up from school without taking calls on the bike. I slept. And then, slowly, I started looking at rrweb with fresh eyes.

What I found was both exciting and sobering.

19,000 Stars and a Growing Opportunity#

rrweb today has over 19,000 GitHub stars. It's the most widely used open-source session replay library on the web. If you've used a product with session replay built in (and you almost certainly have), there's a good chance rrweb is running under the hood.

The adoption is staggering. Companies use rrweb to power observability platforms, experience analytics, bug reporting tools, browser automation, and demo environments. Some of the world's leading brands rely on it. Datadog, New Relic, Sentry. The ecosystem that depends on rrweb is enormous.

But here's the opportunity: using rrweb in production at scale creates an important infrastructure opportunity.

The library itself does its job brilliantly. It captures DOM mutations, serializes them, and lets you replay them with pixel-perfect fidelity. What it doesn't do is store those sessions, deduplicate them, index them, or serve them back efficiently when you have millions of recordings. Every team that deploys rrweb at scale has to build that entire infrastructure layer themselves.

I know because I've watched them do it. I've seen the GitHub issues. I've had the calls. Smart engineering teams spending months building storage backends, deduplication pipelines, and replay serving infrastructure, solving the same problems over and over again, independently of each other.

That's the scaling opportunity: helping teams build the infrastructure around a library they already trust.

What We Built#

So we built the thing everyone was building for themselves.

rrweb Cloud is managed session replay infrastructure. It's the full stack you need to run session replay in production: storage, indexing, deduplication, query, and replay. All optimized specifically for rrweb's data format, operated by the team that actually maintains the library.

Let me be specific about what this means in practice:

If you're already self-hosting rrweb, nothing changes for you. The open-source library remains MIT licensed. You can keep doing exactly what you're doing. But if you're tired of maintaining your own storage backend, or if you're hitting scale and don't want to invest engineering time in infrastructure, you can now point your rrweb sessions at our cloud and we'll handle the rest.

If you're evaluating rrweb for a new project, you can start recording sessions in minutes with a free tier (no credit card required) and scale up with transparent, usage-based pricing as you grow.

If you're building a product that embeds replay (an observability tool, a testing platform, a support widget), you can license the full platform stack and deploy it on your own infrastructure with our support.

This isn't a pivot. It's a logical extension. The open-source library handles recording and replay. The platform handles everything else.

The Question I Know You're Going to Ask#

"Is rrweb going commercial? Are you selling out?"

I'd be disappointed if the community didn't ask this. Healthy skepticism about open-source commercialization is a feature, not a bug. I've been on the other side of this enough times to know that a vague "don't worry, we're committed to open source" isn't going to cut it. So let me be concrete.

The recording library stays MIT. Full stop. The core rrweb packages (rrweb, rrweb-player, rrweb-snapshot, @rrweb/record) are MIT licensed today and they will remain MIT licensed. We are not relicensing the library. We are not adding "open core" restrictions. We are not building features into the library that only work with our cloud. The library is the library. It works with any backend, including yours.

The platform layer is source-available with licensing designed to protect your investment. This is the managed infrastructure: the storage engine, deduplication, indexing, and serving layer. You can read the code, audit it, and adapt it to your needs. If you're interested in the platform license, reach out and we'll walk through the details together.

We built cloud hosting to fund the open-source library, not to replace it. Every dollar we make from cloud hosting goes back into maintaining and improving the library that 19,000 developers starred because it solved a real problem. Sustainability isn't a dirty word. It's the only way rrweb survives the next decade.

What We Are (and What We're Not)#

I want to be very clear about positioning, because I think this matters for trust:

We are building infrastructure that complements session replay products. Hotjar, FullStory, LogRocket, and the many products in this category give teams powerful end-user experiences: dashboards, heatmaps, analytics, and workflows. They're great at what they do.

We are the infrastructure layer that companies like those build on top of.

If you need a session replay feature inside your product - if you're building an observability platform, a testing tool, a support solution, a demo environment - rrweb is the replay engine and rrweb Cloud is the managed infrastructure that runs it. We power the platforms. We don't compete with them.

This distinction matters because it defines who we're building for. We're building for developers and engineering teams at technology companies who need replay as a capability inside their product, while the established end-user platforms continue serving marketing, product, and growth teams exceptionally well.

The Deployment Choice#

One of the things that has shaped our thinking about infrastructure tooling is that teams deserve meaningful deployment choice: self-hosting offers direct ownership, while managed services offer operational simplicity.

We rejected that framing. rrweb gives you a genuine choice:

Open Source - Self-host, self-operate, MIT licensed. Use the most trusted session replay library in the world for free, forever. Community support. Build your own.

Public Cloud - Fully managed by the rrweb team. Zero-ops, instant setup, usage-based pricing. Start free, pay as you grow.

Platform License - Deploy the full rrweb stack on your own cloud. Your infrastructure, our software, enterprise support and SLA.

These aren't just marketing tiers. They represent fundamentally different deployment architectures. You can start with open source and migrate to cloud without rewriting anything. You can run cloud in dev and self-host in production. You can license the platform for your largest customers and use the cloud for everyone else.

Deploy where it makes sense. Not where we tell you.

The Road Ahead#

Coming back to rrweb full-time after six months away felt like coming home. The community is stronger than ever. The codebase is solid. And now we have a sustainable model that lets us invest in both the library and the infrastructure around it.

Here's what's coming:

We're opening early access to rrweb Cloud in the coming weeks. If you're already running rrweb in production and want to simplify your infrastructure, or if you're building something new and want to start fast, I'd love to have you in the program. We're specifically looking for teams who can help us pressure-test the platform at scale and give us honest feedback.

We're also going to keep shipping library improvements. The 1.0 release was a milestone, but there's so much more to do: better performance, better privacy controls, better support for modern web platform features. Cloud revenue means we can dedicate real engineering time to the open-source library, not just squeeze it in between other commitments.

And personally, I'm going to be more present. More responsive on GitHub issues. More available in the community. More willing to have the hard conversations about where rrweb goes next. I owe the community that, and I'm here for it.

Join the Early Access#

If you want to be part of the first cohort using rrweb Cloud, reach out. We're keeping the early access program small and intentional. We want teams who will actually push the platform hard and tell us what's broken.

You can find me on X (@Juice10), on GitHub, or just reply to this post.

rrweb has always been a community-first project. That doesn't change because we're building a business around it. If anything, the business exists to make the community stronger.

Let's build.

Justin

---

If you're interested in learning more about rrweb Cloud, visit rrweb.com. If you want to contribute to the open-source library, the repo is at github.com/rrweb-io/rrweb. And if you have questions or concerns about any of this, I genuinely want to hear them. The comments are open.