Syntasa Notebooks support standard JupyterLab Real-Time Collaboration (RTC). RTC is on by default for every notebook in every workspace; there is nothing to configure. When two or more workspace members open the same notebook, their edits, cursors, and cell outputs appear live in each participant's view.
What you get is what JupyterLab RTC provides:
- Simultaneous editing — type in the same cell or different cells, and everyone's edits merge automatically.
- Presence indicators — colored avatars in the notebook header show who else is currently in the document.
- Live cursors — labeled with each collaborator's name, showing where their caret is.
- Shared cell output — when one user runs a cell, every collaborator sees the output appear in their view at the same time.
One notebook, one kernel — what you should know
When multiple users are on the same notebook, they share a single kernel. The kernel is per-notebook, not per-user — and that has two practical consequences before you pair on something with a colleague. The first is a coordination concern; the second is a security concern that's easy to overlook.
Shared kernel state
Variables, imports, and execution order are shared. If Alice runs `x = 1` and a moment later Bob runs `x = 2`, Bob's value wins — for both of them. Treat the kernel like a shared whiteboard: anything one collaborator changes is visible to the others, and the last write wins. Coordinate verbally if you both plan to run cells at the same time.
Security — one user's permissions apply to everyone's cell runs
Whoever launches the kernel first is the user it runs as. From that point on, every cell — regardless of who clicks Run — executes with that user's data access permissions. If Alice starts the kernel and Bob runs a cell that reads from S3, the read uses what Alice is allowed to read, not what Bob is allowed to read.
This is worth flagging because it can let one user effectively read data through another user's identity. To reset identity to a different user, restart the kernel and have that user launch it. (See Data Authorization and Session Policy for what determines a user's data access. Note that on a notebook attached to a runtime — see Runtime Attachment in Notebook Workspaces — identity is per-notebook in the same way; shared compute cluster is not the same as shared identity.)
Where RTC works
RTC is active in every workspace and applies to both notebook cards and JupyterLab notebooks. In practice, it is only useful when more than one user has the same notebook open. On your personal workspace, or on a group workspace where you are the only one currently editing, RTC runs in the background, but you will not see avatars or live cursors until someone else joins.
Good uses
RTC is well suited to:
- Pair programming on a notebook — one person types, the other comments and reviews live.
- Notebook walkthroughs — scroll along with a colleague while you narrate the analysis.
- Joint debugging — both users run cells, inspect variables, and edit in place without screen-sharing.
- Live code review — leaving inline edits while the author is still working.
Limits and edge cases
A few things worth knowing for collaboration in practice:
- Connection drops — if your network drops mid-session, JupyterLab's CRDT model keeps your local edits and merges them in when you reconnect. You won't lose work as long as you don't close the tab before reconnecting.
- Autosave — autosave continues as long as at least one collaborator is connected. The notebook file is workspace-stored, not session-stored; closing the last tab leaves the file in its last saved state.
- Concurrent users — there is no documented hard cap on how many users can edit a notebook at the same time. RTC is designed for small-team collaboration; if you find yourself with more than five or six people on a single notebook, consider splitting the work.