Since December I've been running a jitsi instance just for family and friends. It's been working well for me, and I like that I can just send a link to anyone and they can click it and join the call in a browser without messing around.
Edit: since this in HN, I'll mention too that I don't even bother with passwords. I set up basic auth on the endpoint for management and room creation, and just leave the room(s) open. For a low key chat-with-friends-and-family setup, it's great and I haven't had to touch it since I set it up.
It's about $40/month, but it's my personal server for everything else too. Hosts some web radio projects with liquidsoap and icecast, some generative audio experiments, and so on. It's still probably more server than I need.
Edit: remembered that wrong. It's $66/month. But I'm using an instance much larger than you'd need to just run jitsi.
You can get so much mileage from a $40 hetzner instance. Mine is doing all forms of useful things. My only critique is that latency to storage boxes is awful (and storage is otherwise really pricey).
I'm running Jitsi in Docker on a VPS. I use it for voice + video chat while playing online games with friends. For this use case, I had to do almost no tweaking from defaults, so I have not become a Jitsi expert at all. It's been running for about a year with no issues I can remember.
One annoyance was that I couldn't figure out how to set up a persistent room protected by a code. My goal was to have no usernames or passwords, but without allowing completely open access - I just wanted to distribute a room name and single known password/passcode my friends could use to get into the room.
Since this didn't seem to be possible at the time, I settled for requiring rooms to have a "host," which is just me. That way I deal with a username and password, but nobody else has to. It does make it impossible for the rest of the group to play without me, but this isn't an issue for our situation.
Unfortunately I don't have a very helpful answer - it's free to me. I said VPS as a simplification, but the actual situation is some co-colocated hardware a friend of mine runs. He gives me a virtual slice of it because he has excess capacity.
That said, compute-wise I would expect Jitsi to run fine on a $5 droplet or similar. Probably have to watch out for bandwidth costs, I haven't been monitoring my usage because I don't have to.
Using the Jitsi website has worked well enough for me for years, and the calls are P2P as far as I'm aware. What's the advantage of hosting your own? Just preventing jitsi.org from seeing call metadata?
Zoom costs money beyond 40 mins, unlike Jitsi. It also doesn't require anyone to have an account, or to install any software. These are key differentiators in my book!
Jitsi is footing the bill if you use the hosted product. If you don't want it to shut down or become expensive, you need to take a look at how the server is being run.
With self-hosted, you're simply paying for the servers. If you can pay for the servers and maintain them, you can be confident they'll stay up.
The hosted product is great, it just seems separate and off topic to me.
I wonder if you could get more reliable performance by planning a more centralized location. My book club uses the main jitsi site and it works well all things considered, but it's not perfect by any means. We've got people in several US and EU time zones showing up with varying internet connection qualities, so it's a difficult case.
But hey, it's free. And it hits the most important consideration: it could not be easier to use. That's pretty critical since my club mates don't have much capacity for troubleshooting.
I've been hosting it for about 2 years, running in a container on a Proxmox host (a DL380G7 with 128GB RAM and a DS4243 JBOD in a tailor-made enclosure under the stairs here at the farm) together with a bunch of other services. It is not used all that often but when I need it it is there and works as intended. After configuring it I have not had to do anything else than run apt update && apt dist-upgrade every now and then. It is a bit of a memory hog just like most other jvm-based services but it is reliable and dependable.
Do you have a handle on how much of a memory hog? I've considered installing it for a small group of people (~15 total, likely no more than 6 actively on a video call at any given time) but the dedicated server I'd put it on only has 32Gb in total (though it does run very little else that needs much memory: a large filesystem for backups, a web server hosting simple stuff, a LanguageTool self-install, occasionally other things I'm tinkering with that benefit from more bandwidth that the ~12mbit I currently get upstream hosting things at home).
I run a matrix server deployed using their annsible script [1] which comes with jitsi, etherpad, etc.
The setup was a bit of a hassle (need to get the domain configured for federation, updating the config files etc) but after a weekend of configuration it has been rock solid since (in operation for a year now). I use it primarily as a centralized chat client (using bridges to the various propriatary chat services) but it is nice to be able to throw up a quick jitsi call and/or etherpad document.
The whole ansible/docker stuff is over my head, but these days I just run the playbook to apply updates and it hasn't failed me yet. Backups are handled by taking snapshots of the VM it runs in.
The jitsi web client works great on desktop, but I would recomend using the dedicated mobile apps because I have heard reports the web client struggling on mobile.
I've set one up before when the pandemic was in full swing. I haven't really been stuck in group call hell for well over a year with my work now but at the time I was really impressed about how much higher the video and audio quality was over what zoom had at the time.
The only complaint we had was the mobile performance. Made older phones hot and killed the battery fast.
A serious pain point is that Jitsi stopped supporting Ubuntu 18.04 with no warning, well before its EoL date.
An update led to a dependency issue (I would have to go remind myself which but I think Prosody) and that was that - just a ‘well lets stop supporting Ubuntu 18.04 then’.
I think over time the advice has been to go manually downgrade some packages or try and find the relevant versions somewhere. A more satisfactory solution would be to support the up to date versions of dependencies available to the distribution jitsi is installed on.
We’re getting to the point where this doesn’t matter of course, as 18.04 goes end of life. But you can understand why we are reluctant to recommend jitsi as a stable and reliably maintained option after this experience.
I attempted self hosting it on an RPI4 but the video quality was dropping heavily and stopping alltogether from time to time. I did not see an obvious bottleneck anywhere in the system. The rpi had both ram and cpu to spare, my connection is 1gbps down, 100mbps up. Should be more than enough for two people.
This was early this year. I followed the official guide word-to-word. Others reported similar issues on the official forum so my issue isnt new or unique.
Just wanted to say thanks as well. I host a private Jitsi server for my online teaching. It took a bit of effort to set up but worked well for me since.
Public documentation on how to automatically install + configure the Debian packages would be great (i.e. using debconf-set-selections). I've figured it out from forum posts, etc. in the past, but it keeps changing, causing my installation scripts to get stuck waiting for user input.
Hey, I'm part of a team that self hosts a jitsi instance. I've made a small plugin that uses some CSS-hacks to make the buttons in the bottom of the call also have text, and not just icons. It makes it much easier to explain to someone which button you need to press to access the chat, or begin to screen share.
Instead of sharing the ugly CSS-hacks here's just the list of what I've named the buttons, the CSS-hack isn't something I would expect to make it upstream so to say.
From left to right:
- Mic
- Webcam
- Screen share
- Chat
- Hey! (it's willingly ambiguous so that someone might stumble upon the feature in a exploratory manner, we don't really use the "raise hand" function in a serious way)
- This call
- Layout
- More actions
- Leave
I seem to always have trouble with video freezing or very low quality audio+video. Jitsi just isn't reliable enough for me. We've switched to BigBlueButton on the same type of server and it runs gloriously, with HD video, crisp audio. I kept giving Jitsi a chance, but it disappointed us too many times
No but my networking group does, which I thought was an interesting choice. It was because the whole 'zoom is insecure' thing was going around when the pandemic hit. It's worked out OK ish, they're still using it after 3+ years.
I set one up on my basement server when the pandemic hit for my church, since Zoom's free meetings were limited to 45 minutes. I was able to allow Jitsi to run as a web app on phones, but people complained that it ate through their batteries fast and caused them to get hot. They went back to meeting in person outdoors, and didn't need it. I turned it off after about a month, and haven't needed to look into it again.
IRC + Jitsi could work for a lot of people, but there's still enough trust in big centralized platforms for people to be satisfied with them.
It's not clear that regular people care about where software is hosted. If anything it's just far more convenient that you don't have to deal with anything. Did anyone care how secure zoom was? Not really. Just pure convenience.
Yep, I ran one on bare-metal for many years, then a Jitsi-Meet server as a 'replacement' while running the original for 1-on-1 calls so the execs could use the full end-to-end crypto.
Jitsi is great, IMO. Highly recommend.
I've left the company since, I believe they were bought out and switched to MS Teams now.
I run a Jitsi instance on Linode. I used their push-button setup, then tweaked the security settings slightly. I keep it off and on a minimal instance except when it's time for a meeting, at which point I move it to a dedicated host for the duration of the meeting. I always check my TLS/SSL certificates and update the OS before the meeting, too. It has been okay, but not as reliable as Google Meet or Zoom. There's often someone having audio issues, typically on an iPad. Before I switched to a dedicated instance, those problems were worse. One of my regular meeting participants co-founded the FSF, so I'm using Jitsi so that we're using open-source software. I'm a big fan of Jitsi, but I want to be realistic about its reliability in my experience.
It's hard to tell. There are typically only three or four people in the room at most, and the iPad audio problems typically occur with even fewer people.
I believe that the iPad user is using the web, not the app.
Wasn't there news recently about Safari overtaking edge as the second most popular browser?
If so, we should probably be developing for it too. Not just the top 1. Yes, there's a gap between 1 and 2, but you can't just discount it when building an app.
We did it for a long time but finally got pushed into Zoom due to edge case issues like distorted audio for some participants and the need to support really big meetings. We pretty much have to buy a Zoom subscription due to sales calls anyway, so we had it.
In my experience Jitsi actually works better than Google Meet and I like self-hosting it, but Zoom works better than any and all WebRTC-based solutions.
The hard thing for things like Jitsi is that they have to work in the browser and are therefore held prisoner by how good the browser is. Most of the issues we ran into are probably browser issues not Jitsi issues since we also have tons of problems with Google Meet.
Well, I for one host my own Jitsi instance because of Internet censorship. The censorship is very bad here so major social media like WhatsApp and Telegram etc are blocked. And for cases such as Skype and Google Meet which aren't blocked the connection is sometimes throttled (not to mention that sometimes they just cut the Internet off) so that leaves one option: a self-hosted Jitsi instance on an Iranian data center.
Fun fact: Even on an Iranian data center, I had to limit the video quality on my own server to 360p because other qualities don't work great either.
Authentication can be another important one, if you want to integrate with your existing SSO or other auth mechanism.
Last, customization. While this can be done via JaaS too (our CPaaS offering) you will always have full control over your deployment if you self-host it.
For my use case, I also use the hosted version. It's worked great, and as Zoom tightens the belt on meeting duration I am shifting more of my meetings to Jitsi. No one has ever complained, and I've asked folks for feedback to see how it compares to Zoom/Google. IME it's about the same as Zoom, and better than Google or Teams.
I was, but haven't for a year or so. It was handy during the COVID lockdown when I lived about 100 miles (three or so hours drive) from my mum and she wanted to see her grandson.
Really the only reason I took it down was I moved my hosting to another server and never bothered to set it up.
Yes, in a commercial setting. It's somewhat complicated as a stack, but when everything plays together, it's low latency, good quality, flexible and scalable across regions.
Only downside in my experience: cross device video never works?
Good luck making a video call with chrome + firefox + android clients in the same room.
> Jitsi is a set of open-source projects that allows you to easily build and deploy secure video conferencing solutions. At the heart of Jitsi are Jitsi Videobridge and Jitsi Meet, which let you have conferences on the internet, while other projects in the community enable other features such as audio, dial-in, recording, and simulcasting.
Is it like self-hosted Zoom alternative? I feel like if an org is on Teams, they'll just use Teams video conference. Same for Slack. I used to work at an org that had Teams + Slack + Google Hangouts/Google Meet + Zoom.
I use the hosted version and tried it out after seeing it on HN a couple years ago. I have slowly increased my percentage use over the years, and now that Zoom is limiting 1-to-1 calls to 40 mins (used to be unlimited), I am moving over to Jitsi.
Everyone I've talked with says it's easy to use, and connectivity has been just about as good as Zoom.
Yes, I ran & still run a Jitsi instance and a website which would connect you to one of 12 participating Jitsi server at random applying to our guidelines in the EU.
My goal was offering a low-barrier open for all way to connect with loved ones. During the peak of the Covid pandemic for many people it was easier to connect with colleagues than family members or friends. So I contacted a few sysadmins and public organizations of whom I knew were running Jitsi and asked if it could be shared via our public website. A few agreed and a few dropped by and wanted to help out. After a few days a commercial hosting company decided to sponsor us with one VPS as well.
Our idea was to connect the servers and use the API to select a server with the lowest load. In the meantime we used a randomizer...we've never used the API after all, the randomizer worked well enough ;)
People told us they've used our free service for yoga classes, library book reading clubs, hackerspaces & celebrating birthdays with grandma.
Overall I'm still very proud what we've achieved in a few days with some servers, opensource software and bit of work.
Many thanks to @saghul, 8x8 and all other people contributing to Jitsi. Thank you!
Yes, I had hosted it on Digital ocean for a long time to bypass telco regimes where FaceTime and WhatsApp is blocked for A/V calls.
It worked pretty well. I was scared of security issues where I thought some miscreants might have calls and I get blamed for it. There were security issues(which probably could be fixed but I didn’t spend too much time)
I'm looking forward to Element Call, which is currently in development.
It looks like their design starts with WebRTC running through SFU (selective forwarding units), which is pretty common by itself, but they're adding a tree-like SFU hierarchy in order to handle many participants without requiring expensive MCU (multipoint control unit) servers.
I assume it will become part of the Matrix spec rather than being an Element-only feature, though I don't think I've seen that confirmed. Maybe Arathorn will see this and comment?
Contrast with Jitsi, which requires Java, making it too heavy for my low power ARM server, and does end-to-end encryption in a way that's too heavy for some of my contacts' web browsers to run smoothly.
In the meantime, I've been relying on my Mumble server when I don't need video. The sound quality and latency are top notch, and the hardware requirements are low.
The thing keeping it in beta has been a set of really annoying intermittent bugs, which we’ve ended up tracking down by adding full opentelementry support; should expect to exit beta in the next few weeks (currently gathering data to check we really did fix them). Meanwhile we’re experimenting with other SFU implementations (eg LiveKit) to see if we can avoid reinventing the wheel there.
Element Call style VoIP is already proposed for the Matrix spec - MSC3401 and MSC3898.
102 comments
[ 4.2 ms ] story [ 164 ms ] threadEdit: since this in HN, I'll mention too that I don't even bother with passwords. I set up basic auth on the endpoint for management and room creation, and just leave the room(s) open. For a low key chat-with-friends-and-family setup, it's great and I haven't had to touch it since I set it up.
Edit: remembered that wrong. It's $66/month. But I'm using an instance much larger than you'd need to just run jitsi.
You'll find plenty of decent ones here for ~€40/month.
One annoyance was that I couldn't figure out how to set up a persistent room protected by a code. My goal was to have no usernames or passwords, but without allowing completely open access - I just wanted to distribute a room name and single known password/passcode my friends could use to get into the room.
Since this didn't seem to be possible at the time, I settled for requiring rooms to have a "host," which is just me. That way I deal with a username and password, but nobody else has to. It does make it impossible for the rest of the group to play without me, but this isn't an issue for our situation.
That said, compute-wise I would expect Jitsi to run fine on a $5 droplet or similar. Probably have to watch out for bandwidth costs, I haven't been monitoring my usage because I don't have to.
Jitsi is xo posee of several moving parts, and making sure everything works well out of the box is something we deeply care about.
(I.e., there is no universe in which Jitsi's possible/likely abuse of this data is remotely close to Zoom's)
With self-hosted, you're simply paying for the servers. If you can pay for the servers and maintain them, you can be confident they'll stay up.
The hosted product is great, it just seems separate and off topic to me.
But hey, it's free. And it hits the most important consideration: it could not be easier to use. That's pretty critical since my club mates don't have much capacity for troubleshooting.
Do you have a handle on how much of a memory hog? I've considered installing it for a small group of people (~15 total, likely no more than 6 actively on a video call at any given time) but the dedicated server I'd put it on only has 32Gb in total (though it does run very little else that needs much memory: a large filesystem for backups, a web server hosting simple stuff, a LanguageTool self-install, occasionally other things I'm tinkering with that benefit from more bandwidth that the ~12mbit I currently get upstream hosting things at home).
The setup was a bit of a hassle (need to get the domain configured for federation, updating the config files etc) but after a weekend of configuration it has been rock solid since (in operation for a year now). I use it primarily as a centralized chat client (using bridges to the various propriatary chat services) but it is nice to be able to throw up a quick jitsi call and/or etherpad document.
The whole ansible/docker stuff is over my head, but these days I just run the playbook to apply updates and it hasn't failed me yet. Backups are handled by taking snapshots of the VM it runs in.
The jitsi web client works great on desktop, but I would recomend using the dedicated mobile apps because I have heard reports the web client struggling on mobile.
edit: forgot link [1] https://github.com/spantaleev/matrix-docker-ansible-deploy
Self-hosting is one of the use cases we spend a lot of time on, recently venturing into a hybrid model with JaaS components.
If there is any pain point with self-hosting, please let us know!
Thank you for your hard work!
The only complaint we had was the mobile performance. Made older phones hot and killed the battery fast.
Other than that great software suite!
An update led to a dependency issue (I would have to go remind myself which but I think Prosody) and that was that - just a ‘well lets stop supporting Ubuntu 18.04 then’.
I think over time the advice has been to go manually downgrade some packages or try and find the relevant versions somewhere. A more satisfactory solution would be to support the up to date versions of dependencies available to the distribution jitsi is installed on.
We’re getting to the point where this doesn’t matter of course, as 18.04 goes end of life. But you can understand why we are reluctant to recommend jitsi as a stable and reliably maintained option after this experience.
I attempted self hosting it on an RPI4 but the video quality was dropping heavily and stopping alltogether from time to time. I did not see an obvious bottleneck anywhere in the system. The rpi had both ram and cpu to spare, my connection is 1gbps down, 100mbps up. Should be more than enough for two people.
This was early this year. I followed the official guide word-to-word. Others reported similar issues on the official forum so my issue isnt new or unique.
Instead of sharing the ugly CSS-hacks here's just the list of what I've named the buttons, the CSS-hack isn't something I would expect to make it upstream so to say.
From left to right:
And lastly, thanks for making great software."then press the three-lines" makes me feel debased as a human being, like I'm reduced to pictograms because language has been taken from me.
That this isn't a standard part of every software, is part of what's gone wrong with UI/UX in the last decade or so.
Hamburger menu? https://www.mobileapps.com/blog/hamburger-menu
I share your disdain for this sort of UI, but then I'm content with a CLI...
IRC + Jitsi could work for a lot of people, but there's still enough trust in big centralized platforms for people to be satisfied with them.
https://github.com/ergochat/ergo
https://github.com/kiwiirc/kiwiirc
https://github.com/kiwiirc/plugin-conference
Jitsi is great, IMO. Highly recommend.
I've left the company since, I believe they were bought out and switched to MS Teams now.
For adhoc gaming sessions, family chat during corona.
Disabled audio activity indicator(?) to severely reduce client CPU usage.
I believe that the iPad user is using the web, not the app.
If so, we should probably be developing for it too. Not just the top 1. Yes, there's a gap between 1 and 2, but you can't just discount it when building an app.
Those on an iPad, were they using the app or the mobile web app?
In my experience Jitsi actually works better than Google Meet and I like self-hosting it, but Zoom works better than any and all WebRTC-based solutions.
The hard thing for things like Jitsi is that they have to work in the browser and are therefore held prisoner by how good the browser is. Most of the issues we ran into are probably browser issues not Jitsi issues since we also have tons of problems with Google Meet.
Fun fact: Even on an Iranian data center, I had to limit the video quality on my own server to 360p because other qualities don't work great either.
Authentication can be another important one, if you want to integrate with your existing SSO or other auth mechanism.
Last, customization. While this can be done via JaaS too (our CPaaS offering) you will always have full control over your deployment if you self-host it.
Really the only reason I took it down was I moved my hosting to another server and never bothered to set it up.
Only downside in my experience: cross device video never works? Good luck making a video call with chrome + firefox + android clients in the same room.
If you’d like to dig into it, please reach out to us on GH or to me at HNusername@jitsi.org
> Jitsi is a set of open-source projects that allows you to easily build and deploy secure video conferencing solutions. At the heart of Jitsi are Jitsi Videobridge and Jitsi Meet, which let you have conferences on the internet, while other projects in the community enable other features such as audio, dial-in, recording, and simulcasting.
Is it like self-hosted Zoom alternative? I feel like if an org is on Teams, they'll just use Teams video conference. Same for Slack. I used to work at an org that had Teams + Slack + Google Hangouts/Google Meet + Zoom.
Everyone I've talked with says it's easy to use, and connectivity has been just about as good as Zoom.
My goal was offering a low-barrier open for all way to connect with loved ones. During the peak of the Covid pandemic for many people it was easier to connect with colleagues than family members or friends. So I contacted a few sysadmins and public organizations of whom I knew were running Jitsi and asked if it could be shared via our public website. A few agreed and a few dropped by and wanted to help out. After a few days a commercial hosting company decided to sponsor us with one VPS as well.
Our idea was to connect the servers and use the API to select a server with the lowest load. In the meantime we used a randomizer...we've never used the API after all, the randomizer worked well enough ;)
People told us they've used our free service for yoga classes, library book reading clubs, hackerspaces & celebrating birthdays with grandma.
Overall I'm still very proud what we've achieved in a few days with some servers, opensource software and bit of work.
Many thanks to @saghul, 8x8 and all other people contributing to Jitsi. Thank you!
If you want to do it anyway: create a fully automated setup to quickly spin up a new instance.
It worked pretty well. I was scared of security issues where I thought some miscreants might have calls and I get blamed for it. There were security issues(which probably could be fixed but I didn’t spend too much time)
The problem was UX for mom and pop folks
It looks like their design starts with WebRTC running through SFU (selective forwarding units), which is pretty common by itself, but they're adding a tree-like SFU hierarchy in order to handle many participants without requiring expensive MCU (multipoint control unit) servers.
https://element.io/blog/introducing-native-matrix-voip-with-...
https://element.io/blog/element-call-beta-2-encryption-spati...
I assume it will become part of the Matrix spec rather than being an Element-only feature, though I don't think I've seen that confirmed. Maybe Arathorn will see this and comment?
Contrast with Jitsi, which requires Java, making it too heavy for my low power ARM server, and does end-to-end encryption in a way that's too heavy for some of my contacts' web browsers to run smoothly.
In the meantime, I've been relying on my Mumble server when I don't need video. The sound quality and latency are top notch, and the hardware requirements are low.
The thing keeping it in beta has been a set of really annoying intermittent bugs, which we’ve ended up tracking down by adding full opentelementry support; should expect to exit beta in the next few weeks (currently gathering data to check we really did fix them). Meanwhile we’re experimenting with other SFU implementations (eg LiveKit) to see if we can avoid reinventing the wheel there.
Element Call style VoIP is already proposed for the Matrix spec - MSC3401 and MSC3898.