DEV Community: Zishan Ghaniwala

Build ESP32 Video & Audio Calling With VideoSDK

Zishan Ghaniwala — Wed, 05 Aug 2026 12:10:09 +0000

ESP32 video calling runs two-way WebRTC audio and video directly on an ESP32-S3 microcontroller. The VideoSDK IoT SDK ships as an ESP-IDF component that joins your board to the same VideoSDK room a browser joins, with no signaling server of your own. Set a token, flash the firmware, and join from the web.

Until recently, ESP32 video calling meant building, hosting, and maintaining your own signaling and media backend before a single frame moved. The VideoSDK IoT SDK cuts out that infrastructure. It provides a native ESP-IDF component that hooks an ESP32-S3 directly into a WebRTC room, the exact same room a browser or mobile app joins.

Your board streams camera and microphone input into the room, and on boards with a screen and speaker, it draws remote video on the LCD and plays remote audio back. By the end of this guide you will have an ESP32-S3 holding a live video and audio call with a web application, without managing a custom media server.

What Is ESP32 Video Calling?

ESP32 video calling is defined as real-time, two-way audio and video streaming that originates and terminates on an ESP32 microcontroller rather than on a phone or laptop. It works by capturing frames from an onboard camera and samples from a microphone, encoding them on-device, and publishing them over WebRTC to every other participant in a room.

The VideoSDK IoT SDK provides this capability as a native ESP-IDF component for the ESP32-S3 family, published on Espressif's official component registry under the MIT license. It handles the room connection logic, WebRTC encryption (DTLS and SRTP), and media stream lifecycle, so your firmware manages calls through a handful of function calls.

The board is a first-class participant, not a camera feeding a gateway. It appears in the participant list, it can be muted, and it shares the same room ID your React or JavaScript client already uses.

What You Need Before You Start

The board you choose decides whether your device can only send media or handle full two-way playback, so pick it before writing any code.

Board	Send (Mic & Camera)	Receive (Speaker & LCD)	Hardware Detail
XIAO ESP32-S3 (Sense)	Yes	No	Includes camera & mic, but lacks onboard display & speaker
ESP32-S3-Korvo-2 v3.0	Yes	Yes	Includes camera, mic, LCD, and speaker for full two-way A/V

On the XIAO board, calling startSubscribeVideo() or startSubscribeAudio() returns DEVICE_NOT_SUPPORTED. That is expected behavior for missing hardware, not a bug. Pick the Korvo-2 if you want the board itself to display and play back the far end.

Prerequisites:

ESP-IDF 5.4.4 or newer with the environment exported. The component declares 5.4.4 as its minimum.
Python 3.11+, required by the ESP-IDF build tools.
8 MB of flash and PSRAM on the board. The application image does not fit in 4 MB.
A VideoSDK account for your API key, secret, and room tokens.

How ESP32 Video Calling Works Under the Hood

Running WebRTC on an ESP32 is a memory problem before it is a CPU problem. The WebRTC stack, the DTLS handshake state, video frames, and audio buffers all compete for internal SRAM, which is why supported boards carry external PSRAM and why the SDK depends on it for stable operation.

WebRTC security runs end to end. The device performs a DTLS handshake and transmits media over encrypted SRTP streams, the same transport a browser uses.

Receiving is where the SDK saves the most work. Publishing is comparatively simple, but subscribing means decoding incoming video and audio, absorbing network jitter, drawing to an LCD, and driving speaker hardware in real time inside tight SRAM limits. On the ESP32-S3-Korvo-2, the publish and subscribe calls for both audio and video run concurrently.

Wi-Fi quality shows up directly in frame rate and audio clarity. Keep the antenna clear, connect to 2.4 GHz, and test on the network the hardware will actually run on in production.

When Not to Use the IoT SDK

Espressif ships its own esp-webrtc-solution, and it wins in a specific case: you already run your own signaling server and media infrastructure, or you need to peer directly with a device that is not in a VideoSDK room. The IoT SDK assumes VideoSDK rooms and VideoSDK tokens, which is exactly the assumption that removes the backend work. If you want the board on an existing SFU you operate yourself, the managed path is the wrong trade.

Step 1: Set Up the ESP-IDF Environment

Install Espressif's ESP-IDF toolchain. The commands below cover macOS; see the official ESP-IDF getting started guide for Linux and Windows.

Install build dependencies:

brew install cmake ninja dfu-util ccache git wget flex bison gperf
brew install openssl libffi

Clone ESP-IDF at v5.4.4 or newer and run the installer. Older branches will not build this component:

mkdir -p ~/esp && cd ~/esp
git clone --recursive -b v5.4.4 https://github.com/espressif/esp-idf.git
cd esp-idf
./install.sh esp32s3

Export the environment variables into your shell session:

source ~/esp/esp-idf/export.sh

Step 2: Generate Your VideoSDK Token

VideoSDK uses token-based authentication. For building and testing you do not need a signing server: the dashboard generates a token for you in about a minute.

Open the VideoSDK dashboard and sign up or log in.
Copy your API key and secret.
Generate a temporary token and save it.

You also need a room (meeting) ID, and the order here matters. The React client in Step 7 mints one for you when you click New Meeting, and that is the ID you flash onto the board.

Firmware is harder to rotate than a web bundle, so a long-lived token flashed into a device is a liability. The VideoSDK authentication and token guide covers token lifetimes and permission scopes.

Step 3: Create the Project From the Example

Fetch the project structure from the official video_call example, then extend it to carry audio as well.

idf.py create-project-from-example "videosdk/iot-sdk=0.3.1:video_call"

The stock video_call example captures camera input and draws incoming video on supported hardware such as the ESP32-S3-Korvo-2, running with videoCodec = VIDEO_CODEC_JPEG. Step 5 adds the audio streams.

Step 4: Configure the Build

Set the target chip to esp32s3 and open menuconfig to enter credentials and Wi-Fi settings.

idf.py set-target esp32s3
idf.py menuconfig

In the menuconfig interface:

Microcontroller board: Select ESP32-S3-Korvo-2 or ESP32-S3-XIAO (XIAO is the default).
VideoSDK Configuration: Paste the token and the meeting / room ID. If you are following the repo flow, get the room ID from the React client in Step 7 first, then come back here.
Example Connection Configuration: Enter your 2.4 GHz Wi-Fi SSID and password.
Flash and Partitions: Set flash size to 8 MB and keep the partition table the example ships.

Keep sdkconfig out of public repositories. It holds your Wi-Fi credentials and your VideoSDK token in plain text.

Step 5: Understand the Code

The firmware flow connects to Wi-Fi, fills an init_config_t structure, calls init(), and starts the media streams. The example ships as a video-only call, so its app_main sets only the video codec and starts only the two video streams:

#include "videosdk.h"
#include "sdkconfig.h"

void app_main(void)
{
    // Initialize NVS, network interfaces, event loops, and Wi-Fi...

    init_config_t cfg = {
        .meetingID     = CONFIG_VIDEOSDK_MEETING_ID,
        .token         = CONFIG_VIDEOSDK_TOKEN,
        .displayName   = "ESP32S3-AV-Device",
        .participantId = "",
        .audioCodec    = AUDIO_CODEC_PCMA,
        .videoCodec    = VIDEO_CODEC_JPEG, // Video only, as shipped
    };

    if (init(&cfg) != RESULT_OK) {
        return;
    }

    startPublishVideo();     // Stream the onboard camera
    startSubscribeVideo();   // Draw to the LCD (Korvo-2 only)

    while (1) {
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

To turn this into a full audio and video call, add audio yourself. It is just one change. Start the two audio streams alongside the video ones:

    init_config_t cfg = {
        .meetingID     = CONFIG_VIDEOSDK_MEETING_ID,
        .token         = CONFIG_VIDEOSDK_TOKEN,
        .displayName   = "ESP32S3-AV-Device",
        .participantId = "",
        .audioCodec    = AUDIO_CODEC_PCMA,
        .videoCodec    = VIDEO_CODEC_JPEG,
    };

    // ...after init() returns RESULT_OK:

    startPublishAudio();     // Add: stream the onboard microphone
    startPublishVideo();
    startSubscribeAudio();   // Add: play to the speaker (Korvo-2 only)
    startSubscribeVideo();

That gives you all four streams for full A/V. Every SDK function returns a result_t status code, where RESULT_OK equals 0. On send-only hardware like the XIAO, startSubscribeAudio() returns DEVICE_NOT_SUPPORTED, which is expected. Check return codes in production firmware rather than assuming the stream came up.

Step 6: Build, Flash, and Verify the Join

Compile the firmware, flash the board, and open the serial monitor:

idf.py build
idf.py -p <PORT> flash monitor

A successful boot and room join produces this sequence. Values are redacted; yours will show your own network details:

I (20151) wifi:connected with <YOUR_SSID>, aid = 7, channel 7, BW20, bssid = <REDACTED>
I (20152) wifi:security: WPA2-PSK, phy: bgn, rssi: -49
I (21194) esp_netif_handlers: example_netif_sta ip: <LOCAL_IP>, mask: 255.255.255.0
I (21205) example_common: Connected to example_netif_sta
I (21211) IOT-SDK-AUDIO: Device ID: e-ccba970e9220
I (21215) videosdk: participantId (peerId): e-ccba970e9220
I (21256) IOT-SDK-AUDIO: init: 0
I (23312) protoo: decrypted 4 ICE server(s)
I (23313) protoo: connecting websocket to in1.rm.videosdk.live
I (23562) esp-x509-crt-bundle: Certificate validated
I (24094) protoo: websocket connected
I (24113) protoo: protoo client ready (peerId=e-ccba970e9220)
I (26178) videosdk: using 1 STUN server(s) for ICE
I (29220) peer: Created inbound SRTP session
I (29220) peer: Created outbound SRTP session
I (29474) videosdk: DataChannel transport up (ICE+DTLS)
I (29534) videosdk: SCTP data channel connected after 60 ms
I (29807) videosdk: audio RTP producer id=4bb13f4c-b453-4445-8924-ab09215dfd1b
I (29807) videosdk: bringing up mic
Result:0

The two lines that matter are Created outbound SRTP session and the RTP producer id. Together they confirm the DTLS handshake completed and the board is publishing. A few example_connect: Wi-Fi disconnected, trying to reconnect... lines before the association are normal on a busy 2.4 GHz channel.

Step 7: Join the Same Room From a React App

Nothing about the web side is ESP32-specific, which is the point: the board is just another participant. VideoSDK publishes a companion repository, videosdk-live/videosdk-rtc-iot-sdk-example, that carries the firmware under IoT/ and two ready-to-run browser clients under web/js (vanilla JavaScript) and web/react. Both talk to the same room, so pick whichever matches your stack. This guide uses the React client.

Clone the repository and install the client:

git clone https://github.com/videosdk-live/videosdk-rtc-iot-sdk-example.git
cd videosdk-rtc-iot-sdk-example/web/react
npm install

Create the environment file and drop in the token from Step 2:

cp .env.example .env

REACT_APP_VIDEOSDK_TOKEN=<your token>

The token must carry the allow_join permission. Create React App inlines .env at build time, so restart the dev server after any change to it, otherwise you will keep authenticating with the old value and blame the board.

npm start

The app comes up on http://localhost:3000. Browsers only grant camera and microphone access on a secure context, and localhost counts as one, so no TLS setup is needed for local development.

Click New Meeting. The app creates the room and shows you the meeting ID. That ID goes into idf.py menuconfig under VideoSDK Configuration > Meeting / room ID back in Step 4. Reflash the board, and once it joins, the ESP32-S3 appears as its own video tile under the displayName you set in Step 5.

What the React Client Adds for IoT Participants

MeetingView.js is an ordinary VideoSDK meeting view built on the same hooks as the React SDK quickstart, with no device-specific logic in it. Everything that knows about hardware lives in src/iot, which is a useful separation to copy if you are bolting device support onto an app you already have.

Export	Purpose
`<IOTBridge />`	The one piece that has to be mounted for device support to work
`<IOTVideoPlayer participantId={id} />`	Renders a device participant's video and audio
`useIOTMessages()`	Hook for receiving messages sent from the board's data channel
`sendIOTMessage()`	Sends a message to the device, 15 KiB maximum per message
`isIOTDevice()`	Tells a device participant apart from a browser participant

useIOTMessages() and sendIOTMessage() are the browser half of the setDataMessageHandler() and sendMessage() calls from Step 5. That pairing is what turns a call into a control channel: stream the camera for the human, and send a JSON command over the same connection to move a servo or read a sensor, with no second transport to operate.

On a Korvo-2, this is also where the loop closes. Your browser webcam draws to the board's LCD and your voice plays through its speaker, while its camera and microphone come back to you in the tile.

Common Errors

DEVICE_NOT_SUPPORTED on a subscribe call: Expected on boards without LCD or speaker output, such as the XIAO. Use a Korvo-2 for playback on the device.
INIT_NOT_CALLED: A start* function ran before init() returned RESULT_OK. Check the init() return code before starting streams.
Build fails or the image will not fit: Confirm ESP-IDF is on v5.4 or newer, flash size is set to 8 MB, and PSRAM is enabled for the selected board.
Wi-Fi connects but the room join fails: Verify the room ID formatting and confirm the token carries allow_join permission and has not expired.
Board joins but no media arrives: Confirm the browser used the same room ID, and check the serial log for Created outbound SRTP session. Its absence points at the DTLS handshake, usually a blocked UDP path on the network.

ESP32 Video Calling Glossary

Room: A VideoSDK meeting space identified by a unique room ID that participants join to share media streams. The ESP32-S3 and your browser join the same room ID, which is what makes them see each other.

Participant: Any client connected to a room with its own audio and video streams. The IoT SDK registers the board as a participant with a displayName and a participantId.

Meeting Token: A JWT authorizing a participant to join a room, generated from the VideoSDK dashboard for testing or minted server-side for production.

SRTP: Secure Real-time Transport Protocol, the encrypted media transport WebRTC uses. The IoT SDK negotiates SRTP keys through a DTLS handshake, so board media is encrypted on the wire exactly as browser media is.

ESP-IDF component: A reusable package in Espressif's IoT Development Framework, resolvable from the component registry. The VideoSDK IoT SDK ships as one, so idf.py pulls it in as a dependency rather than you vendoring source.

Frequently Asked Questions

Can an ESP32 join real-time calls?

Yes. An ESP32-S3 running the VideoSDK IoT SDK connects directly to a VideoSDK room over WebRTC and streams video and audio with browsers, phones, and other devices in real time. The board is a full participant in the room, not a feed proxied through a gateway.

Which ESP32 boards are supported?

The IoT SDK targets the ESP32-S3 family. The XIAO ESP32-S3 (Sense) handles camera and microphone transmission, while the ESP32-S3-Korvo-2 v3.0 supports full two-way A/V with its integrated LCD and speaker driver.

Does the IoT SDK use standard WebRTC?

Yes. The VideoSDK IoT SDK uses standard WebRTC protocols end to end, establishing encrypted SRTP media channels through DTLS handshakes.

Can two ESP32 devices call each other?

Yes. Two-way interactive calling works when both ESP32 devices have media output hardware, such as two ESP32-S3-Korvo-2 boards equipped with speakers and displays. If a send-only board like the XIAO ESP32-S3 is used, it can publish its streams into the room but cannot receive or play back incoming media.

Why does the ESP32 send JPEG instead of H.264?

JPEG compresses each frame independently, so it needs no reference frames and far less RAM than a video codec. On the supported boards the camera sensor emits JPEG directly, which keeps the ESP32-S3 out of the encoding path entirely.

Is the IoT SDK free to use?

The IoT SDK component is open source under the MIT license. VideoSDK provides a free monthly credit tier covering room connectivity and media routing.

Conclusion

ESP32 video calling stops being an infrastructure project once the board can join a managed room directly. The IoT SDK reduces it to a token, a room ID, and four function calls, and the browser side is a repository you clone. The remaining engineering is where it should be: your product's camera placement, power budget, and reconnect behavior.

The example repo: videosdk-live/videosdk-rtc-iot-sdk-example, firmware plus React and JavaScript clients
Free API keys: VideoSDK dashboard
The component: videosdk/iot-sdk on the Espressif registry, MIT licensed

Flash it once and watching a microcontroller appear in a browser participant list is genuinely strange in a good way. What are you building with VideoSDK? Drop a comment, I would love to hear what kind of embedded calling use case you are working on.

How to Build an Open-Source Zoom Clone with Claude Code + VideoSDK

Zishan Ghaniwala — Mon, 27 Jul 2026 13:27:53 +0000

To build a Google Meet clone, clone the MIT-licensed videosdk-community/google-meet-clone repo, run npm install and npm run dev, then add a free VIDEOSDK_API_KEY and VIDEOSDK_SECRET to .env for real WebRTC video over VideoSDK's SFU. Claude Code handles the customizing.

That is the whole path, and it takes about ten minutes. You start from a complete React video call app: a pixel-accurate Google Meet UI sitting on top of VideoSDK's real WebRTC infrastructure. You clone it, you run it, you make it yours. No real-time video experience needed, no signaling server to write, no TURN infrastructure to rent.

Key Takeaways

The repo is free and MIT-licensed. Clone videosdk-community/google-meet-clone, run npm install, and you have the full codebase.
Preview the UI with zero keys. A built-in fake mode renders the interface locally so you can click around before signing up for anything.
Two keys unlock real video. A free VIDEOSDK_API_KEY and VIDEOSDK_SECRET turn it into genuine multi-participant meetings. The server mints tokens for you.
Claude Code does the customizing. Ask it to rebrand, add features, or change behavior in plain English.
One click to deploy. A Vercel button ships it to the internet with the two env vars pre-filled.

What is a Google Meet clone?

A Google Meet clone is defined as a self-hosted video conferencing app that reproduces Google Meet's interface and meeting mechanics on infrastructure you control. It works by pairing a Meet-styled front end with a WebRTC media backend that routes audio and video between participants.

The hard part was never the UI. It is the media layer: peer negotiation, an SFU to route streams so a five-person call does not melt a laptop, TURN relays for participants behind restrictive firewalls, and signed tokens so a guest cannot grant themselves host powers.

The videosdk-community/google-meet-clone repo hands you the UI and delegates that media layer to VideoSDK's SFU, which is why the whole thing fits in one afternoon instead of one quarter. Real-time transport follows the W3C WebRTC specification, so the browser side is standards-based rather than proprietary.

Most of the competing tutorials in this space stop before that line. The Strapi 5 and Next.js series and the popular WebRTC-plus-Socket.io courses have you hand-roll signaling with peer-to-peer connections, which works for two people and degrades badly past four. This guide starts from an SFU, so scaling is not a rewrite.

Features the repo ships with

The repo ships the feature set that actually matters in a meeting app, not a video-chat demo with two tiles.

Real-time HD video and audio over VideoSDK's SFU, so calls scale past two people.
A grid / gallery view with tiles that resize themselves as the room fills up.
A pre-join green room with a mirrored camera preview and device pickers.
Chat with saved history, floating emoji reactions, and raise hand, all synced to late joiners.
Screen sharing and cloud recording.
Host controls with a real waiting room: guests knock, and the host admits or removes them.

It looks like Google Meet because the UI is built from a Figma reference, down to the icons and fonts. It works like Google Meet because the media is real.

Prerequisites for building the clone

You need very little to start:

Node.js 18 or newer (20+ recommended). Check with node -v.
git, to clone the repo.
A free VideoSDK account for live video. You'll grab the keys in Step 3, so you can skip this until then.
Claude Code (optional, but it's the star of Step 4). It's Anthropic's terminal coding agent, documented at docs.claude.com.

That's it. No database, no backend to stand up, no accounts system to wire in.

Step 1 - Clone the Google Meet clone repo

Getting the code is two commands and one install, and the lockfile pins every dependency for you.

git clone https://github.com/videosdk-community/google-meet-clone
cd google-meet-clone
npm install

This project uses npm as its package manager, so npm install reads the committed lockfile and pulls everything down: React 19, TypeScript, Vite, and the @videosdk.live/react-sdk. Give it a minute.

While that runs, here's the shape of what you cloned. Feature components live under src/routes/ (the landing page, the green room, and the in-call screen). Every call into VideoSDK is hidden behind a single hook layer in src/meeting/, and the token-signing serverless functions sit in api/. You rarely need to touch the SDK directly, which is exactly why customizing this is pleasant. If you do want the raw surface, it is the same one documented in the VideoSDK React quickstart.

Step 2 - Preview the UI in fake mode

You don't need any keys to see the interface. The project ships a fake mode that renders the full UI against a local mock, no camera and no network required.

Start the dev server:

npm run dev

It serves the app on http://localhost:5173. Now open a meeting URL with the ?fake=ok switch appended:

http://localhost:5173/abc-defg-hij?fake=ok

You'll first land in the green room, then join into a fully rendered meeting: participant tiles, the control bar, chat, reactions, the works. It's perfect for exploring the layout, tweaking styles, and getting your bearings.

One honest caveat: fake mode is a UI preview, not a real call. It uses a built-in fake client with fabricated participants, so nothing goes over the network and no one else can join. It's a developer convenience that's compiled out of production builds entirely. For actual meetings with real people, you need keys, which is the next step.

Step 3 - Add real video with VideoSDK keys

Two environment variables turn the UI preview into genuine multi-participant meetings, and neither one ever reaches the browser.

Head to the VideoSDK dashboard and create a free account. You'll get an API key and a secret. [UPDATE: verify free tier limits - videosdk.live/pricing]

Copy the example env file and paste your credentials in:

cp .env.example .env

Open the new .env and fill in the two values:

VIDEOSDK_API_KEY=your_key
VIDEOSDK_SECRET=your_secret

Those are the only two variables that matter. Restart the dev server (npm run dev) and you're live. Click New meeting on the landing page and it creates a real VideoSDK room and makes you its host. Open the meeting link in a second browser or device to join as a guest.

Two things are worth knowing about how this stays safe. First, the secret never reaches the browser. It's read only by the functions in api/, and the project deliberately keeps it out of any VITE_-prefixed variable so it can't get bundled into the client.

Second, there's no manual token step. When a client joins, the server mints the right meeting token on the spot: a host token if the client holds a valid grant for that room, a guest token otherwise. You paste your key and secret once, and token signing is automatic from then on. The token format and its permission claims are described in the VideoSDK authentication docs.

Step 4 - Customize the clone with Claude Code

Claude Code turns customization into a conversation, because every VideoSDK call in this repo already sits behind one hook layer.

Instead of hunting through files, you describe what you want and let the agent make the change. Run claude in the project root and try prompts like these. (These are illustrative examples of what you'd ask, not magic incantations. Phrase them however feels natural.)

Rebrand the colors:

"The app uses design tokens generated from Figma. Change the primary accent color to a deep purple across the UI, and show me which files you touched."

Add a reaction:

"The reactions picker in the control bar has a set of emoji. Add a fire emoji to the list so participants can react with it, and make sure it floats up on the tiles like the others."

Tweak the meeting controls:

"In the in-call control bar, add a keyboard shortcut that toggles the People panel, and show it in the button's tooltip."

Understand before you change:

"Explain how a guest goes from clicking a meeting link to appearing in the host's waiting room. Trace the path through the code."

Point Claude Code at src/routes/ for anything visual and src/meeting/ for anything media-related, and it'll follow the existing patterns rather than reinventing them. Ask, review the diff, run the app, repeat. That loop is the whole workflow.

Step 5 - Deploy to Vercel

Deployment is one button because the repo ships nothing that needs configuring, only the two secrets.

When you're ready to share it, the fastest path is the one-click Vercel button in the repo's README. It clones the project into your own Vercel account and prompts you for the two environment variables (VIDEOSDK_API_KEY and VIDEOSDK_SECRET), with a link straight to your API keys.

Prefer to do it yourself? Build and deploy:

npm run build

Then deploy to any host that runs the api/ serverless functions. On Vercel it's zero-config: there's no vercel.json to write, the functions become endpoints automatically, and the single-page app is served statically. Set the same two env vars in your host's dashboard, and tokens get minted at request time. Nothing is baked into the client, and there's nothing to paste per meeting.

Tour of the running meeting app

Three surfaces make up the whole app: a landing page, a green room, and the call itself.

The landing page (/) is where you start a meeting or join by code. Click New meeting and it spins up a real room and hands you the host role.

Every meeting lives at /:meetingId, and that one route covers both stages. First you hit the green room: type your name, check yourself in the mirrored camera preview, pick your mic and camera, and hit Join now. Then the view swaps in place to the call itself, and the URL never changes, exactly like real Meet.

Inside the call you get the grid of participant tiles that size themselves to the room, a control bar for mic, camera, screen share, reactions, and raise hand, plus a chat panel that keeps its history so late joiners catch up.

Open the People panel to see who's in, and if you're the host, you get the controls that make it real: a waiting room where guests knock for admission, the ability to mute at the media server, and cloud recording with a live indicator. Host power isn't a hidden button either. It's a server-signed grant, so a guest's client simply doesn't hold the capability.

Taking your Google Meet clone to production

Five things change between localhost:5173 and a meeting your users trust, and most clone tutorials never mention any of them.

HTTPS is not optional. Browsers only expose getUserMedia on secure origins, with localhost as the single exemption. Deploy behind TLS or the camera never turns on.

NAT traversal is already handled, and that is the point. Roughly one in five WebRTC connections cannot be established peer-to-peer and needs a TURN relay. Because media here goes through VideoSDK's SFU, you inherit its ICE and relay infrastructure instead of standing up and paying for coturn. [UPDATE: verify current TURN fallback share against VideoSDK network reports]

Token lifetime needs a decision. The functions in api/ mint short-lived meeting tokens per join. If you extend the app with long meetings or reconnect flows, decide what happens when a token expires mid-call, and refresh rather than dropping the participant.

Recordings need a home. Cloud recording writes to VideoSDK storage by default. For anything with a retention or residency requirement, wire the recording webhook to your own bucket and record where that data may legally live.

SPA fallback breaks deep links if you forget it. Meeting URLs are client-side routes. On Vercel this is automatic; on Nginx, S3, or any static host, add a catch-all rewrite to index.html or /:meetingId returns a 404 to every invited guest.

How does this Google Meet clone compare to Google Meet?

This clone matches Google Meet's UI and meeting mechanics, and deliberately skips the accounts-and-history backend behind it.

Capability	This clone	Google Meet
HD video, audio, screen share	Yes, over VideoSDK's SFU	Yes
Chat, reactions, raise hand	Yes, synced to late joiners	Yes
Waiting room and host controls	Yes, server-signed grants	Yes
Cloud recording	Yes	Yes, on paid Workspace tiers
Identity and accounts	A name you type	Google account
Calendar and meeting history	Not included	Yes
Source code and self-hosting	MIT, fully yours	Closed, hosted only

The verdict is conditional. Use Google Meet when you want meetings to just exist for a team that already lives in Google Workspace. Build on this clone when video needs to sit inside your own product, carry your branding, and follow your own permission model. It is a starting point for a product, not a replacement for a hosted meeting service.

Definitions glossary for meeting apps

Room - the VideoSDK unit a meeting happens in. Participants join a room by ID, and every media stream is scoped to it. Here, the room ID is the /:meetingId in the URL.
Participant - one connected client in a room, carrying its own audio, video, and screen-share tracks plus a role that decides what it may do.
Meeting token - a short-lived signed credential granting a client permission to join a specific room, minted server-side in api/ from your API key and secret.
SFU (Selective Forwarding Unit) - a media server that receives each participant's stream once and forwards it to the others, so upload cost stays flat as the room grows.
Prebuilt UI Kit - VideoSDK's drop-in meeting interface, embeddable as an iframe or React component when you want a working call without building the UI at all.

Frequently asked questions about Google Meet clones

Do I need a VideoSDK account to build a Google Meet clone with this repo?
For real meetings, yes, and it's free. You need a VIDEOSDK_API_KEY and VIDEOSDK_SECRET from the dashboard. To just explore the UI, no: fake mode (?fake=ok) runs with no keys at all.

Is the keyless run a real call?
No, the keyless run is not a real call. Fake mode is a local UI preview using a built-in mock client. It's great for design work and clicking through the interface, but nobody can actually join and nothing goes over the network. Add the two keys for genuine multi-participant video.

Is this Google Meet clone really free and open source?
Yes, it is genuinely free and open source. The repo is released under the MIT License, so you're free to use, modify, self-host, and build a commercial product on top of it.

Can I self-host it instead of using Vercel?
Yes, you can self-host it anywhere that runs Node functions. Set VIDEOSDK_API_KEY and VIDEOSDK_SECRET as environment variables, run npm run build, and deploy the api/ functions alongside the static build. On static-only hosts, add an SPA fallback so meeting deep-links load instead of 404ing.

Do I have to write token-minting code?
No, you do not write any token-minting code. The server mints host and guest tokens per request from your key and secret. There's nothing to sign by hand and no token script to run.

How many participants can a meeting hold?
Capacity is set by VideoSDK's SFU rather than the UI, so the grid layout is the practical limit long before the media layer is. Check your plan's concurrency limits before promising a number. [UPDATE: verify participant limits - videosdk.live/pricing]

Can I build a Zoom clone the same way?
Yes, the same architecture applies. Swap the Meet-styled components in src/routes/ for your own layout and keep the src/meeting/ hook layer untouched, since the media logic is UI-agnostic.

Conclusion and next steps

You're a few commands away from your own open-source Google Meet clone, running on real WebRTC infrastructure rather than a demo signaling server.

Try it live on google-meet-clone-by-videosdk.vercel.app, the deployed demo you can open right now.
Fork videosdk-community/google-meet-clone and npm install.
Grab free keys from the VideoSDK dashboard and drop them in .env.
Open Claude Code and start shaping it into your product.

From there, the natural next steps are the VideoSDK React quickstart if you want to understand the hook layer, the Prebuilt UI Kit if you'd rather skip UI work entirely on your next app, and interactive live streaming if your product needs an audience larger than a meeting.

Real video, a polished UI, and an AI agent to do the heavy lifting. What are you building on top of it?