course-tencent-cloud: a self-hosted online course platform on Phalcon and Tencent Cloud

What the open source edition is

The project is the open source edition of Koogua Cloud Classroom, a 网校 open source release, and it is built on Tencent Cloud's base services. The development framework is the C extension framework Phalcon, and it can be used to build an online course system, a school system, a knowledge payment system or an online education system.

So the product shape is a knowledge payment platform. That is a specific and fairly demanding category: you are not only hosting videos, you have orders, payments, coupons, course packages, a member system and a teacher backend. The README's own demo includes a payment flow, with example order confirmation pages for courses priced at 0.01 and 0.02 yuan, which is a cheap way to exercise the checkout path without real money.

The audience is the operator. The repository is the system, and the deployment story is a set of wiki pages rather than a Dockerfile in the tree, with three of them: runtime environment setup, system service configuration, and client-side configuration.

The demo systems are reachable, a front end and an admin back end, with a shared demo account, and there is a separate H5 mobile demo with its own account. The README includes three warnings that are worth reading before you form an impression of the demo. The demo system configuration is low, 2 cores, 4G of memory and 1M bandwidth running multiple containers, so do not put it under load test. The course data is collected from the network and has no substantive content, so do not buy it. And data submission in the admin back end has been disabled, with private configuration filtered out.

The project is GPL-2.0 licensed with a LICENSE file at the root, the primary language is PHP, the last push was on 2026-10-15, and the releases are v2.0.0 from 2026-09-16, v1.8.3 from 2026-06-09 and v1.8.2 from 2026-01-25. The default branch is v2.

The stack, and the version numbers it pins

The component list is short and each entry carries a version, which is unusual and useful because it tells you exactly what a working configuration looked like.

The back end framework is Phalcon 5.20.3, the front end framework is Layui 2.13, the full text search is XunSearch 1.4, and the base dependencies are PHP 8.4, MySQL 8.4 and Redis 8.2.

XunSearch is the piece that stands out. It is a separate search engine rather than a MySQL full text index, which for a course platform with tens of thousands of lesson records and Chinese full text search is a reasonable choice, since the character set and the tokenisation rules matter for Chinese content in a way they do not for English.

The version pairing is worth noting as a whole. PHP 8.4 with Phalcon 5.20 and Redis 8.2 is a current stack, not a legacy one, which suggests the project is maintained rather than merely published. The release history supports that reading, with a v2.0.0 in September 2026 and patch releases in the months before it, on a v2 default branch.

The front end choice of Layui matters too. Layui is a component library that ships its own assets and is served by the application rather than bundled by a JavaScript toolchain, so the deployment is simpler than a modern SPA, and the resulting pages are server rendered, which is the norm for this kind of Chinese web product and works well on the mobile H5 clients that the platform targets.

The directory layout, and what each directory is for

The top level is a conventional PHP application, and the naming tells you the framework conventions it follows.

There is an app/ directory, which in Phalcon holds the application code, with the controllers, models and views living there. There is a bootstrap/ directory, which is where the bootstrap file lives. config/ holds the configuration, and public/ is the document root, the only directory a web server should point at. storage/ is where runtime artefacts go, which in Phalcon means caches, logs and compiled things.

Then there are three files that describe the application's own machinery. console.php is the command line entry point, which is what you use for scheduled jobs and one-off administration. scheduler.php is the scheduler, a separate entry point from the console for the recurring tasks the platform needs. phinx.php is the migration configuration, since the project uses Phinx for database migrations, and the db/ directory holds the schema and the migration files.

That last combination is the interesting part of the layout. A platform with orders, courses and members has recurring background work, so the scheduler is a first-class file rather than a cron entry bolted onto the console, and the migrations are managed with a dedicated tool rather than a SQL dump in the repository. The db/ directory sits alongside the app code for the same reason, because a schema change and the code that depends on it belong together in review.

The rest of the tree is standard: composer.json and composer.lock for the PHP dependencies, a CHANGELOG.md, a SECURITY.md, a README.md and a .gitignore.

The version line and the changelog, and what the demo will not tell you

Two things are worth separating out before evaluating the code, because the demo will not tell you either of them.

The first is the version line. The default branch is v2 and the latest release is v2.0.0 from 2026-09-16, which sits after patch releases v1.8.3 from 2026-06-09 and v1.8.2 from 2026-01-25. A major version bump in a long-running PHP project usually means a compatibility break, and the project carries a CHANGELOG.md at the root, so the upgrade notes are there, but the 1.x to 2.0 change is the one a fork is most likely to hit.

The second is the demo itself. The README is unusually explicit about the limits of the hosted demo. The configuration is low, 2 cores and 4G of memory with 1M of bandwidth running multiple containers, and the instruction is not to put it under load. The course data is collected from the network with no substantive content, so it is not worth buying. And the admin back end has data submission disabled and private configuration filtered out.

That last point has a technical consequence that matters for evaluation. If the admin back end will not accept submissions, then the paths you would normally use to test the product, creating a course, publishing it, enrolling a student, taking an order, are not exercisable in the demo. The payment flow links go to a separate pro host, so the checkout path is testable, but the content management path is not. Anyone evaluating whether this suits a course business will have to read the code for the parts the demo deliberately disables.

The demo accounts themselves are published. A shared account for both the front end and the admin back end, and a separate one for the H5 mobile client, with the same simple password on both. They are demonstration credentials on a public system with a low configuration, which is fine for looking at screens and irrelevant for security.

The SECURITY.md file at the repository root is the file to read if you are running this for real, and it is the standard place for a project to describe how to report a problem.

Where the operational burden sits

This is a self-hosted commercial system, and the documentation is organised around the three things an operator has to get right.

The runtime environment setup page covers what the machine needs, and the project name says the target is Tencent Cloud, so the paths in those pages assume that provider's instances, its object storage and its database service. The system service configuration page covers the services the application itself needs, which on the pinned versions means MySQL 8.4 and Redis 8.2, and the full text search engine on top of them. The client-side configuration page covers what a browser or a mobile client needs to reach, which for a platform with an H5 front end is where the domain, the upload endpoint and the payment callback come from.

That division is the honest way to run a product like this. A course platform holds user accounts, order records and paid content, so the deployment is not a single process you start. There is a web application, a scheduler running on its own schedule, a search index that has to be built and kept in step with the database, and a set of credentials for the payment provider and the object storage.

The consequence for anyone evaluating it is that the wiki pages are part of the product, not an afterthought, and a fork has to carry them. The repository itself does not include them, so the deployment knowledge lives outside the git history, which is the main thing to be aware of before adopting this as a base.

The feedback channels are split in the same way. Issues go to the Gitee platform at gitee.com/koogua/course-tencent-cloud/issues, and the official community is on the project's own community page.

Editorial conclusion

course-tencent-cloud suits an operator who wants to run a paid course platform on infrastructure they control, and who is comfortable with PHP, MySQL and Redis, or with containerised deployment on a cloud provider. It is a poor fit for a team that needs an actively modernised product, because the codebase is a Phalcon application with a v2 branch and a changelog that moves slowly, and it is a poor fit for a multi-tenant SaaS product without work, since the tenancy model is not described. Before adopting, read the environment setup and service configuration pages on the project wiki, and check the SECURITY.md file, since the repository ships a security policy alongside the code.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. xiaochong0302/course-tencent-cloud on GitHub