End-to-end encrypted real-time collaboration SDK.

Self-hosted in one Docker command.

Add Google Docs-style multi-user editing, presence, and chat to any web app — where your server mathematically cannot read plaintext. Built on WebRTC, Yjs, and AES-256-GCM via the browser's native Web Crypto API.

MIT client · Apache 2.0 server · Self-hosted in one Docker command

Why ZeroSync

Zero-knowledge by architecture, not by promise.

Zero-knowledge server

Room keys live only in the browser. The server sees hashed identifiers and opaque ciphertext — never plaintext data or encryption keys.

See the architecture
  • Architecture supports regulated workflows

    HIPAA technical safeguards, attorney-client privilege, GDPR data-minimization by design. Not certified — architecture enables your own compliance program.

  • Self-hosted

    Run on your own Hetzner / AWS / bare metal via one Docker image. No vendor-cloud dependency. Server is Apache 2.0 — fully open-source, no license fees for self-hosting.

  • Open-source client, auditable crypto

    MIT-licensed client SDK. Web Crypto API only — no third-party crypto libraries. Property-based tests via fast-check. SLSA provenance on every release.

  • Real React hooks

    Companion package @tovsa7/zerosync-react — useYText, usePresence, useMyPresence, useConnectionStatus. Works with Tiptap, CodeMirror, Quill via standard Yjs bindings.

Use cases

Products where two or more humans collaborate on sensitive content — and "your server cannot read it" is itself a feature.

Legal tech

Privileged attorney-client work, live document redlines, e-signing ceremonies with witnesses.

Attorney-client privilege

Like Notion for law firms — privilege guaranteed by architecture, not policy.

Mental health / therapy

Therapist-client sessions with notes, homework, and chat that the platform itself cannot see.

HIPAA §164.312

Like SimplePractice, but the vendor cannot read a single session.

Finance / fintech

Token deal rooms, M&A data rooms, OTC trading desk coordination, private equity deal flow.

Data-room grade

Like a VDR, but self-hosted and zero-knowledge end to end.

Enterprise R&D

Cross-team collaboration on IP, patents, regulatory filings, and trade secrets.

Trade-secret protection

Like Confluence, but for material that must not leave your premises.

Regulated SaaS with EU customers

A DPA-grade architecture you can point at during procurement and security reviews.

GDPR Art. 28 / 32

Like Liveblocks, but EU procurement-ready out of the box.

Quick start

Spin up your own signaling server, then integrate the SDK. 30 lines total.

Step 1 — Self-host the signaling server
docker run -p 8080:8080 ghcr.io/tovsa7/zerosync-server:latest

Production setup (TLS via Caddy, license, Docker Compose): SELF-HOSTED.md

Step 2 — Pick your client stack
npm install @tovsa7/zerosync-react @tovsa7/zerosync-client react yjs
import { ZeroSyncProvider, useYText, useConnectionStatus } from '@tovsa7/zerosync-react'
import { deriveRoomKey } from '@tovsa7/zerosync-client'

function App({ roomKey }: { roomKey: CryptoKey }) {
  return (
    <ZeroSyncProvider
      serverUrl="wss://sync.example.com/ws"
      roomId="my-room"
      roomKey={roomKey}
      peerId={crypto.randomUUID()}
      nonce={btoa(String.fromCharCode(...crypto.getRandomValues(new Uint8Array(16))))}
      hmac=""
      iceServers={[{ urls: 'stun:stun.l.google.com:19302' }]}
    >
      <Editor />
    </ZeroSyncProvider>
  )
}

function Editor() {
  const status = useConnectionStatus()
  const text   = useYText('editor')
  if (status !== 'connected') return <p>Status: {status}</p>
  return (
    <textarea
      value={text?.toString() ?? ''}
      onChange={(e) => {
        text?.delete(0, text.length)
        text?.insert(0, e.target.value)
      }}
    />
  )
}
npm install @tovsa7/zerosync-client yjs
import { Room, deriveRoomKey } from '@tovsa7/zerosync-client'

// Room key is derived client-side and never transmitted.
const secret  = crypto.getRandomValues(new Uint8Array(32))
const roomKey = await deriveRoomKey(secret, 'my-room-id')

const room = await Room.join({
  serverUrl:  'wss://your-server/ws',
  roomId:     'my-room-id',
  roomKey,
  peerId:     crypto.randomUUID(),
  nonce:      btoa(String.fromCharCode(...crypto.getRandomValues(new Uint8Array(16)))),
  hmac:       '',
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
})

const text = room.getDoc().getText('editor')
text.observe(() => console.log(text.toString()))

room.updatePresence({ name: 'Alice' })
room.leave()

See the React hooks package for useYMap, useYArray, usePresence, and Tiptap / CodeMirror integration examples.

How it works

AES-256-GCM encryption applied client-side before any data leaves the browser.

ZeroSync architecture Browsers connect directly via WebRTC. The server exchanges signaling info (ICE candidates, SDP) between peers — user data never flows through it. WebRTC P2P — preferred data flows directly between browsers, end-to-end encrypted Browser A holds room key Browser B holds room key ciphertext signaling only ZeroSync Server ICE · SDP · hashed peer IDs no user data ever reaches it

Illustrative: your users read their content; the server handles only signaling metadata. Don't trust the picture — verify the architecture yourself below.

What your users see
# Sprint Planning — Q2
- Launch target: May 15
- Design partners: 100
- Pricing model: per-bracket
- Risk: WebRTC NAT traversal
- Next review: Friday
What the server sees
peer_id: sha256(9c2d7e84…)
room_id: sha256(4a8b3f91…)
ice:     udp 192.0.2.5:54321
sdp:     m=application DTLS
event:   peers.connected
session: 1745420100
Verify for yourself — don't take our word
Open the live demo
Real multi-user session — inspect the actual WebSocket traffic via the DevTools Network tab
Or inspect the code and docs:
  • Client SDK source (MIT) — where AES-256-GCM is applied before any byte leaves the browser
  • SECURITY.md — formal threat model, cryptographic assumptions, disclosure process
  • Standard Web Crypto API — browser-native, no custom crypto libraries to audit

Signaling server source is Apache 2.0 — fully open-source, auditable, fork-friendly. Third-party security audit on the roadmap.

  • P2P by default — Peers connect directly via WebRTC DataChannel. Data never touches the server.
  • Signaling-only server — Exchanges ICE candidates / SDP between peers so they can find each other — then gets out of the way.
  • Zero-knowledge server — Holds no keys, logs only SHA-256-hashed room / peer IDs.
  • Mutual peer auth — AES-GCM challenge-response on DataChannel open — proves key possession without transmission.
  • Encrypted blob fallback — When direct WebRTC fails, the signaling server forwards opaque ciphertext between connected peers in-memory — server still cannot decrypt.

Full threat model + disclosure process: SECURITY.md

How it compares

Versus the most common alternatives for real-time collaboration.

ZeroSync Liveblocks Yjs + y-websocket Jazz.tools
End-to-end encrypted
AES-256-GCM
opt-in
Zero-knowledge server
Self-hosted
cloud only
Open-source
MIT + Apache 2.0
MIT
MPL-2.0
React hooks
community

Frequently asked questions

Questions I get from security-conscious CTOs during evaluation.

Why E2E when I already have TLS?
TLS protects data in transit between client and server. End-to-end encryption protects data across the server — even if your infrastructure is compromised, the server itself sees only ciphertext. For regulated workflows, this moves compliance from vendor trust to architectural guarantee.
Is the cryptography audited?
Not yet by a third party — independent audit is on the roadmap. Today: the client SDK uses only standard Web Crypto API primitives (AES-256-GCM, SHA-256, ECDH) — no custom crypto to audit. Source is MIT and fully open; the test suite includes property-based tests via fast-check.
What's the latency overhead vs plain Yjs?
In P2P mode: one AES-256-GCM encrypt and one decrypt per update. On modern hardware this measures at roughly 0.1 ms per update for typical collaborative document sizes — negligible next to the network round-trip Yjs already does over WebRTC DataChannel.
HIPAA / GDPR — what's actually included?
Architecture supports both. HIPAA §164.312: encryption in transit and at rest (client-side). GDPR Art. 25 / 32: data minimization by design — server holds no personal data, only hashed room / peer IDs. ZeroSync itself is not certified — COMPLIANCE.md maps each technical safeguard to the code path that implements it so your own compliance program can reference it directly.
Can I get a signed BAA or DPA?
BAA-ready architecture documentation is available on request — designed for your legal team to incorporate into your own customer agreements. A DPA template is also available. Direct signed BAA / DPA arrangements are part of design-partner and future Enterprise engagements.
Mobile support?
React Native and native iOS / Android SDKs are on the roadmap. Today the client works in mobile browsers (Safari on iOS, Chrome on Android) and inside any WebView via Capacitor or Cordova — hybrid apps work out of the box.
Is ZeroSync production-ready? What's the bus factor?
Client SDK is published to npm with SLSA provenance on every release and a comprehensive test suite (including property-based tests). Signaling server runs via Docker on any Linux host. Independent third-party audit is the remaining milestone. Bus factor: solo maintainer today — but the MIT client and Apache 2.0 server mean you can fork, patch, and self-support if needed. No vendor lock-in.

Didn't find your question? Email me directly.

Running ZeroSync in production?

I'm onboarding a small group of design partners — companies shipping HIPAA / GDPR / privilege-sensitive collaboration. In exchange for deep feedback, you get direct influence on the product and pricing that stays friendly as you grow.

  • Direct founder access

    Email goes straight to me — no support tiers, no tickets. You talk to the person who writes the code.

  • Priority on the roadmap

    Your use case shapes the next quarter. Needed features jump the queue — you see what ships because of you.

  • Grandfathered pricing

    Today's rate stays locked in as standard prices rise. No surprise hikes when you scale your deployment.

  • Hands-on deployment

    Pair-programming for self-hosted setup. TOM compliance template. We debug your NAT or WebRTC issues together.

Ideal fit
  • Regulated industry (legal · therapy · fintech · enterprise R&D · EU regulated SaaS)
  • Comfortable with self-hosted deploy (Docker / Linux)
  • Launching or actively building E2E-sensitive collaboration
  • Willing to share real feedback (optional public case study)
Email the author directly

contact.zerosync@proton.me