Jitsi as a Service

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me embedded video meetings instead of paying for Jitsi as a Service: my own media server, my own domain, meetings inside my own product.

Read this first, because the trade here is unusually clear. The software is free and excellent. What the fee buys is bandwidth and capacity — media servers sized for many participants, and relay servers around the world so a call connects through something near the caller. That is a real cost you are taking on, not a subscription you are avoiding. For a handful of small meetings it is cheap; for hundreds of concurrent participants it is not.

STACK
- Jitsi Meet with its videobridge, or LiveKit if you want a smaller surface and a modern SDK. Do not write a media server
- coturn for TURN, which is what makes calls connect through restrictive networks
- Node 20+ with Fastify and SQLite for your own layer: rooms, tokens, recordings, history
- Caddy in front for the web parts

WHAT YOUR LAYER ACTUALLY DOES
- rooms: id, slug, name, created_by, starts_at, ends_at, max_participants, is_locked, password_hash, lobby_enabled, recording_enabled, created_at
- tokens issued as short-lived JWTs naming the room, the participant, their display name and whether they are a moderator. The media server validates the signature and nothing else — so authorisation is your product's, not the media server's
- participants: id, room_id, name, external_id, joined_at, left_at, was_moderator, connection_quality_json
- recordings: id, room_id, path, bytes, duration_ms, status, started_at, finished_at
- events: id, room_id, kind, actor, at — append-only, so a meeting's history is answerable

THE NETWORK PART, WHICH IS WHERE THIS SUCCEEDS OR FAILS
- TURN is not optional. A large fraction of users are behind networks where a direct connection cannot be made, and without a relay their call simply does not connect. Run coturn with both UDP and TCP, and on port 443 as well, because that is the one that gets through corporate firewalls
- The videobridge needs real bandwidth: budget roughly a megabit per second per participant stream in each direction and size accordingly. A call of ten people is not ten times a call of two, it is worse
- Put the bridge close to the participants. One bridge in one country serving people on another continent is a call with a second of delay, and nobody blames the geography
- Open exactly the ports needed and no others; the media ports are UDP and must not be behind anything that mangles them
- Measure with the real thing: a call between four people on four different networks, one of them on a phone on mobile data. Nothing on a local machine tells you anything about this

EMBEDDING IT
- The meeting runs in an iframe from your own domain, driven by the external API, or with the SDK if you chose LiveKit
- Your product creates the room and mints the token; the participant never sees a join page from anybody else
- Branding: your colours, your logo, your wording, and none of the original's
- Control from your own code: mute, kick, lock, end, and knowing who is in the room

THE MEETING FEATURES PEOPLE EXPECT
- A lobby, so somebody has to be admitted
- A password on the room as well, because a guessable name is a public meeting
- Moderator rights: mute anyone, remove anyone, mute everybody on entry
- Screen sharing, chat, raised hands, and a participant list
- A dial-in number only if you genuinely need it — that means a telephony provider and a per-minute cost, and it is the one part that has no free version

RECORDING
- Recording is a separate process joining the call as a participant and capturing it, then transcoding — which is expensive in CPU and in disk, and is the reason hosted plans charge for it
- Run it on its own machine, queue the transcodes, and cap the length
- Every participant is told the meeting is being recorded, visibly and before they can speak. In several jurisdictions recording without notice is illegal, and quite apart from that it is a betrayal
- Recordings stored encrypted, with a stated retention and a sweeper that actually deletes
- Transcription with a local speech model if you want it; never send the audio to a third party without saying so

PRIVACY
- End-to-end encryption where the stack supports it, with an honest note about what it costs in features — a server that cannot see the media cannot record it or mix it
- Otherwise the media is encrypted in transit and decrypted at your bridge, which is your machine. Say that plainly rather than claiming more
- No analytics inside a call

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, JWT_SECRET, JITSI_DOMAIN, TURN_SECRET, RECORDING_PATH
- Migrations on boot, each once
- Monitor bridge load, participant count and the relay's traffic; alert before saturation rather than after
- Nightly backup of your own database; recordings backed up separately with their own policy
- Health endpoint that checks the bridge and the relay

WHAT MATTERS MOST
TURN and capacity. Get the relay working on port 443 and test a call from a locked-down corporate network before building anything of your own — a meeting product that fails to connect for a quarter of its users has failed completely, and that quarter will never tell you why.

Give me the compose files for the bridge and the relay, your token-minting service, migrations, .env.example, and a README with the network requirements, the bandwidth budget and the recording notice.