Jitsi Meet on a VPS: Private Video Calls Without Zoom Licences

You can run Jitsi Meet on a VPS with the official Docker setup in about ten minutes, and after that your team holds video meetings on its own server with no per-user licence and no 40-minute cut-off. You need a Linux server with a public IP address, a domain name for HTTPS, and two open ports: TCP 443 for the web page and UDP 10000 for audio and video. Turn on authentication so only your own users can open new rooms, while guests still join with a link. In our lab, the whole idle stack used about 340 MB of RAM. The real cost appears only during calls, as bandwidth and CPU.

Key facts, checked on 9 October 2026:

• The current Docker release is docker-jitsi-meet stable-11248, published on 14 September 2026. It runs four containers: web, prosody, jicofo and jvb.
• The Jitsi handbook's requirements page suggests 8 GB of RAM in general, says 4 GB works for small meetings, and says 4 cores can be enough for a basic server.
• The same page puts video at about 200 kbit/s for 180p, 500 kbit/s for 360p and 2,500 kbit/s for 720p HD per stream. It calls 1 Gbit/s enough for a small organisation and 10 Gbit/s advisable "for a serious server".
• Zoom's free Basic plan ends meetings after 40 minutes, and Pro costs $14.16 per user per month billed annually or $16.99 billed monthly (zoom.us/pricing, US prices).
• Free Google Meet limits calls with 3 or more people to 60 minutes (Google Meet Help).
• The public meet.jit.si service has required a sign-in to create rooms since 24 August 2023 (Jitsi blog). Self-hosting is the way to keep full control over who can sign in.

What is Jitsi Meet, and why host it yourself?

Jitsi Meet is free, open-source video conferencing that runs in the browser. Guests click a link and join from Chrome, Firefox or Safari, or from the Jitsi Meet app on a phone. Nobody needs an account. The code is published under the Apache 2.0 licence on GitHub, so you can run it for a company of any size without paying anyone per seat.

People self-host it for three reasons: meetings pass through a server you control, there are no limits on minutes, rooms or hosts, and you choose where the server sits. A server in Amsterdam or Dublin keeps meetings inside the EU, and one in Prishtina keeps them close to users in Kosovo and the region.

Jitsi is made of four parts, and knowing their names helps when you read logs:

• web serves the meeting page over HTTPS.
• prosody is a chat server (XMPP) that handles sign-in and signalling: who is in which room.
• jicofo, the "conference focus", sets up each meeting and decides which bridge carries it.
• jvb, the Jitsi Videobridge, receives every participant's video and forwards it to the others. This is the part that uses bandwidth and CPU.

What does it cost compared with Zoom and Google Meet?

Hosted services charge per user. Jitsi on your own server costs the same whether five or fifty colleagues host meetings, because you only pay for the server.

Prices come from Zoom's pricing page (US dollars) and Google Workspace pricing (shown to us in euros), both checked on 9 October 2026. They change by country and over time. As an example, ten people with Zoom Pro on monthly billing cost $169.90 a month. On a Jitsi server, adding the eleventh host costs nothing.

The honest trade-off: Zoom and Google run the service for you. With Jitsi you install updates, watch the server and handle support questions yourself.

How big a server does Jitsi Meet need?

An idle Jitsi server uses very little. We started stable-11248 in a Debian 13 lab container with 2 CPU cores and 3 GB of RAM on our Amsterdam test server, and measured it with docker stats several times in the first minutes after start, across two separate lab runs:

The four images took 22 seconds to download and about 2.2 GB of disk (3.2 GB for all of Docker's data), and the stack started in 2 seconds. We could not hold a real meeting with many people in a lab, so for load we rely on the handbook. Treat these numbers as the floor, not as the size you need.

Bandwidth is the real limit

The videobridge forwards each person's video to everyone else, so traffic grows much faster than the number of people. Here is the arithmetic with the handbook's per-stream figures. If 10 people each watch the other 9 at 360p (500 kbit/s), the bridge sends 10 x 9 x 0.5 = 45 Mbit/s. If all 10 watch everyone in 720p HD (2,500 kbit/s), that becomes 225 Mbit/s. At 25 people in HD it reaches 1,500 Mbit/s, more than a 1 Gbit/s port can carry.

Real meetings use less than this worst case, because Jitsi sends the active speaker in high quality and the small tiles in low quality, and a two-person call goes peer to peer, directly between the two browsers. Still, the pattern explains why the handbook advises 10 Gbit/s for a busy server, and why unmetered traffic matters for a team with daily calls.

Which RS Computers plan fits?

The Nano and Micro plans (1 and 2 GB of RAM) sit below the handbook's advice for real meetings. Its smallest figure, 2 GB, is meant for test servers. vCPUs on our plans are shared, and you can move to a bigger plan later from the client area with a short reboot.

How do I install Jitsi Meet with Docker?

These steps follow the official Docker guide. We ran every command below on Debian 13. Before you start, point a DNS A record such as meet.example.com to your server's IPv4 address.

Step 1: install Docker and create a user

# as root
apt-get update
apt-get install -y docker.io docker-compose curl wget unzip
useradd -m -s /bin/bash -G docker,sudo meet
su - meet

Debian 13 installed Docker 26.1.5 and Docker Compose 2.26.1. The user meet is in the docker group, so it can run the stack without being root. Everything from here on runs as that user.

Step 2: download the release and generate passwords

# as the meet user
wget $(wget -q -O - https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep zip | cut -d\" -f4)
ls
unzip stable-11248
cd jitsi-docker-jitsi-meet-*
cp env.example .env
./gen-passwords.sh

The first line asks GitHub for the newest release and downloads it. ls shows a file named after the release, stable-11248 in our case, without a .zip ending; use the name you see. The folder it unpacks to ends in a short code (ours was jitsi-docker-jitsi-meet-276801c), which is why the cd line uses a star. gen-passwords.sh prints nothing. It fills seven internal passwords into .env so your components do not use the example ones.

Step 3: create the configuration folders

# as the meet user
mkdir -p ~/.jitsi-meet-cfg/{web,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri,transcriber}
mkdir -p ~/.jitsi-meet-cfg/storage/{jibri,prosody,transcripts,web}
mkdir -p ~/.jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}
chmod 777 ~/.jitsi-meet-cfg/storage/{jibri,prosody,transcripts,web}
chmod 777 ~/.jitsi-meet-cfg/tmp/{web-crontabs,web-load-test}

The handbook says releases from stable-11146 onward need these folders. Guides written before that release leave out the storage and tmp folders, so follow the current handbook rather than an old blog post.

Step 4: set your domain, ports and IP address

Open the file with nano .env. Find each line below, remove the # in front if there is one, and set your own values. ENABLE_HTTP_REDIRECT was not in the stable-11248 example file, so add it as a new line:

# lines to set in .env (edited as the meet user)
HTTP_PORT=80
HTTPS_PORT=443
ENABLE_HTTP_REDIRECT=1
PUBLIC_URL=https://meet.example.com
JVB_ADVERTISE_IPS=203.0.113.10

JVB_ADVERTISE_IPS is the line people most often get wrong. Put your server's public IPv4 address there. The videobridge runs inside Docker and cannot see that address on its own, so it must be told which address to give to browsers. The handbook warns that with a wrong value, calls break once more than two people join. Two-person calls still work, because they go peer to peer, which makes the fault confusing.

Step 5: start it and check

# as the meet user, in the jitsi-docker-jitsi-meet folder
docker compose pull
docker compose up -d
docker compose ps

You should see four services, all Up. The web line shows ports 80 and 443, and the jvb line shows 0.0.0.0:10000->10000/udp. Check the page and the videobridge from the server itself:

# as the meet user, in the jitsi-docker-jitsi-meet folder
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://localhost/
curl -sk -o /dev/null -w '%{http_code}\n' https://localhost/
docker compose exec -T jvb curl -s http://localhost:8080/about/health -w '%{http_code}\n'

In our lab, HTTP answered 301 and redirected to HTTPS, HTTPS answered 200 with the "Jitsi Meet" page, and the videobridge health check returned 200. The -k flag tells curl to accept the self-signed certificate the stack creates at first.

Step 6: a real certificate

Browsers only allow camera and microphone on HTTPS, and phones reject self-signed certificates. The stack can request a Let's Encrypt certificate itself: set ENABLE_LETSENCRYPT=1, LETSENCRYPT_DOMAIN and LETSENCRYPT_EMAIL in .env. The comments in env.example say the default certificate authority is ZeroSSL, so add LETSENCRYPT_ACME_SERVER="letsencrypt" if you want Let's Encrypt itself. We could not test this step, because it needs a real domain. The other choice is to put Caddy or Nginx in front of the web container, as shown in our reverse proxy and SSL guide. That is easier when the server also hosts other sites.

How do I stop strangers from creating rooms?

Out of the box, anyone who finds your address can open a room and use your bandwidth. The fix is what Jitsi calls a "secure domain": a user name and password to create a room, while guests can still join a room that is already open. Add these lines to .env in the same way as before:

# lines to set in .env (edited as the meet user)
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Apply the change, then create an account for each person who should be able to start meetings:

# as the meet user, in the jitsi-docker-jitsi-meet folder
docker compose up -d
docker compose exec -T prosody prosodyctl --config /run/prosody/config/prosody.cfg.lua register alice meet.jitsi 'A-Long-Password-Here'

Recreating the containers took 15 seconds. The second command printed User account created: alice@meet.jitsi. Keep meet.jitsi exactly as written: it is the internal name of the sign-in domain, not your public domain. To remove someone later, run the same command with deluser alice@meet.jitsi in place of register alice meet.jitsi 'password'. It answers OK: User deleted.

We checked that the lock really works by asking the server which sign-in methods it offers. The main domain offered only SCRAM-SHA-1 and PLAIN, which means a password, while the separate guest domain offered ANONYMOUS. So guests can only enter rooms, not create them. The Docker guide adds that guests wait until a signed-in user has joined the room.

One caveat: the handbook's secure domain page calls this method deprecated and recommends JWT tokens for new setups, where a website or app you run decides who may join. For "our people start meetings, guests join with a link", the internal method still did the job in our stable-11248 lab.

Is my firewall actually protecting the server?

Open only what Jitsi needs. With ufw, Debian's simple firewall:

# as root
apt-get install -y ufw
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 10000/udp
ufw --force enable
ufw status verbose

The status should list ports 22, 80, 443 and 10000/udp as ALLOW IN for IPv4 and IPv6. Now the trap. Docker writes its own firewall rules, and ports published by containers skip ufw. We saw this in the lab. In our first run the web container was still published on port 8443, which ufw did not allow, and a request from the host machine outside the container still got the Jitsi page back. Docker's firewall documentation explains that such packets are routed "before the firewall rules can be applied". The rule of thumb: whatever docker compose ps shows on 0.0.0.0 is open to the internet, whatever ufw says. Jitsi's internal ports (8080 and 8888) are bound to 127.0.0.1, so they stay private. Our Docker on a VPS guide covers this in more depth.

How do lobby, passwords and encryption work for guests?

These are meeting controls for the moderator, the person who started the room. We confirmed that the lobby module is switched on in the Docker setup. We could not click through a multi-person meeting in the lab, so this part comes from Jitsi's own pages:

• A lobby is a waiting room. Guests knock, and the moderator lets each one in. It is turned on from the security options inside the meeting.
• A meeting password can be set by the moderator. Jitsi's security page notes that it is reset once the last person leaves the room.
• All audio and video are encrypted on the network with DTLS-SRTP. The videobridge removes that layer while it forwards packets, which is one more reason to run the bridge on a server you control.
• End-to-end encryption can be turned on so the bridge cannot read the media. Jitsi says it covers audio, video and screen sharing, not chat or polls.

Use the lobby for client calls, and a password for recurring internal meetings. Pick room names that are hard to guess, such as weekly-sales-7f3k rather than sales.

Can I record meetings?

Yes, but the server-side recorder is the heavy part of Jitsi. It is called Jibri, and it works by running a real Chrome browser that joins the meeting and records the screen. The requirements page is clear about the cost:

• Jibri needs one machine per recording, so five meetings recorded at the same time need five Jibris.
• One recording needs at least 8 GB of RAM, and 12 GB at a 1280x1024 resolution.
• The handbook does not recommend running Jibri on the same server as Jitsi Meet, because it uses so many resources.

With Docker you enable it with ENABLE_RECORDING=1 and start it with the extra jibri.yml file. We did not run Jibri in this lab. For most teams there are two lighter options. The web app includes local recording, which saves the meeting in the moderator's browser (the setting is present in the stable-11248 configuration). Or you can put Jibri on a second VDS Small later, when recording becomes a regular need.

Frequently asked questions

Is Jitsi Meet really free?

Yes. Jitsi Meet is open source under the Apache 2.0 licence, with no per-user or per-meeting fees when you host it yourself. You pay only for the server and its bandwidth. The free public service at meet.jit.si is separate, and since August 2023 it requires a sign-in to create rooms.

How much RAM does Jitsi Meet need?

The Jitsi handbook suggests 8 GB in general, 4 GB for small meetings and 2 GB for test servers or very small meetings. In our lab, the idle Docker stack used about 340 MB, so the rest of the memory is headroom for active calls and the Java-based videobridge.

Which ports does Jitsi Meet need?

TCP 443 for the web page and signalling, UDP 10000 for audio and video, and TCP 80 if you want an automatic redirect to HTTPS or a Let's Encrypt certificate. UDP 10000 is the port people forget, and the usual symptom of a closed UDP 10000 is that people can join a meeting but cannot see or hear each other.

How many people can join a Jitsi meeting on a VPS?

It depends mostly on bandwidth, because the videobridge forwards every video stream to every viewer. Ten people at 360p need roughly 45 Mbit/s of outgoing traffic, while twenty-five people in HD can pass 1 Gbit/s. A 4 GB VPS suits meetings of up to about ten people, and a VDS with a 10 Gb/s port suits larger rooms.

Can guests join without an account?

Yes. With ENABLE_AUTH=1 and ENABLE_GUESTS=1, only your registered users can create a room, but anyone with the link can join it once a registered user is inside. Guests need no app and no account, only a modern browser.

Should I use Docker or the Debian packages?

Both are official. Docker keeps Jitsi separate from the rest of the server and makes updates a matter of downloading a new release and running docker compose pull. The Debian packages suit a server that runs only Jitsi. This guide uses Docker, which is the setup we tested.

Get your own meeting server running

Pick a server with enough bandwidth for your largest meeting. Follow the six steps above, set JVB_ADVERTISE_IPS to your public IPv4, lock room creation with ENABLE_AUTH, and open UDP 10000. RS Computers runs KVM servers in Amsterdam, Dublin and Prishtina, with unmetered traffic on every plan and a 10 Gb/s port on VDS plans. Availability by city is on the plans page. Compare them on the VPS and VDS plans page, or see Amsterdam, Dublin and Prishtina. If you would rather have us install Jitsi for you, message us on Telegram and we will quote the setup.

← All articles