# Greenlight: a front door for BigBlueButton servers

> Greenlight is the open-source web application that sits in front of a BigBlueButton server, giving non-technical staff a browser-based way to create meeting rooms, share links and record sessions without touching the server configuration. Version 3 is a Ruby on Rails and React application with its own PostgreSQL and Redis dependencies, built and published as a container image.

**bigbluebutton/greenlight** — A really simple end-user interface for your BigBlueButton server.

- Repository: https://github.com/bigbluebutton/greenlight
- Stars: 851 · Forks: 3,650
- Language: Ruby
- License: LGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/bigbluebutton-greenlight

## What the project is and what it is not

Greenlight is an open-source, LGPL-3.0 licensed web application that allows organizations to quickly set up a complete web conferencing platform using their existing BigBlueButton server. The phrase that matters is existing. Greenlight does not carry the audio and video media path, it manages it. It is the layer between a person who wants to host a meeting and a BigBlueButton deployment that is not designed to be poked at directly by non-technical staff. The README describes it as user-friendly for both regular and advanced users, and the project description as a really simple end-user interface for your BigBlueButton server. So the value proposition is administrative rather than technical: room creation, links, recordings and configuration, exposed through a browser to people who would not otherwise be given shell access.

## Version 3 is a Rails and React rewrite

Greenlight v3 is the latest version, and it is constructed with recent versions of Ruby on Rails and React. The package manifest shows the JavaScript half of that stack in detail. React 17 with react-dom 17, react-router-dom 6 for routing, react-query for server state, react-hook-form with yup for validation, Bootstrap 5 with react-bootstrap 2 and semantic-ui-react alongside, i18next with react-i18next and an HTTP backend for translations, and axios for requests. The Rails side is implied by the repository layout and the Dockerfile, which uses Ruby 3.3.6 on Alpine 3.20. Greenlight v3 is the latest version, so anyone upgrading from an earlier deployment should expect to follow a migration rather than an in-place update.

## What the compose file expects

The compose file is short and shows the three-service shape of a deployment.

```yaml
services:
  postgres:
    image: postgres:14-alpine3.20
    container_name: postgres
    restart: unless-stopped
    volumes:
      - ./data/postgres/14/database_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=
```

There is a Redis service with the same restart policy and a persistent volume, and the application service itself, which takes its configuration from a .env file, binds only the loopback address on the host at port 5050 and maps it to port 3000 in the container, and depends on both Postgres and Redis. The application service also mounts a storage volume for the Rails application and configures a logging driver that defaults to journald. Binding to loopback is the important detail: the compose file does not expose the service to your network, which means you put a reverse proxy in front of it, and the presence of greenlight-v3.nginx in the repository root is the configuration that does that.

## The container image and what it expects of you

The Dockerfile has a base stage and then a build stage and a production stage. The base is ruby:3.3.6-alpine3.20 with a set of arguments that configure the environment: RAILS_ROOT, RAILS_ENV defaulting to production, NODE_ENV, PORT defaulting to 3000, and flags for logging to standard output and serving static files, both defaulting to true. The build stage installs the Ruby dependencies with the development and test groups excluded, and the production stage copies that vendor directory across, installs the node packages with a frozen lockfile, copies the application in and upgrades the base packages. The runtime package list tells you what the application needs beyond Ruby and Node: the PostgreSQL client and its headers, tzdata, imagemagick, yarn, bash, jpeg development files and glib. That list is a decent summary of what Greenlight does with files, since imagemagick is there for image processing.

## The details in the repository that are easy to miss

Several files in the root tell you more about how the project is operated than the README does. There is a keycloak.nginx alongside the greenlight-v3.nginx, which suggests the application can sit behind Keycloak for single sign-on. There is a docker-compose.kc.yml, a variant of the compose file that presumably wires in that path. There is a Procfile.dev and a Dockerfile.dev for running the application directly during development, and an esbuild.mjs with a development counterpart, which is the JavaScript build, since the package manifest scripts run node esbuild.mjs to build and esbuild.dev.mjs with a watch flag for development. There is a transifex.yml, so the translations are managed on Transifex rather than in the repository, and a sample.env for the configuration. The .licenserc.yaml is for automated licence header checking, and there is a Rakefile, a .rspec file and a spec directory for the Ruby tests.

## Installation, the demo and how to contribute

Installation and configuration are documented off the repository, with the BigBlueButton docs linked for installing and configuring Greenlight v3,. There is a demo server linked from the README, so you can click through the interface before installing anything, which is the sensible order for an application whose whole job is its interface. For contributions, the project has a pull request template that must be used for all pull requests, on the stated grounds that it helps the maintainers review them in a timely manner, and the README asks that as much information as possible be provided. Questions and feedback go to the Greenlight mailing list rather than to the issue tracker, and there is a security file at the repository root for reporting vulnerabilities.

## Where Greenlight is the wrong choice

Four limits apply. It depends on BigBlueButton being there already, so it is not a conferencing platform you can deploy on its own, and the scale of what you end up operating is the sum of both projects rather than either. The v3 rewrite means the upgrade path from a Greenlight 2 deployment is a migration rather than an in-place update, and the compose file and container image in the repository are tied to the v3 line, so a mixed fleet is a configuration problem you inherit. The application is a Rails app with a React frontend, which is a stack of considerable weight for what some organisations want from a link generator for a small number of rooms. And the licensing is layered: Greenlight is LGPL-3.0 while the BigBlueButton components it drives have their own terms, so a deployment that mixes them inherits obligations from both rather than one.

## Conclusion

Use Greenlight when you already run BigBlueButton and want people to create and join rooms without server access, because that is the gap this project fills and nothing else. Do not treat it as a conferencing server in its own right, since it is the interface layer and the media still runs on BigBlueButton. Verify first which version you are deploying, since the v3 line is a rewrite on current Rails and React while the compose file and container image in the repository are v3 specific, that your reverse proxy and TLS setup match the port the container exposes, and that the licence terms fit, since Greenlight is LGPL-3.0 while the surrounding BigBlueButton components have their own terms.

## FAQ

### What is Greenlight?

It is an open-source, LGPL-3.0 licensed web application that lets organizations set up a web conferencing platform using their existing BigBlueButton server. It provides the end-user interface for creating and managing rooms, and is described as user-friendly for both regular and advanced users.

### What does Greenlight v3 need to run?

The compose file defines three services: PostgreSQL, Redis and the application, which reads its configuration from an .env file and exposes port 3000 in the container, bound to loopback on the host. The image is Ruby 3.3.6 on Alpine with the PostgreSQL client, tzdata, imagemagick, yarn, bash and glib added at runtime.

### Which front-end stack does Greenlight v3 use?

React 17 with react-dom, react-router-dom for routing, react-query for server state, react-hook-form with yup for validation, Bootstrap 5 and react-bootstrap alongside semantic-ui-react, i18next for translations and axios for requests. The Ruby side runs on Rails, and the JavaScript is built with esbuild.

### How do I install Greenlight v3?

The README points to the BigBlueButton documentation for installing and configuring Greenlight v3, and there is a linked demo server you can try before installing anything. The repository also ships a compose file, a Dockerfile and nginx configuration for a reverse proxy in front of the application.

### How do I contribute to Greenlight?

The project has a pull request template that must be used for all pull requests, to help the maintainers review them in a timely manner, and asks that as much information as possible be provided. Questions and suggestions go to the Greenlight mailing list, and there is a security file for reporting vulnerabilities.

## Sources

- [bigbluebutton/greenlight on GitHub](https://github.com/bigbluebutton/greenlight)
- [Issues](https://github.com/bigbluebutton/greenlight/issues)
- [License: LGPL-3.0](https://github.com/bigbluebutton/greenlight/blob/master/LICENSE)
- [README](https://github.com/bigbluebutton/greenlight/blob/master/README.md)
- [Releases](https://github.com/bigbluebutton/greenlight/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bigbluebutton-greenlight