Real-Time Collaboration in a Cloud IDE

As part of our engagement with Google, we built real-time collaboration into their cloud-based IDE. Multiple developers editing the same workspace simultaneously, with live cursors, presence indicators, and a shared experience that just worked.

This is how we pulled it off.

Real-Time Collaboration in a Cloud IDE cover image

Not Your Typical Live Share

If you've used Microsoft's Live Share, you might think this is a solved problem. But Live Share is peer-to-peer: one developer hosts from their local machine and guests connect through a relay. Our situation was fundamentally different. The workspace already lived in a cloud VM. There was no host machine. We needed to make a single remote environment collaborative, not bridge two local ones.

Why We Forked VS Code

We started by trying to build this as a VS Code extension using Yjs, a CRDT library for real-time synchronization. But Yjs needs synchronous access to the document model, and the VS Code extension API is entirely asynchronous. Edits would race and state would diverge. We also tried building our own sync engine from scratch and hit the same walls.

That work wasn't wasted though. It gave us the evidence to confidently recommend that Google fork VS Code. At the time they were essentially wrapping the upstream codebase with minimal changes, so a fork felt like a big step. But collaboration wasn't the only feature that needed internal access, and that made the decision easier. With the fork in place, we worked directly with the creator of Yjs to build a proper VS Code binding.

Solving for Scale

Every new connection to a workspace spun up a full set of backend processes. On standard 8 GB VMs, a handful of users would exhaust memory. Only the 64 GB machines could handle around ten connections, which was far too expensive. We worked with Google's infrastructure team to profile and reduce the footprint per connection.

We also ran into port exhaustion. The sync layer needed its own port for each instance, but developers were already using ports for their own apps and dev servers. We forked y-websocket and switched to Unix domain sockets, which don't consume ports at all. Clean fix.

The Experience

We built a collaboration panel in the sidebar showing who's in the workspace, what file they're in, with the ability to click a name and jump to their cursor. Each collaborator gets a colored cursor with their name above it so you can see where everyone is editing. It's the detail that makes collaboration feel real rather than abstract.

Our distributed team was a real advantage for testing. Engineers connecting from different countries, on different devices, under different network conditions. We'd get the whole team into one workspace and stress test concurrent editing. These sessions surfaced the kind of edge cases automated tests never catch. We weren't simulating real-world conditions, we were living them.

What We Shipped

It required convincing Google to fork a major open-source project, collaborating with the creator of Yjs, working around real infrastructure constraints, and testing relentlessly across devices and geographies. The kind of project we live for.

Metadata

Sector

Scope