Inspiration
Modern development is increasingly collaborative, but the tools developers use are often fragmented. Teams may need one tool for documentation, another for code execution, and another for communication. I wanted to bring these workflows into one shared environment where developers can work together in real time. The idea behind Nexus was to build a collaborative engineering workspace where multiple users can edit, experiment, and execute code together without constantly switching between different tools.
What it does
Nexus is a real-time collaborative engineering workspace that combines shared document editing with live code execution. Users can create isolated rooms and work together on shared content in real time. The platform supports: Multiplayer rich-text editing Live code execution for Python, JavaScript, and Shell Isolated collaborative rooms Real-time synchronization between users Network failure recovery Persistent project data The goal is to make collaborative development feel closer to working together at the same desk, even when users are working remotely.
How I built it
Nexus uses a modern distributed web architecture. I built the frontend with React and Vite, while the backend provides the application APIs. I use Ably for real-time communication and synchronization between connected users. Project and room data are stored using PostgreSQL through Neon. For code execution, I use isolated E2B sandboxes rather than running untrusted code directly on the application server. The application is deployed using Vercel and Render, with GitHub-based CI/CD supporting the development workflow. Cloudflare R2 is used for object storage, while Sentry provides application monitoring and error tracking. I designed the architecture around independent services so that collaboration, persistence, execution, and monitoring can evolve without tightly coupling the entire application.
Challenges I ran into
One of the biggest challenges was maintaining reliable real-time collaboration across multiple users. Network interruptions can cause clients to temporarily lose synchronization, so I had to think beyond simply sending updates over a WebSocket connection. Recovery and synchronization behavior became an important part of the system. Another challenge was executing user code safely. Running arbitrary Python, JavaScript, or shell commands directly on the backend would create serious security and isolation problems. I therefore moved execution into isolated E2B sandboxes. Deployment also introduced challenges around distributed services, CORS configuration, environment variables, persistent storage, and communication between independently hosted frontend and backend components.
Accomplishments that I'm proud of
I am proud of turning Nexus from a collection of individual features into a working collaborative engineering environment. The most important accomplishments were: Building real-time multiplayer editing Implementing isolated rooms for collaborative sessions Adding live execution for multiple programming languages Designing a recovery path for network failures Separating code execution from the main application infrastructure Connecting multiple cloud services into one deployable system Building the project as an end-to-end product rather than just a prototype of one isolated feature Nexus challenged me to think about reliability and system architecture alongside the user experience.
What I learned
I learned that real-time applications are fundamentally different from traditional request-response web applications. It is not enough to make the happy path work. The system also needs to account for disconnected users, synchronization, concurrent changes, failed requests, stale state, and recovery. I also learned that architecture decisions become much more important when different parts of a product are distributed across multiple services. Clear boundaries between the frontend, backend, real-time layer, database, execution environment, storage, and monitoring made the system easier to reason about and debug. Most importantly, I learned that building a complete product requires much more than implementing individual features. Reliability, deployment, security, and failure handling are part of the product itself.
What's next for Nexus
The next version of Nexus will focus on making collaborative development more powerful and intelligent. Potential improvements include: AI-assisted coding and debugging Collaborative terminal sessions GitHub repository integration Persistent project workspaces More programming languages and execution environments Better conflict resolution for simultaneous edits Richer collaboration and presence indicators Project-level permissions and access control Improved observability and performance monitoring My long-term goal is to evolve Nexus from a collaborative editor into a complete cloud-based engineering workspace where teams can write, run, debug, and share software together in one place.
Built With
- ably
- cloudflare-r2
- docker
- e2b
- fastapi
- github
- neon
- postgresql
- python
- react.js
- render
- sentry
- vercel
- vite
Log in or sign up for Devpost to join the conversation.