Jitsi Meet Server Requirements: CPU, RAM, Bandwidth and What a Server Costs per Month

A self-hosted Jitsi Meet is sized by the meetings it carries at once, and the Jitsi handbook, checked on 1 November 2026, is specific about what that takes in CPU, memory and bandwidth. This guide reads those figures, explains which of Jitsi's components each one applies to, and prices three configurations of the Jitsi Meet package on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic).

What the handbook says

The handbook's requirements page gives memory as a range rather than a floor: 8 GB is usually suggested, 4 GB works for small meetings, and 2 GB can be tried for test servers or very small meetings. For CPU, 4 dedicated cores can be enough for a basic server, with the caveat that Prosody, the XMPP server, can use only one core, so piling on cores past about 32 is not useful; for big meetings the handbook's advice is to scale out with more videobridges rather than up with more memory.

Bandwidth is given per video stream by resolution: 180p about 200 kbit/s, 360p about 500 kbit/s, 720p (HD) about 2,500 kbit/s, 4K about 10 Mbit/s. On the server link, the handbook calls 10 Gbit/s advisable for a serious server and says 1 Gbit/s will often be enough for a friends-or-small-organisation server. The page does not list the required ports.

Which component needs what

Jitsi Meet is four services. The web front end serves the pages and is light. Prosody handles signalling and is single-threaded, so it wants a fast core and little memory. Jicofo allocates conferences to bridges and is light. The videobridge (JVB) forwards every participant's video to every other participant and is where CPU, memory and bandwidth go; a meeting of twenty people at 360p is twenty incoming streams and up to 380 outgoing ones, which is why the handbook's bandwidth figures matter per stream rather than per person.

That split is why the Jitsi Meet package on the marketplace deploys the front end, Prosody with Jicofo, and the videobridge as separate nodes with a public IP for the bridge. Each can be sized on its own, and the bridge can be scaled horizontally, which is the handbook's recommended path for large meetings.

The three configurations on PaaS and their cost

Cloudlets are 128 MiB RAM plus 400 MHz CPU, billed at $0.003372 per cloudlet-hour, $2.46 per cloudlet-month, with no licence fee; Jitsi Meet is Apache-2.0 licensed.

The Starter row's 4 GiB in total matches the handbook's small-meetings figure, the Standard row gives the bridge alone the 4 GiB, and the Production row's two bridges follow the handbook's scale-out advice. All three are ceilings for an always-on server before volume discounts: a Jitsi that hosts meetings for six hours a day is billed for its idle allocation the other eighteen, which for a videobridge at rest is a fraction of the limit. External traffic is billed per gigabyte and is the real variable for video; see the next section. The PaaS pricing calculator prices other layouts and schedules.

Bandwidth, the cost line video adds

Apply the handbook's bitrates to a meeting. Ten participants at 360p, each receiving the other nine, is 90 outgoing streams at 500 kbit/s, 45 Mbit/s from the bridge, or about 20 GB of outbound traffic per hour of meeting. At 720p the same meeting is roughly five times that. The bridge's simulcast and bandwidth estimation reduce the real figure, because participants on small screens receive lower layers, but the order of magnitude holds, and it is why the server link and the per-gigabyte traffic line matter more than the cloudlet line for a busy Jitsi.

Two levers control it. Set the default and maximum resolution in the web front end's configuration to 360p for ordinary meetings, which most organisations find indistinguishable on a laptop, and enable the last-N setting so each participant receives only the most recent active speakers' video. The capacity planning post works through the arithmetic with the bridge's statistics.

When one bridge is not enough

The handbook is clear that large meetings are a scale-out problem. On the platform the videobridge layer is scaled horizontally like any other: a second bridge node registers with Jicofo, which spreads new conferences across the bridges, and OCTO, Jitsi's bridge-to-bridge relay, lets a single very large meeting span several. The Production row starts with two bridges for that reason, and an auto-scaling trigger on bridge CPU adds a third for a conference day and removes it afterwards, billed only for its hours.

The remaining question for most deployments is authentication: who may create a room. The JWT integration post connects a self-hosted Jitsi to Moodle, Mattermost and other applications so that only logged-in users can start meetings, and the Zoom and Teams comparison puts the whole bill beside per-host licensing.

Frequently Asked Questions

How much RAM does a Jitsi Meet server need?

The Jitsi handbook, checked on 1 November 2026, says 8 GB is usually suggested, 4 GB works for small meetings and 2 GB can be tried for tests. On MassiveGRID PaaS the Starter configuration allocates 4 GiB across the three nodes, Standard gives the videobridge 4 GiB on its own, and Production runs two 6 GiB bridges.

How much bandwidth does Jitsi use per participant?

Per video stream, the handbook gives about 200 kbit/s at 180p, 500 kbit/s at 360p, 2,500 kbit/s at 720p and 10 Mbit/s at 4K. Each participant receives a stream from every other visible participant, so a ten-person 360p meeting sends roughly 45 Mbit/s from the bridge; last-N and simulcast reduce it.

What does self-hosted Jitsi cost per month?

About $78.72 for the Starter configuration, $118.08 for Standard and $314.88 for the two-bridge Production layout on MassiveGRID PaaS, at $0.003372 per cloudlet-hour before volume discounts, plus outbound traffic per gigabyte. Jitsi Meet has no licence fee.