Today's Deep-Dive: PILOS

Welcome back to The Deep Dive. Today we're looking at something a little different.

It's not just a

piece of software, but really an architectural solution that was born out of a

crisis.

We're going to be unpacking an essential open source platform, a kind of digital

front end,

that was specifically designed to handle the immense chaos of scaling a university

classroom

during a global pandemic. Our mission today is to really get a handle on how this

platform makes

life so much better for institutions that are trying to manage huge numbers of

users all at once,

especially if they're relying on Big Blue Button. But first, a quick word on why

all this matters,

why stability and a solid architecture are so key. This Deep Dive is supported by

Safe Server. Safe

Server focuses on hosting complex open source software, exactly the kind of tools

we're discussing

today, and they really support clients on their digital transformation journey. So

if you need

powerful hosting that just works, you can find out more about how they do all the

heavy lifting at

www.safeserver.de. Right. So the core subject today is Pylos. It's an acronym for

platform for

interactive live online seminars. And if you're new to this whole space, the

easiest way to think

about Pylos is this. It's a modern, very easy to use open source front end. It's

designed to sit

right on top of your Big Blue Button or BBB server setup. So it's the nice looking

website, the

dashboard, basically the user friendly part that students and teachers actually log

into. Exactly.

It's built on top of that powerful but sometimes complicated engine underneath. And

what makes it

so special? Well, what makes Pylos instantly relevant for say a big university

deployment

is that it brings a massive piece of enterprise level functionality right out of

the box. Okay.

A built-in load balancer. Ah, the load balancer. That really is the star feature

here. But before

we get into the mechanics of that, let's get the origin story. The source material

is very clear.

This wasn't some commercial product. No, not at all. It was born from pure

necessity. Pylos

started at the TeachMiddleHessin University of Applied Sciences, specifically in

their faculty

of health. So not even the main IT department. Right. And that's important. This

was a faculty

that was deeply affected by the sudden shift to remote learning in 2020. They

needed a custom

solution for their specific problems, digital classrooms, secure group work, and

running these

huge online seminars without everything crashing. I think we all remember those

days in 2020,

just scrambling to find any platform that could handle that sudden surge in users.

Most of the tools out there, even the open source ones, just felt like they were

held together with,

I don't know, duct tape and good intentions. And that experience, that constant

frustration with

crashes, with missing features, with the difficulty of getting things to work, that

was the direct

catalyst for Pylos. They just needed a modern, flexible system that was actually

built for an

academic environment. So let's transition a bit into that core relationship. We've

said Pylos is

the front end, the body of the car, so to speak. What exactly is Big Blue Button,

the engine, doing?

So Big Blue Button is the underlying heavy duty open source web conferencing system.

It's what's

actually handling all the functionality. Like the video streaming, the whiteboards.

Exactly. The video

encoding, shared whiteboards, breakout rooms, all the recording capabilities, all

the real-time stuff.

Pylos just tells it what to do. I see. And a really crucial point here, which they

emphasize

in their documentation, is that while Pylos uses BBB, it's not endorsed or

certified by Big Blue

Button Inc. It's a completely independent specialized wrapper around it. A

customized wrapper

built for a university's unique needs. And this brings us to that big pivot point.

Yeah. Because

there's another well-known front end for BBB, right? Greenlight. Yes, exactly.

Greenlight is

a very functional, widely used project. So the critical question is, why? Why did

the team at

THM spend all the time and resources to build Pylos from the ground up? Why not

just, you know,

fork Greenlight and add the features they wanted? And that's really the core of

this whole deep dive.

If open source is about collaboration, why start over? The sources seem to put the

blame

squarely on one thing. Architecture. They're very direct about it. During that

really intense 2020

online semester, a lot of crucial features they needed were either exceptionally

difficult or

just unsolvable within the Greenlight framework. Unsolvable. That's a strong word.

It is. And the

difficulty wasn't about the skill of the developers. It was about Greenlight's

fundamental

architectural choice. It was built on Ruby on Rails. Okay, so for anyone listening

who's a bit

more on the technical side, can you elaborate on that? Why would a Ruby on Rails

foundation be such

a roadblock for a system like this? Well, Ruby on Rails can be fantastic for

building apps quickly,

especially things that are pretty predictable and synchronous. Think of like a

standard website or

some admin forms, but a massive video conferencing system, especially one that has

to dynamically

manage a whole pool of load balance servers, needs extreme asynchronous handling.

You have

thousands of users, all starting sessions, checking server capacity, updating lists,

all at the same time. So the architecture of Rails, which is more monolithic, more

synchronous,

it just started fighting against the chaotic high concurrency needs of a live

teaching platform.

That's a perfect way to put it. They ran into what we call architectural friction

to build a dynamic API driven load balancing system, which needs constant server

health

checks and routing sessions on the fly. They realized it was just too complex to

force that

into a traditional Rails structure. So it was actually easier to start over. The

cost of

starting fresh with a modern decoupled architecture was actually lower than trying

to force the old

one to work. Which brings us back to that essential feature, the load balancer. And

this is where

Pylus really shines. This isn't just a simple round robin load balancer, you know,

you go to server A,

you go to server B. With streaming video, it's not that simple. Right, because once

you're in a meeting,

you have to stay on that specific server session persistence. Absolutely mandatory.

So the Pylus

load balancer sitting on the front end, it uses the big blue button API to check

the real time

capacity and health of the entire pool of servers before it ever routes a user to a

room. So it

prevents those cascading failures you'd see when an institution just pushed too

many people onto one

single BBB server. That stability is the huge payoff for that big architectural

overhaul. Okay,

that shifts us perfectly from the why to the how. If Ruby on Rails was the problem,

what is this new

flexible architecture they chose? Let's break down the four main components, the

stacks that make up

Pylus. Right, so we'll start with the obvious one. Component one is big blue button.

It's still the

indispensable engine, the core conferencing system. Understood. So what did they

choose to replace

Rails with for the main foundation? That would be Laravel. Laravel is a very

powerful expressive PHP

web framework. They chose it specifically to build the backend JSON API. So when

the source material

talks about its expressive, elegant syntax, what does that mean in practical terms?

It's basically

developer speak for saying it makes building complex scalable APIs a lot simpler

and faster

than what they were dealing with before. It lets you have that clean separation

between the backend

logic and the front end display. So Laravel is... That's component number three.

View. View is the

JavaScript framework they used for building the user interface. So the clean

dashboard, the room

creation pop-ups, the settings pages, that's all view. So by using view, the front

end can be

updated and maintained completely independently from the Laravel backend. A huge

amount of

flexibility compared to a monolithic system where the UI and the backend are all

tangled together.

And this decouple architecture Laravel for the backend, view for the front end,

that is the direct answer to the problems they had with Greenlight. It's the whole

point of the

project. And then there's one final piece, the translation layer. They needed a

reliable way

for this new Laravel API to talk to the big blue button engine. The translator,

what is it? It's

the fourth component, a library called Littler Button, big blue button, A-B-E-P. It's

basically

a specialized, unofficial PHP API wrapper. Okay. It translates the commands from

pilots like create

a meeting or what's the server status into a format that the BBB engine understands.

And then

it translates the responses back. It closes the loop. That makes the whole stack

incredibly clear.

And looking at the technical snapshot, the code is about 80% PHP and 19% view.

That heavy reliance on PHP and Laravel, it suggests something about the original

developers,

doesn't it? But it does. It signals that the internal expertise at the university

was likely

very strong in the PHP ecosystem. You could argue for using other languages like

Node or Go for this

kind of thing, but choosing Laravel was a pragmatic choice. Right. It balanced the

need for a modern

architecture, which it delivers, with the need to use the skills they already had

to get a solution

built quickly. You have to remember, this was an emergency. And for other

institutions looking to

actually use this, the docs mentioned Docker images are available. For a university

IT department,

why is that so critical? Docker just simplifies complexity enormously. University

IT systems can

be a total mess. Different operating systems, weird security rules. Docker packages

the entire

application and all its dependencies into one standard unit. So an admin can deploy

it reliably

no matter what their server environment looks like. Exactly. It radically cuts down

on installation

time and configuration errors. It's really the gold standard for this kind of

institutional deployment.

It definitely speaks to the maturity of the project, which brings us to our final

section,

the open source spirit and the community health of Pylos. It's a healthy project.

It's licensed

under the LGPL 2.1 license, which encourages people to use it. And the metrics show

solid

engagement. You see about 60 stars, 26 forks on GitHub, which shows developers are

actively

interested. They're playing with the code. And for a tool designed for education,

which is

obviously global, localization must be a huge focus. It absolutely is. And they

handle that

through a service called the PO Editor Project. They actively use it to call for

collaboration,

inviting people from all over to help contribute translations. It's a great way to

make sure the

platform works across language barriers. So if you're an Ikey director at an

institution

and you're looking at this platform, what are the practical steps available to

actually

implement it? They've provided really excellent detailed guides. You have the

standard installation

instructions, of course. But crucially, they also have an upgrade guide for moving

from older

versions. And maybe most importantly, they offer a specific migration guide for any

institution

that's currently running Greenlight 2. That migration guide is, that's the ultimate

sign

they know their audience. They're basically confirming, we know you hit the same

architectural

wall we did, and here's the way out. It offers a clear, documented path to

architectural stability.

And all the collaborative spaces are wide open, too. The GitHub repo is really well

organized,

with sections for code, issues, discussions, a security policy. It's all there.

This is a

platform built for long-term community support. So if you step back and look at the

whole journey,

PyLas wasn't some theoretical project. It was a knowledge product born from the

immediate,

urgent need of a university during a crisis. Its main purpose was to solve the

architectural

friction they found in a monolithic system like Greenlight. And the result was this

modern,

flexible platform based on Laravel and Vue. Right. One robust enough to handle the

sheer

complexity of large-scale digital education today. It's a really inspiring example

of

how solving an internal problem with intelligence can lead to a tool that's

valuable for everyone.

It shows the power of making the right foundational choices, even if it means doing

the hard work of a

complete rewrite. And that leads us to our final thought. Since Pylos was founded

purely because

an underlying architecture, the Ruby on Rails and Greenlight, was creating roadblocks

that limited

innovation. I want you to think about how often foundational technology choices

maybe made years

ago in your own organization are dictating the limits of what you can do today. Is

your legacy

system enabling flexibility, or is it silently telling you what you can and cannot

build next?

It's a really compelling thought to explore. It absolutely is a fantastic thought

to end on.

And if you are facing those kinds of architectural roadblocks, or you just need

rock solid hosting

for powerful open source solutions like Pylos, remember that Safe Server cares

about your hosting

and your digital transformation needs. You can find out how they can support you in

building robust

scalable solutions at www.safeserver.de. Thank you for joining us for this deep

the architecture of modern digital learning. We'll catch you next time.

the architecture of modern digital learning. We'll catch you next time.