Cloudflare has introduced a Whiteboard plugin for RealtimeKit, allowing developers to embed a collaborative drawing surface directly into live audio/video meetings. The change is delivered as a hosted iframe that authenticates participants with a token passed in the URL fragment, removing the need to provision, scale, or secure a custom whiteboard backend.
Integrating the Whiteboard Plugin
The plugin is added using the same plugins API that RealtimeKit already supports. An iframe is created, sized to fill its container, and pointed at the hosted URL https://whiteboard-v2.plugins.realtime.cloudflare.com/ with the participant’s auth token appended after a #. The fragment is URL‑encoded to avoid accidental transmission in HTTP requests.
const WHITEBOARD_URL = "https://whiteboard-v2.plugins.realtime.cloudflare.com/";
function createWhiteboard(authToken) {
const iframe = document.createElement("iframe");
iframe.style.width = "100%";
iframe.style.height = "100%";
iframe.style.border = "none";
iframe.allow = "clipboard-read; clipboard-write";
iframe.referrerPolicy = "no-referrer";
iframe.src = `${WHITEBOARD_URL}#authToken=${encodeURIComponent(authToken)}`;
return iframe;
}
const whiteboardElement = createWhiteboard("");
When initializing the RealtimeKit SDK, the returned whiteboardElement is supplied as the plugin’s component. Cloudflare’s documentation provides registration snippets for web, Android, iOS, and React Native, so the same pattern works across client platforms.
Architectural Impact
Using the hosted plugin shifts the whiteboard’s real‑time synchronization, persistence, and access‑control logic from the application stack to Cloudflare’s service. Engineers no longer need to provision a separate server that broadcasts drawing strokes, stores board state, or enforces opening permissions. The meeting application can focus on media handling and core business logic while the plugin handles collaborative drawing.
Because the plugin runs in an isolated iframe, it does not inherit the parent page’s address or cookies. The referrerPolicy="no-referrer" further limits information leakage. The only credential crossing the boundary is the auth token in the fragment, which is never sent to the origin server but is available to the iframe’s JavaScript.
Operational and Security Considerations
- Token handling: The auth token must be scoped appropriately for whiteboard access, as it is exposed to the client side. Developers should ensure the token’s lifetime and permissions match the intended meeting duration.
- Isolation: The iframe sandbox isolates the whiteboard code from the host page, reducing the attack surface of the meeting UI. However, any JavaScript running inside the iframe can still interact with the clipboard because of the
allowattribute. - Operational load: Offloading drawing synchronization to Cloudflare eliminates the need to monitor latency, scaling, or storage for a custom whiteboard service. Teams should still monitor the overall meeting latency to ensure the added iframe does not introduce perceptible delays.
- Compliance and data residency: Since the whiteboard data is stored and processed by Cloudflare, organizations must verify that the service’s data handling aligns with their regulatory requirements.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopting the Whiteboard plugin lets engineers add a fully functional collaborative canvas to RealtimeKit meetings with a few lines of code, while delegating real‑time state management to Cloudflare. The primary actions are to generate a meeting‑scoped auth token, embed the iframe as shown, and register the plugin in the SDK. Teams should audit token scopes, confirm compliance posture, and monitor meeting performance, but they can avoid building, scaling, and securing a custom whiteboard service altogether.
