chamilo/chamilo-lms: a major PHP release with a 40 million user claim and no load test

A 3.0 release three weeks old, sitting next to a 40 million user claim

The scale claim and the release date are both in the readme, and they sit oddly next to each other. The project says it has been used by more than forty million people worldwide since it started in 2010. The release history shows a beta in mid-August 2026, a 1.0-equivalent major in early September, and a patch release ten days later that also carries the last commit to the default branch. So the version everybody is running today has existed for a matter of weeks.

Between those two facts the readme puts the sentence that decides how to read the rest of the document. The minimum hardware requirement is two virtual CPUs, four gigabytes of memory and four gigabytes of free disk, and immediately after it comes the qualification: the system was tested on a smaller machine and works, but building the development environment needs more memory than that, and at this stage no load testing has been done to work out how many users could use the system at the same time.

That is a rare admission, and it is more useful than a benchmark would have been. A published concurrency figure would tell you one number on one configuration on one day. What the sentence actually tells you is that the project's own maintainers do not claim a capacity figure, which means the number you would get from a vendor or a hosting provider is their extrapolation rather than the project's measurement. For a platform whose business is running training for thousands of people at once, that is the single most important line in the documentation, and the fact that it appears unprompted rather than in a footnote is a good sign about the project's honesty.

The rest of the minimum requirements are more prescriptive. The client side needs any recent computer and a browser no older than five years, which is a generous definition of recent and a sensible one for a system whose users are often on whatever hardware a training provider issued years ago.

The virtualhost requirement is the constraint that trips up new installations

The software stack requirements are three lines and the middle one causes most of the trouble. You need a web server with a virtualhost on its own domain or subdomain, and the readme is explicit that a subfolder inside a domain shared with another application is not supported. You need PHP 8.3, 8.4 or 8.5. You need MariaDB 10 or higher, or MySQL 5.7 or higher.

The subfolder restriction is the one to internalise before you start, because it is invisible until something breaks. A system that assumes it owns the root of a hostname will generate absolute URLs, will set cookie paths without a prefix, and will resolve asset paths relative to the site root, and every one of those works perfectly in development on a dedicated host and fails on a shared one. Discovering this after building a course catalogue is expensive, which is why the requirement is stated in the software stack section rather than buried in a troubleshooting page.

The installation instructions themselves are Ubuntu specific and written for a fresh server, and they begin by installing the web server, the database and a long list of PHP extension packages, which is a useful inventory of what the application actually needs:

sudo apt update && sudo apt -y upgrade
sudo apt install -y apache2 libapache2-mod-php mariadb-client mariadb-server php-{apcu,bcmath,cli,curl,dev,gd,intl,ldap,mbstring,mysql,redis,soap,xml,zip} unzip curl
sudo mysql -e "CREATE USER chamilo@localhost IDENTIFIED BY 'chamilo';"

The extension list is a specification in disguise. Caching, arbitrary precision maths, the CLI, HTTP, image processing, internationalisation, directory services, multibyte strings, the database driver, a cache client, SOAP, XML and compression. The internationalisation and multibyte packages are the ones that matter for the multilingual claim discussed later, and their presence here is a small confirmation that the translation work is real rather than cosmetic.

Two other things in that section are worth flagging. The instructions cover certificate setup not at all, with the readme leaving it explicitly to you, and they say so rather than pretending a quick start is production ready. And the readme notes that you can skip all of it entirely by using a third party installer or a cloud marketplace image, which is a reasonable option if you want a working system in an afternoon and are willing to accept whatever configuration the image ships with.

Content standards, and the one that is only partly supported

The feature list is long enough that the useful way to read it is by category, and the category that most constrains an evaluator is interoperability with other learning systems.

The platform speaks a wide set of content and integration standards: SCORM 1.2, QTI, LTI, xAPI CMI 5, the Aiken format, and others, with SCORM 2004 called out as partially supported. That list is a compatibility statement, and it is worth being precise about what it means in practice. A learning management system that can import SCORM 1.2 packages can consume almost any commercially produced e-learning content ever made, because that format is old and universal. Adding QTI and LTI extends interoperability beyond files to live integrations, and xAPI extends it again to activity records that can be consumed by systems outside the platform. Partial support on the fourth version of the older format is a limitation stated in advance rather than discovered during a migration.

The administrative side has an equivalent property. Course administration includes export and import from a named competing learning management system, and the upgrades section mentions importing existing courses from other systems. For an institution that has spent a decade building course content in a different tool, that import path is usually the deciding factor, and it is listed without qualification, which suggests it is a maintained path rather than a one-off script.

Two compliance items stand out from the rest of the list because they are jurisdiction specific. The attendance module mentions reporting for a named French quality standard, and the security section lists password policy and rotation, two factor authentication, HSTS, regular updates and intrusion detection. There is also a dedicated section for exporting personal data, which is the concrete feature behind a general data protection compliance claim. These are the items that turn a generic open source system into something a regulated institution can sign off on, and they are the reason a platform with this feature list can be chosen by a public sector buyer over a lighter alternative.

Seven analysis tools, four test layers, and a fixture scheme named after tests

The repository root contains an unusual density of quality tooling for a PHP project, and the file names tell you what each layer does.

There is a static type checker for PHP, a separate static analyser that publishes a difficulty level through a badge, an automated refactoring tool, a coding standard configurator, and two configuration files for a code style fixer. On the JavaScript side there is a formatter configuration, a linter on the current flat configuration format, a TypeScript configuration, a stylesheet framework configuration and a bundler configuration. Coverage is reported to one service, code quality to two others, and the project also carries a best practices certification badge and a digital public goods verification badge. The badges at the top of the readme are not decoration; each one is a different external service being asked to grade the same repository.

The test story is the part with the clearest design. The browser tests are not one suite. The package manifest defines a set of named scripts, each running the test runner with a filter that selects a single test by name and nothing else: one for the installation process, one to create test users, one to create a course, one to create a private course, one to enable group categories, and one tagged for a specific case. The main test run then excludes all of those by name.

That is a seeding pattern disguised as a script list, and it is the right way to do browser testing against a system that has to be installed before it can be tested. Creating the fixtures is slow and stateful, so it is done once, in order, with generous timeouts and in one case restricted to a single worker, and the fast suite then runs against a prepared instance. Encoding that in the test names rather than in a shell script means the setup and the suite cannot drift apart, because the exclusion filter is derived from the same strings the setup steps match.

Two smaller scripts sit alongside them and are worth noticing for what they check. One verifies that breadcrumb routes are consistent, and one verifies right to left classes. Both are plain node scripts rather than test framework cases, which is the right tool for both jobs: they are static consistency checks over the whole source tree, and a test framework would be the wrong way to express them.

The manifest still says 2.0.0, and the licence file appears twice

A detail that will confuse anyone automating a release: the JavaScript package manifest in the repository declares its version as 2.0.0, while the project's release tags are at 3.0.1. The description in the same file matches the platform's own tagline rather than a library description, which suggests this manifest exists to drive asset building rather than to be published as a package of its own.

That is a reasonable arrangement, and it is not a bug so much as a leftover. Asset pipelines for a server rendered application do need a manifest to record tool versions and to run the bundler, and a name and version field is required to have one at all. The cost is that the version in it is not authoritative for anything, and a script that reads the application version from the wrong place will report the previous major. The authoritative value is in a separate version file at the root, and the pattern of a platform keeping its real version in a small dedicated file is an old PHP convention that predates most package tooling.

The licence appears twice, as a top level file and again with an extension that suggests it is meant for the distribution rather than the repository. Alongside it is a metadata file with a name that indicates its purpose is to be updated during releases, which together suggest a small amount of release automation around packaging rather than a fully manual process.

Everything else in the root is tooling and conventions, and one entry is worth singling out: a file of instructions aimed at coding agents, plus a hidden directory for their configuration. For a project of this size, which is a mature PHP application with a large internationalised codebase, having agent instructions committed is a reasonable way to encode conventions that would otherwise live in a wiki nobody reads. It also means the conventions are versioned, which is the point.

Sixty languages, and a script that checks right to left markup

The multilingual claim is specific: more than sixty languages fully translated, with right to left support. For a learning management system that is a strategic feature rather than a nice to have, because public sector training programmes, refugee integration services and multinational employers all need a system in the learner's own language, and the alternative is paying for translation work on every deployment.

What makes the claim checkable is the custom script mentioned earlier. Checking right to left classes across a codebase is a static problem with a clear answer: if a layout is expressed with directional CSS properties and hand-written left and right variants, then adding a right to left language means every one of those has to be found and mirrored. A script that fails when a directional class is used incorrectly is a way of keeping that honest at scale, and it is cheaper than discovering the problem during a right to left translation review with a native speaker.

The translations live in a single top level directory, and the fact that it is one directory rather than a directory per language is what makes a script over it feasible. The internationalisation and multibyte extensions installed by the setup instructions are the runtime half of the same commitment. A word processor language and the platform's own interface are separate problems, and a system that ships sixty interface languages but runs on a server whose locale is wrong will still sort names incorrectly and still produce broken dates, which is a support problem that is entirely the deployer's to solve.

The style customisation section is the other half of the localisation story. Custom colours, custom stylesheets and a custom logo are separate from translation, and for a public sector deployment they are the difference between a system branded for the institution and a system that looks borrowed. It is a small feature that says something about who the project expects to be running it.

The AI features are integrations, and the readme says so

The feature list mentions artificial intelligence in four separate places: assignments that can be co-graded with it, quizzes that can be created with it, live chat that includes a chatbot, and the note at the end of the list about which model providers are supported, naming five of them across three companies.

The note attached to that list is the important part. It says these features and other integrations may require an active subscription to, or the availability of, external services and applications. That single sentence moves the entire AI feature set from the product into someone else's billing relationship. Co-grading, quiz generation and the chatbot are thin layers over a third party model, and whether they work at all, and at what cost, depends on a commercial arrangement the project does not control and has made no claim to subsidise.

Stated plainly, that is a sensible design for an open source platform rather than a limitation. A self hosted learning management system that bundled a model would either be enormous or would be reselling access to something it does not own. Naming five supported providers is better than naming one, since an institution with an existing agreement is not forced into a new one.

The part to be careful about is the same part that makes it useful. Co-grading is a judgement about a student's work, and a platform that will delegate that to a third party model is taking on an assessment integrity question regardless of where the model runs. Institutions that care about that will want to know whether the feature can be disabled, and the readme does not say, which is a reasonable thing to ask the project before deploying. Everything else in the feature list is software the institution runs itself, and that is the distinction worth holding on to when you read the release notes.

Editorial conclusion

Chamilo is a credible choice if you run a training organisation that needs the e-learning standards, the multilingual interface including right to left text, and the specific French regulatory reporting that the attendance module implements, and you are prepared to own the hosting. It is a poor fit if you need someone else to answer for concurrency, because the project states plainly that it has not measured it, and that gap is the first question to put to whoever supports the platform in your region. Before deploying, read the virtualhost requirement rather than assuming a shared host will do, since subfolder installations are explicitly unsupported, and check the version skew between the release tag and the bundled manifest, which still carries the previous major in its package version.

Frequently asked questions

Official sources

1. chamilo/chamilo-lms on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases