Tutorials & How-To · Article A071

Install BigBlueButton: Step-by-Step for a First-Time Setup

Get a stable BigBlueButton deployment from scratch — covering every key step, critical settings, and the common mistakes that trip up first-time installers. Built for IT administrators, sysadmins, and instructional technology teams who need a reliable server running fast.

Installing BigBlueButton for the first time is one of the most rewarding — and most unforgiving — tasks an IT team can take on. Done right, you get a powerful, open-source web conferencing platform purpose-built for education, fully under your control, ready to integrate with Canvas, Moodle, Blackboard, or any LMS that supports LTI. Done wrong, you end up with a server that crashes under load, recordings that never appear, or a TURN configuration that locks out half your users before a session even starts.

This guide walks through the complete install BigBlueButton process step by step — from choosing the right Ubuntu server and running the bbb-install script, to configuring Let's Encrypt TLS, setting up a TURN server for WebRTC connectivity, enabling recordings, and verifying that everything works before your first live session. We cover performance tuning, Scalelite load balancing for multi-server clusters, monitoring and alerting, and the most common troubleshooting scenarios that catch first-time installers off guard.

Recording on BigBlueButton is one of the platform's most-used features, and getting it right during initial setup saves significant pain later. We explain how to record BigBlueButton meetings from the first session, where to find conference recordings on BigBlueButton, how to access BigBlueButton recordings as an admin, and how to configure recording post-processing so that completed recordings appear reliably for instructors and students inside Canvas or other LMS platforms.

Whether you are setting up a pilot server for a department, migrating from a previous installation, or building a production multi-node cluster from scratch, this article gives you a realistic, checklist-driven picture of what the installation actually involves — and where managed hosting can remove the most painful parts of the process entirely.

This is not a summary of the official docs. It is a practical, experience-informed guide written for IT professionals and technical administrators who want to understand every decision point, every configuration risk, and every post-install validation step before they commit to a deployment path.

Quick Navigation

What Does It Mean to Install and Host BigBlueButton?

Installing BigBlueButton means deploying the full application stack — web server, media server, recording processor, TURN relay, and all supporting services — onto a Linux (Ubuntu) server that you own or rent. Unlike SaaS conferencing tools, BigBlueButton is self-hosted software: the institution or provider running it is entirely responsible for the server's stability, capacity, security patching, and data management.

Hosting responsibilities for a BigBlueButton server include:

• Provisioning and maintaining the underlying Linux server (Ubuntu 20.04 or 22.04 LTS).
• Running and updating all BigBlueButton services: Nginx, FreeSWITCH, Kurento or mediasoup, HTML5 client, and the recording subsystem.
• Configuring and renewing TLS certificates (Let's Encrypt or institutional CA) for HTTPS and WSS endpoints.
• Deploying and maintaining a TURN server (coturn is the standard) for WebRTC connectivity through firewalls and NAT.
• Managing disk space for recording post-processing — raw recordings, processed formats, and published playback files all accumulate rapidly.
• Applying OS and application security patches promptly to maintain a hardened posture.
• Monitoring CPU, RAM, network, and disk utilisation — and responding to alerts before they become outages.
• Performing backups and testing restore procedures for configuration files, recording archives, and database state.
• Scaling the deployment — either by upsizing the single node or by adding nodes behind a Scalelite load balancer — as concurrent demand grows.

What BigBlueButton Is — and Why the Server Beneath It Defines the Experience

BigBlueButton is an open-source web conferencing system designed from the ground up for online education. It includes multi-user whiteboards, breakout rooms, polling, shared notes, public and private chat, screen sharing, webcam video, and a fully featured recording and playback system. All of these features run inside the browser via WebRTC — no plugin or installed client required for participants.

The platform's strength is also its distinguishing challenge: every audio packet, every video frame, every screen-share stream, and every recording job is processed by the server you install and run. A correctly sized and tuned BigBlueButton server delivers a smooth, low-latency experience. An undersized or misconfigured server delivers frozen video, choppy audio, failed recordings, and frustrated instructors mid-lecture.

Peak concurrency is the critical planning variable. During a typical academic week, a university might run 5–10 concurrent sessions at most. During exam week, finals review days, or a campus-wide virtual open day, that number can spike to 60, 80, or 150 simultaneous rooms within minutes. A server sized for average load will fail precisely when you can least afford it. Capacity planning must be done against your realistic peak — not your average.

Recording on BigBlueButton adds a significant secondary load: post-processing converts raw session captures into web-playable formats. This is CPU-intensive and runs on the same server as live sessions unless you explicitly separate it. Many first-time installs skip this separation and discover the problem only when recording post-processing begins degrading live sessions during a busy afternoon.

BigBlueButton vs Zoom, Teams, and Google Meet: What Changes When You Self-Host

For IT teams evaluating whether to install BigBlueButton or use a managed SaaS alternative, the comparison is less about features and more about operational control, data ownership, and total cost of ownership. The table below captures the key differences from an infrastructure and governance perspective.

BigBlueButton gives institutions full data sovereignty and purpose-built education features. The trade-off is the installation and operational commitment — which is precisely why managed BigBlueButton hosting exists as an alternative to self-hosting.

Self-Hosted vs Managed BigBlueButton: Choosing Your Installation Path

After completing a first-time install BigBlueButton walkthrough, many institutions revisit the decision to self-host versus use a managed provider. The comparison below covers the dimensions that matter most in a production educational environment.

For institutions without a dedicated Linux sysadmin on the team, managed hosting removes every item in the self-hosted column that has historically caused first-time install failures.

Server Requirements: Why Concurrent Users Is the Only Number That Matters

First-time BigBlueButton installers almost always ask the wrong sizing question: "We have 500 users — what server do we need?" The correct question is: "How many simultaneous BigBlueButton sessions will be active at your busiest moment?" Total user count is irrelevant. Peak concurrency drives every infrastructure decision.

Baseline server requirements for a BigBlueButton installation with recording enabled:

• Operating System: Ubuntu 20.04 LTS (Focal) or 22.04 LTS (Jammy) — 64-bit, dedicated or bare-metal recommended. BigBlueButton does not officially support other Linux distributions or containerised installs for production use.
• CPU: Minimum 8 dedicated vCPUs for a small production deployment. 16 vCPUs for institutions expecting 20–40 concurrent rooms. 32+ vCPUs for larger clusters. Avoid shared/burstable CPU instances — BigBlueButton media processing needs sustained CPU, not burst credits.
• RAM: 16 GB minimum; 32 GB recommended for comfortable production use with recording enabled. Recording post-processing is memory-intensive during peak hours.
• Disk: 50 GB minimum for the OS and application. Add storage for recordings separately — a 1-hour recorded session generates 200 MB to 800 MB depending on format. High-volume deployments need NFS, S3-compatible, or dedicated recording storage.
• Network: A static public IPv4 address is required. Gigabit network interface recommended. Symmetric bandwidth matters — plan for 30–50 Mbps per heavily loaded concurrent room.
• TURN server: Required separately (or on the same server for small deployments). Without TURN, users behind strict NAT or corporate firewalls will silently fail to connect WebRTC audio/video.
• Headroom: Never size for exactly your expected peak. Add at least 30–40% CPU and RAM headroom. Recording post-processing runs concurrently with live sessions and will consume the resources you thought you had spare.

WebRTC and TURN: The Networking Layer Every BigBlueButton Installer Must Understand

BigBlueButton uses WebRTC — the browser-native real-time communication protocol — for all audio, video, and screen-sharing. This means participants join sessions directly from their browser with no plugin required, but it also means your server must handle the WebRTC media routing, signalling, and relay infrastructure correctly. Getting this wrong is the single most common cause of "it works for me but not for them" audio/video problems after a fresh installation.

• SFU (Selective Forwarding Unit): BigBlueButton uses Kurento (older versions) or mediasoup (BBB 2.6+) as its SFU to route media streams between participants. The SFU runs on your server. More concurrent streams = more CPU consumed by the SFU. This is why CPU headroom at peak concurrency is non-negotiable.
• STUN/TURN: WebRTC first attempts a direct peer-to-peer connection (assisted by a STUN server). When that fails due to symmetric NAT or firewall rules — which is common in school networks, corporate environments, and home broadband with strict router settings — a TURN relay is required. Without TURN, affected users see a spinner and never connect audio or video. This failure is silent from the server's perspective, making it hard to diagnose post-install.
• coturn: The standard TURN server for BigBlueButton deployments. It can run on the BigBlueButton server itself (for small deployments) or on a separate VM (recommended for production). Must be configured with a valid TLS certificate and ideally accessible on port 443/TCP to traverse deep-packet inspection firewalls.
• Jitter and packet loss: WebRTC is UDP-based, which means it is sensitive to network jitter and packet loss. On a campus wired network, this is rarely an issue. On congested home broadband or mobile data, users will experience frozen frames and audio dropouts. Adaptive bitrate helps but does not eliminate the problem on very poor connections.
• FreeSWITCH audio: BigBlueButton uses FreeSWITCH for its audio conferencing layer. FreeSWITCH has its own SIP and WebRTC audio stack and must be correctly configured with your server's public IP. A missed step here causes one-way audio — a notorious first-time install pitfall.

Post-install WebRTC validation checklist: test audio join from both wired and WiFi connections; test from behind a corporate firewall; confirm TURN relay is used when direct connection fails; verify that webcam video flows in both directions; and confirm screen sharing works in Chrome, Firefox, and Edge before declaring the installation production-ready.

Security, TLS, and Governance for a Production BigBlueButton Installation

Security is not optional in a BigBlueButton deployment used by schools, universities, or any institution handling student data. The following areas must be addressed during and immediately after installation.

TLS / HTTPS

• BigBlueButton requires HTTPS on all endpoints. The bbb-install script can automate Let's Encrypt certificate issuance during installation — use the -s flag with your fully qualified domain name. Certificates must be renewed before expiry; Let's Encrypt certificates expire every 90 days. Automate renewal with a cron job or systemd timer and monitor for renewal failures.
• WSS (WebSocket Secure) is used for signalling. A lapsed or self-signed certificate will break WebSocket connections and prevent sessions from launching entirely.
• TURN server connections should use TLS on port 443 to traverse restrictive firewalls. Non-TLS TURN on UDP 3478 is blocked by many institutional firewalls.

OS and Application Hardening

• Disable root SSH login; use key-based authentication only. Restrict SSH to a non-standard port or VPN-only access if your network architecture allows it.
• Configure UFW (Uncomplicated Firewall) to allow only required ports: 80/TCP, 443/TCP, 443/UDP (TURN), and 16384–32768/UDP (RTP media). Close all other ports.
• Apply unattended-upgrades for OS security patches. Keep BigBlueButton application packages updated — run sudo apt update && sudo apt upgrade on a defined schedule and test in a staging environment before applying to production.

Recording Governance and Retention

• Define a recording retention policy before go-live. Recordings stored indefinitely create FERPA, GDPR, and institutional liability exposure. Implement automated deletion scripts for recordings older than your defined retention window (commonly 12–24 months).
• Control who can publish and unpublish recordings. By default, moderators can mark recordings as published or unpublished via the API or Greenlight front-end. Ensure this control is governed by your LTI role mapping.
• Enable and ship application logs to a centralised SIEM or log management system for audit trail purposes.

Review BiggerBluButton's data policies and security commitments: biggerbluebutton.com/terms-and-conditions

How to Enable and Use Recording on BigBlueButton After Installation

Recording on BigBlueButton must be explicitly enabled during or after installation — it is not active by default on a vanilla install. Here is the complete step-by-step process to configure and use BigBlueButton recording from your first session.

Step 1: Enable Recording in bbb-conf

By default, BigBlueButton allows recording but requires it to be enabled per-meeting at the API level. To allow recording from the Greenlight front-end or LTI integration, ensure that recording is set to allowed in your bigbluebutton.yml or passed as record=true in the API create call. Verify by running sudo bbb-conf --check after any configuration change.

Step 2: How to Record a BigBlueButton Meeting as a Moderator

1. Join the session as the moderator (instructor). Only moderators have access to recording controls — viewers and students do not see the Record button.
2. Click the red circular Record button in the top header bar of the BigBlueButton interface. A "Recording" label and red indicator will appear, confirming that recording with BigBlueButton is active.
3. To add a recording to a BigBlueButton conference after it has already started — for example, if you forgot at the beginning — simply click the Record button at any point during the session. Only content after that click is captured.
4. To stop the BigBlueButton recording mid-session, click the Record button again. This pauses the recording. Clicking again resumes and creates a new recording segment. To end recording entirely, end the meeting — BigBlueButton will automatically stop recording and initiate post-processing.
5. Post-processing converts raw captures into a web-playable format (Presentation, Video, Podcast, or Screenshare depending on configured formats). This process runs in the background and typically takes 30 minutes to 2 hours for a 1-hour session.
6. To access BigBlueButton recordings, moderators navigate to the Recordings section in Greenlight or the recordings tab in the LTI integration. Recordings appear here once post-processing completes.

Step 3: Recording Post-Processing and Disk Management

• Monitor disk usage in /var/bigbluebutton/recording/ — raw, process, publish, and published directories all consume space. A full disk silently aborts recording jobs.
• Configure only the recording formats you actually need. Each enabled format (presentation, video, podcast, screenshare) multiplies post-processing time and storage usage. Most institutions need only Presentation format.
• For saving recordings from BigBlueButton to external storage, configure the post_publish scripts to copy completed recordings to S3-compatible object storage or NFS — this extends your storage capacity without growing the server disk.

Recording Best Practices

• Always inform participants when recording is active — it is displayed on screen, but verbal notification is a legal requirement in many jurisdictions.
• BigBlueButton recording chat is included by default in Presentation format recordings. Remind participants that public chat is captured and will be visible in the playback.
• Set up monitoring alerts for recording post-processing failures — failed jobs do not alert by default. Check /var/log/bigbluebutton/ logs regularly or ship them to a log aggregation tool.

For a full overview of BigBlueButton recording formats and features: biggerbluebutton.com/features

Canvas BigBlueButton Recording: Making Your Recordings Available to Students in Canvas

Once BigBlueButton is installed and recording is working, the next step for most institutions is connecting it to Canvas via LTI so that recordings appear automatically inside course pages. Canvas BigBlueButton recording access works differently depending on how the integration is configured — here are the three main methods.

Method 1: LTI Integration (Recommended for Canvas)

When BigBlueButton is integrated into Canvas via LTI 1.3 (or 1.1), recordings from LTI-launched sessions are automatically tied to the Canvas course context. After post-processing completes:

1. Instructors and students open the BigBlueButton LTI activity inside the Canvas course.
2. The Recordings tab inside the LTI tool lists all completed recordings for that course — students can view and listen to BigBlueButton recordings here without any additional login.
3. Recording access is automatically scoped to enrolled students — unenrolled users cannot access the recordings even if they have a direct link.

Method 2: Sharing a Recording Link Manually in Canvas

For sharing a recording from BigBlueButton to Canvas without LTI:

1. In Greenlight or the BigBlueButton admin interface, navigate to the completed recording and copy its playback URL.
2. Paste the URL into a Canvas Page, Announcement, or Module as an External URL item. Students click the link to open the BigBlueButton recording player in their browser.
3. To send a BigBlueButton video recording to a specific Canvas assignment, embed the URL in the assignment description or as a submission link. Note that recording visibility on the BBB server must be set to "published" for the link to be accessible.

Method 3: Governed Media Library via API or Post-Publish Script

For institutions managing large volumes of BigBlueButton canvas recordings across many courses:

1. Use a BigBlueButton post-publish hook or the recordings API to push completed recordings to a centrally managed media library (Kaltura, Panopto, or a custom S3-backed solution).
2. Generate Canvas-compatible embed codes or LTI deep links from the media library and place them into the appropriate Canvas course modules.
3. This approach provides a single inventory of all recordings across all courses with centralised retention control, access auditing, and FERPA-compliant storage management.

Recommended Resources for BigBlueButton Installation and Hosting

The following resources from BiggerBluButton will help you scope, configure, and support your BigBlueButton deployment — whether you are installing from scratch or evaluating managed hosting as an alternative.

• Compare managed BigBlueButton hosting plans and capacity tiers — find a plan sized for your peak concurrent session count, with recording storage included.
• Explore BigBlueButton features including recording, LTI, and branding options — full feature list for IT evaluators and procurement teams.
• Read BiggerBluButton's installation guides, API documentation, and configuration references — including LTI setup, Scalelite, TURN configuration, and recording post-processing.
• Contact our infrastructure and installation specialists — get expert guidance on sizing, TURN configuration, Scalelite setup, or migrating from a self-hosted deployment.
• Review our terms, data governance, and security policies — relevant for procurement, legal review, and FERPA/GDPR compliance documentation.
• Read more BigBlueButton tutorials, how-to guides, and best practices on our blog — covering installation, recording workflows, Canvas LTI setup, performance tuning, and monitoring.

Frequently Asked Questions: BigBlueButton Installation, Recording, and First-Time Setup

Ready to Skip the Hard Parts of BigBlueButton Installation?

Get a fully installed, configured, and production-ready BigBlueButton environment — with TURN, TLS, recording storage, monitoring, and LTI integration already handled. Your IT team focuses on education, not server maintenance.