Self-Hosted BigBlueButton: planning, cost, deployment options.
A practical planning reference for IT teams, LMS administrators, and decision makers evaluating whether to run BigBlueButton on their own infrastructure or use our managed BigBlueButton hosting.
Planning Scope
What you can evaluate
What is self-hosted BigBlueButton?
Self-hosting means deploying the open-source BigBlueButton stack on servers you control, then operating the real-time WebRTC, recording, security, and integration layers yourself.
Choose self-hosting when your team can operate it
A reliable BigBlueButton environment needs Linux maintenance, WebRTC troubleshooting, backups, firewall reviews, monitoring, and controlled version upgrades.
Keep infrastructure inside your control
Teams with strict regional, institutional, or internal network requirements may prefer servers and recordings inside their own infrastructure boundary.
Use managed hosting when continuity matters
If your team cannot actively operate CoTURN, Nginx, FreeSWITCH, recording workers, and cloud networking, dedicated managed infrastructure usually reduces operational risk.
What you need before installing BigBlueButton
BigBlueButton combines browser permissions, real-time media, TURN relay paths, recording workers, and system-level services. Confirm these requirements before you commit to a rollout.
Operating system and compute
Use supported Ubuntu LTS releases for the BigBlueButton version you deploy. Production nodes should use dedicated CPU resources, not burst-only instances.
Public hostname and TLS
Browsers require HTTPS for microphone, webcam, and screenshare permissions. Plan a public FQDN, valid DNS, and automated certificate renewal.
Firewall and media ports
Expose HTTP/HTTPS for web traffic and the WebRTC media UDP range required by your BBB version. Test with real client networks, not only server-side port scans.
TURN/STUN path
CoTURN helps clients behind restrictive NATs and corporate firewalls connect reliably. Standalone deployments can use local CoTURN; clusters should usually separate it.
Sizing guide for production planning
Use this as a planning baseline, then validate with real class formats, recording policy, webcams, and client networks.
| Deployment Scale | CPU | RAM | Disk | Bandwidth | Capacity Planning |
|---|---|---|---|---|---|
| Development / Test | 4 physical cores or 8 vCPU | 8 GB | 30 GB SSD | 250 Mbps | Small tests only |
| Production Standard | 8 physical cores or 16 vCPU | 16 GB | 50-100 GB SSD/NVMe | 1 Gbps | Up to 120 load units |
| Production High Load | 16 physical cores or 32 vCPU | 32 GB | 150 GB SSD/NVMe | 1-2 Gbps | 121-200 load units |
| Scalelite Cluster | Multiple BBB nodes | Per node | Shared recording storage | Multiple 1 Gbps+ uplinks | More than 200 load units |
Example deployment sizes and monthly cloud costs
These reference profiles help you translate expected attendance into realistic server sizes, bandwidth needs, and cloud cost exposure.
| Target Users | Meeting Format | Recommended Hardware | Example Cloud Instance | Estimated Bandwidth |
|---|---|---|---|---|
| 100 | Standard Classes (2-4 webcams) | 8 cores, 16 GB RAM, 100 GB SSD | AWS c6i.2xlarge / DigitalOcean 8-Core Dedicated | 1 Gbps port |
| 250 | Mid-Scale Webinars (5-10 cams) | 16 cores, 32 GB RAM, 200 GB SSD | AWS c6i.4xlarge / DigitalOcean 16-Core Dedicated | 1 Gbps port |
| 500 | Distributed LMS (multiple rooms) | 2x node cluster (8-core nodes) + 1x Scalelite LB | 2x DigitalOcean Dedicated CPU 8-Core Nodes | 2x 1 Gbps ports |
| 1000 | High-Load University (standard peak) | 4x node cluster + 1x Scalelite LB + 1x shared storage | 4x DigitalOcean Dedicated CPU 8-Core Nodes | 4x 1 Gbps ports |
Sample Monthly Cloud Bill
Example monthly bill: 250 concurrent users
Compute is only one part of the self-hosted budget. Bandwidth, recordings, TURN relay traffic, and operations work can change the real monthly cost.
Estimated Total
$854.00 / mo
AWS infrastructure estimate
| Cost Item | Assumption | Monthly Cost |
|---|---|---|
| Compute Node | c6i.4xlarge - 16 cores, 32 GB RAM | $340.00 / mo |
| Storage Volume | 200 GB gp3 SSD + snapshot backups | $28.00 / mo |
| Network Egress | Approx. 5 TB outbound data | $450.00 / mo |
| Dedicated TURN VM | t3.medium + Elastic IP | $36.00 / mo |
| Estimated AWS infrastructure total | $854.00 / mo | |
Costs to verify before launch
Bandwidth egress
Live classes can move several TB per month. Confirm included transfer and overage rates before choosing a provider.
Recording storage
Plan for raw recording space, processed playback files, snapshots, backups, and retention policy.
TURN relay traffic
Users behind restrictive networks may relay media through TURN, increasing bandwidth and server pressure.
Operations effort
Include monitoring, updates, incident response, certificate renewals, backup checks, and upgrade testing.
Typical BigBlueButton deployment models
Choose the smallest architecture that reliably satisfies concurrency, firewall, recording, and uptime requirements.
Option 1
Standalone Standard
BBB, Nginx, FreeSWITCH, Greenlight, recordings, and local CoTURN on one optimized node.
Option 2
Distributed Standalone
A primary BBB node with a separate public TURN relay for stricter client networks.
Option 3
Distributed Cluster
Scalelite fronts multiple BBB nodes with shared recording storage, Redis, and PostgreSQL to reduce dependence on a single BBB node.
| Compare | Standalone Standard | Distributed Standalone | Distributed Cluster |
|---|---|---|---|
| Best for | Small schools, pilots, and controlled production deployments. | Organizations with many corporate-firewall users or regional network constraints. | Large LMS deployments, multi-campus programs, and high concurrency. |
| Typical scale | Small teams, pilots, and modest class schedules | Medium deployments with stricter client networks | Large institutions, multi-campus LMS use, and high concurrency |
| Key services | BBB, Nginx, FreeSWITCH, Greenlight, local CoTURN | BBB node, dedicated TURN relay, optional external storage | Scalelite, multiple BBB nodes, Redis, PostgreSQL, shared storage |
| Recording storage | Stored and processed on the same BBB node | Local or external storage depending on retention needs | Shared storage or object-storage sync behind one endpoint |
| Operational complexity | Low | Medium | High |
| Upgrade path | Add external storage or a dedicated TURN relay as usage grows | Move to Scalelite when concurrency exceeds one node | Add BBB nodes and storage capacity as demand increases |
Planning details that protect live classes
Use these checks to reduce avoidable outages, recording failures, bandwidth surprises, and upgrade risks after launch.
Risks to avoid before launch
- Using burstable virtual machines for production classes, then hitting CPU credit or noisy-neighbor throttling during peak meetings.
- Placing a TURN server behind NAT without a stable public IPv4 path for relay traffic.
- Leaving file descriptor limits, Nginx workers, and FreeSWITCH capacity at defaults for high-concurrency use.
Costs beyond the server
- Cloud egress can exceed compute spend when many viewers receive audio, webcam, and screenshare streams.
- Maintenance labor includes security patching, certificate renewal failures, monitoring, incident response, and upgrade rehearsals.
- Recording retention requires raw recording buffer space, processed archive storage, and backup/object storage costs.
Recording storage strategy
- Raw recordings are staged separately before processing; keep enough temporary room for delayed or failed processing jobs.
- Published recordings grow with session hours, webcam count, uploaded presentations, and retention period.
- For clusters, use shared storage or object-storage sync so recordings remain available from a single endpoint.
Bandwidth planning
- Audio commonly sits around tens of Kbps per participant, while each active webcam and screenshare stream multiplies server egress.
- A practical formula is: viewers x (audio stream + active webcams x webcam bitrate + screenshare bitrate).
- Model peak class hours separately from monthly transfer; both matter for port speed and billing.
Update and upgrade planning
- Apply minor package updates on a scheduled maintenance window after snapshotting or backing up key state.
- Treat major version changes as migrations: review OS support, Greenlight compatibility, recordings, and rollback steps.
- Run a staging upgrade when the server is tied to a production LMS calendar.
Security checklist
- Disable demo endpoints and restrict access to internal Redis, PostgreSQL, and administrative services.
- Keep TLS certificates current and avoid exposing database or monitoring ports publicly.
- Review API secret handling, firewall rules, SSH access, backups, and recording retention policy.
Health monitoring
- Track CPU, memory, disk, active meetings, active users, recording processing backlog, and packet-loss indicators.
- Use Prometheus/Grafana style dashboards for trend visibility and alert before CPU or disk pressure becomes a classroom outage.
- Log WebRTC connection errors to spot firewall/TURN issues affecting specific networks.
Backup and recovery
- Back up Greenlight configuration, database state, API secrets, certificates, and customized Nginx/BBB configuration.
- Sync processed recordings to external storage without interrupting active meetings.
- Test restores periodically; an untested backup is only a hopeful copy.
TURN and STUN connectivity
- STUN helps a browser discover how it appears on the public internet.
- TURN relays media when direct UDP traffic cannot pass through local or corporate firewalls.
- Routing TURN over TCP/TLS 443 can help users on restrictive networks, but relay traffic increases bandwidth demand.
Scalelite load balancing
- Scalelite presents one API endpoint to Moodle, Canvas, WordPress, or custom applications.
- It assigns new meetings to available BBB nodes based on load while keeping integrations simple.
- It improves capacity planning, but it does not move active meetings during a node failure; design expectations accordingly.
Self-Hosted Cost and Sizing Calculator
Enter your expected meeting usage to estimate server capacity, bandwidth, storage, and monthly operating cost.
1. Usage Profile
Adjust sliders to define meeting metrics.
The maximum number of sessions running at the exact same moment.
Enable Meeting Recording
Estimate storage based on recording volume.
Processed recordings are stored and billed based on this retention window.
2. Infrastructure Setup
Select your target cloud environment.
Operations Time and Cost
Include maintenance effort so the estimate reflects total monthly ownership cost.
Recommended Sizing Specification
Recommended infrastructure specs based on stream volume.
Node Specification
1x Nodes (8 Cores / 16 GB)
Target Storage
242 GB SSD Disk
Expected Monthly TCO
Breakdown of server infrastructure and labor.
Network Usage Insights
Managed Hosting Alternative
Premium 120 Users Plan
Session Routing: Group Session
Starts from
€175/mo
Export Planning Results
Copy a permalink or open a print-ready report that can be saved as PDF.
Cost assumption: Estimates are based on publicly available cloud provider lists (as of Q2 2026) and baseline BBB configurations. Actual rates vary by geography, negotiated discounts, media settings, and usage patterns. Run load testing before finalizing a production deployment.
BigBlueButton® is a registered trademark of BigBlueButton Inc.
BigBlueButton Deployment Advisor
Answer six quick questions to discover whether self-hosting or Managed BigBlueButton hosting, best fits your technical and operational requirements.
What is the primary stage of your BigBlueButton project?
Helps determine if you need immediate production-grade SLA or a low-cost testing sandbox.
Self-managed vs. dedicated managed hosting
Compare the day-to-day responsibilities, cost behavior, and risk profile before deciding whether to operate BigBlueButton internally or use a dedicated managed service.
Self-managed
Your team owns the operating path
Best when you want direct control and have internal Linux, WebRTC, networking, and incident response capacity.
Dedicated managed hosting
BigBlueButton.Host operates with you
Best when you want dedicated BBB infrastructure with deployment, monitoring, maintenance, tuning, and capacity review handled as a service.
| Decision Area | Self-managed | Dedicated managed hosting |
|---|---|---|
| Infrastructure ownership | Your cloud, bare-metal account, network, DNS, TLS, and server access. | Dedicated infrastructure provisioned for your organization and workload. |
| Daily operations | Your team monitors, patches, upgrades, tunes, and responds to incidents. | BigBlueButton.Host operates deployment, monitoring, maintenance, tuning, and capacity review. |
| Cost behavior | Compute, egress, storage, monitoring, backups, and labor can vary month to month. | Plan-based pricing with fewer bandwidth surprises and less internal operations time. |
| Continuity expectations | Continuity depends on your internal runbooks, monitoring, backup tests, and response coverage. | Operational coverage is included; premium SLA and recovery options depend on selected plan or add-ons. |
| Best fit | Teams with strong Linux, WebRTC, networking, and incident response capacity. | Teams that want dedicated BBB infrastructure without carrying routine operations internally. |
Decision guide: choose self-managed if your team has Linux/WebRTC operations capacity. Choose managed if you want dedicated BBB infrastructure with routine operations handled by BigBlueButton.Host.
Self-Hosted BigBlueButton Server Setup
Choose the service path that matches your next step: a standalone installation, a scalable cluster rollout, or a technical architecture review.
Standalone Setup
Best for
Single production BBB server
Includes
Cluster Setup
Best for
Multi-node or higher capacity deployments
Includes
Architecture Review
Best for
Teams validating an existing or planned deployment
Includes
Self-hosted BigBlueButton questions
Answers for infrastructure, networking, cloud costs, recordings, scaling, security, upgrades, and LMS integrations.