In my previous post, I discussed why the Initiative for Literacy in a Digital Age switched to a self-hosted Jitsi Meet server for our video conferencing needs. Today, I want to share how.
While Reclaim Cloud offers a “one-click” installer for Jitsi, getting it “production-ready” for real-world use required navigating a few technical hurdles. If you are looking to set this up yourself, hopefully, my experience can save you some time.
Here is the rundown of getting our server from a raw install to a branded, secure, custom-domain experience.
The Initial Hurdle: The “Not Secure” Error
Reclaim Cloud’s Jitsi installer is fast and effective, but by default, it runs behind a shared load balancer and a generic Reclaim URL. A load balancer acts as a gateway that manages incoming traffic. While the default shared version is great for getting Jitsi up and running instantly, moving to a dedicated setup is usually necessary if you want a custom domain name and professional branding.
A shared load balancer is akin to an apartment building where multiple tenants share the same front door. That works for standard web traffic, but high-bandwidth video calls often require a dedicated IP (Internet Protocol address). This provides Jitsi with a private driveway, ensuring the fastest, most direct path for data.
When I tested the default setup, the browser flagged the site as “Not Secure,” and the camera refused to turn on, throwing WebRTC errors.
WebRTC is the part of your browser that handles live audio and video. It’s what turns Chrome or Firefox into a walkie-talkie and camera. And it’s picky.
Think of WebRTC as a high-security clearance badge. Because it gives a website permission to access your physical hardware (your camera and mic), modern browsers act as strict gatekeepers. If that ‘Not Secure’ warning appears, the browser loses trust in the connection and essentially pulls the plug on the walkie-talkie to protect your privacy.
Modern browsers will not allow WebRTC to use the microphone or camera unless the site is running over HTTPS.
No lock. No video.
Step 1: Assigning a Public IP (and Why It Matters)
HTTPS (Hypertext Transfer Protocol Secure) is the encrypted version of the protocol computers use to communicate. It’s the little lock in your browser. It tells your computer that no one can peek in while you’re talking.
Imagine sending a postcard through the mail. Anyone who handles it, the mail carrier, the sorting facility, or a nosy neighbor, can read what you wrote. That is standard HTTP.
HTTPS is like taking that same message, locking it in a tamper-proof titanium box, and sending it. Only the person with the specific key (your server) can open it. If anyone else “peeks in” while it’s traveling across the internet, all they see is scrambled gibberish.
Without it:
- The browser assumes the site is unsafe
- Camera and microphone access are blocked
- Video calls simply don’t work
For Jitsi, HTTPS isn’t optional. It’s the rule that makes video possible.
To get HTTPS working reliably, Jitsi needs its own clear address on the internet. In Reclaim Cloud, that meant attaching a dedicated public IPv4 (Internet Protocol version 4) address directly to the server.
An IP address is like a street address. A public one means messages don’t have to pass through someone else’s house first. This is particularly important for live video, where timing is crucial.
Think of a Public IP as a direct delivery route. Without it, your video data has to stop at a ‘sorting center’ (the shared load balancer) to figure out which server it belongs to. With a Public IP, data flows directly to your server’s front door. This reduces lag and makes it much easier for security services to verify your ‘identity’ and issue the essential HTTPS padlock.
This adds a small monthly cost, but it’s essential for stability.
Step 2: The Domain + SSL “Chicken and Egg” Problem
Once the server had a public IP address, I still couldn’t use it safely. Modern browsers require HTTPS with a valid SSL certificate before they’ll allow access to cameras and microphones. In addition, SSL certificates can only be issued to domain names, not raw IP addresses.
So I needed to connect my custom domain, videochat.initiativeforliteracy.org , to the server and configure Jitsi to use it properly.
The key was doing things in the right order.
First, I created an A record in my domain settings that pointed the subdomain to the server’s public IP.
This tells the internet where to send people when they type in the address. For a non-technical translation, think of this as putting your name on the map. The server already exists, but until you create the DNS record, no one knows that “videochat.initiativeforliteracy.org” belongs to that specific location. It’s like telling a GPS system that “My Office” is located at a particular street address.
Second, I returned to Reclaim Cloud and applied the Jitsi domain configuration so the server would recognize its new name.
In plain terms, this step is telling the server its identity. Even though the domain now points to the server, Jitsi still thinks it’s called something like env-12345.reclaim.cloud. You have to formally introduce it to its new name so it knows to respond when someone connects.
It’s similar to moving into a new office and putting your nameplate on the door. Now, when someone arrives looking for you, the building knows where to direct them.
Finally, Jitsi requested an SSL certificate from Let’s Encrypt.
This is the step that adds the official security seal. The certificate authority verifies that you control the domain and then issues a digital credential that enables HTTPS encryption.
A helpful analogy is getting a notarized business license. It proves to visitors that you are who you claim to be, which is why the browser finally displays the secure padlock.
Once these three pieces were in place (mapping the address, naming the server, and verifying security), everything clicked into place. The lock icon appeared immediately, and the camera and microphone began working without any additional changes.
Step 3: Ensuring Moderator Control
By default, Jitsi works on a first-come, first-served system. The first person who joins a meeting automatically becomes the moderator.
That’s fine for casual calls, but it can cause problems in hosted sessions. If a student, guest, or early participant clicks the link before you do, they’re suddenly in charge. This includes the ability to mute others, start recordings, or control the room.
To fix this, I created a permanent admin account using Jitsi’s built-in authentication system (Prosody) via Reclaim Cloud’s web-based SSH interface. In simple terms, this meant giving myself an official “owner login,” so the system knows who should always be in charge.
In Plain English, think of this like managing a meeting space. By default, Jitsi is like a community room where whoever walks in first automatically gets handed the master key and the microphone. That works until the wrong person arrives early.
To prevent accidental moderators, here’s how I created a permanent admin account using the server’s backstage control panel.
Step 1: Creating an Admin Account
Prosody is the software Jitsi uses to manage user accounts and permissions. By creating a login there, I told the system that I was appointing a permanent manager.
Basically, letting the system know: “This person is the official host. Don’t give control to anyone else until they sign in.” It’s like assigning a permanent building manager who always has the master key.
Step 2: Using the Web-Based SSH Interface
SSH (Secure Shell) sounds complicated, but it simply means accessing the server’s control panel directly through a text interface.
Reclaim Cloud provides this in the browser, so there’s no special setup required. You just click a button and type commands.
Think of this as entering through a staff-only door to adjust how the building operates, instead of using the public entrance. This ensures the meeting room stays under my control until I log in. It turns hosting from a race into a deliberate choice.
The Result: Hosting by Design, Not by Accident
Before this change, I had to rush into meetings early just to make sure I got to be the moderator. Now, the workflow is intentional.
The room stays effectively “locked” until I log in with my admin credentials. Only then does the system grant moderator control.
No surprises. No accidental hosts. No scrambling to reclaim the mute button.
Summary and Cost Management
Getting Jitsi production-ready required understanding how public IPs, domains, and HTTPS work together; the result is a stable, private video space that we control.
To manage costs, we spin the server up shortly before meetings and shut it down afterward. We pay for computing power only when we’re actually using it.
As I worked through questions about access, openness, and control, I realized I was doing exactly the kind of computational thinking I ask educators and students to practice. Naming constraints, anticipating edge cases, and taking responsibility for imperfect choices.
In the next post, I reflect on those questions, and why I think they matter more than the setup itself.
Photo by Brett Jordan on Unsplash