PlayEdu: a self-hosted corporate training platform built on Spring Boot 3 and React 18

The gap PlayEdu fills, and the edition boundary that defines it

Most small and mid-sized companies that need internal training end up choosing between a hosted SaaS product and a learning management system built for universities. PlayEdu targets the space in between: a corporate training platform you run yourself, with department management, student management, online video learning, progress tracking and private video storage in the open source edition. The README describes it as a solution built by Baishu Technology out of years of work in online education, and the open source repository is the free tier of that product line.

The boundary matters more than the feature list. The README states plainly that the commercial edition adds audio and video learning, online document preview, online exams, learning tasks, video transcoding and encryption, hotlink protection, anti-fast-forward and anti-idle detection, plus integrations with WeCom, DingTalk and Feishu. None of that is in the open source repository as described. So the question a reader should ask is not whether PlayEdu can run a training program, but whether the specific program they have in mind fits inside department management, student management, video playback and progress tracking. If it does, the open source edition is coherent. If it does not, the project is a demo of a product you would have to buy.

One more constraint sits in the README's usage notes rather than in the licence file. The project is Apache-2.0, but the README adds its own terms: modifications are allowed only if each change is marked with a comment recording what was changed, and the copyright notices, including the "Designed By PlayEdu" page mark and the official site link, must be preserved. That is a stricter posture than Apache-2.0 alone, and it is stated in the README, not in LICENSE.

How the PlayEdu stack is assembled: one container, four ports, two builders

The architecture is visible in the Dockerfile and compose.yml. The build runs in stages. A Node 20 Alpine image installs pnpm dependencies for three separate frontends, playedu-admin, playedu-pc and playedu-h5, and builds each with VITE_APP_URL set to /api/. A separate Temurin 17 image copies the Maven wrapper and the module poms, runs dependency:go-offline, then copies the full playedu-api tree and packages it with tests skipped. The final stage copies the built jar to /app/api/app.jar, the three dist directories to /app/admin, /app/pc and /app/h5, drops in an nginx configuration, and starts nginx alongside the Java process.

That means a single container serves everything. compose.yml publishes four mappings: the API on 9700 to container port 9898, the PC site on 9800, the H5 site on 9801 and the admin console on 9900. MySQL runs as a second service built from ./docker/mysql, with a named volume mysql-data for /var/lib/mysql and a host mapping on 23307 by default. The API waits on the mysql service through depends_on.

Configuration is entirely environment driven. The compose file reads PLAYEDU_DB_HOST, PLAYEDU_DB_PORT, PLAYEDU_DB_NAME, PLAYEDU_DB_USER and PLAYEDU_DB_PASS, with defaults pointing at the bundled mysql service, plus a set of Hikari pool settings: PLAYEDU_DB_POOL_MIN_IDLE at 1, PLAYEDU_DB_POOL_MAX_SIZE at 10, and timeout values of 30000, 600000 and 1800000 milliseconds for connection, idle and max lifetime. Authentication uses SA-Token with a JWT secret from PLAYEDU_JWT_KEY, defaulting to playeduxyz, and PLAYEDU_SA_TOKEN_IS_CONCURRENT controls whether one account can be logged in from more than one place.

The pool defaults are worth reading carefully. A maximum of ten connections is a modest ceiling for a service that streams video metadata and tracks progress for every student, and the .env.example exposes the value, so raising it is a deliberate operational decision rather than a hidden one. The JWT default is the more urgent item: .env.example annotates PLAYEDU_JWT_KEY with a note to change it in production, which implies the shipped value is a placeholder.

Installing PlayEdu with docker-compose and reaching the admin console

The README gives a two-step quick start. The first command clones the repository from Gitee on the main branch into a directory named playedu.

git clone --branch main https://gitee.com/playeduxyz/playedu.git playedu

The second command moves into that directory and brings the stack up. The README writes it as docker-compose up -d; the repository file is named compose.yml, so on a Docker installation that only ships the compose plugin you would run the same thing as docker compose up -d.

cd playedu && docker-compose up -d

Because compose.yml declares a build context of . with the repository Dockerfile, this step compiles the three frontends and the Java API locally rather than pulling a prebuilt image. Expect it to take a while on a first run, and expect it to need network access to the Aliyun registry that hosts the Node and Temurin base images.

When the containers are up, the README says to open http://localhost:9900 for the admin console and log in with [email protected] and password playedu. The other surfaces are listed as the PC site on http://localhost:9800, the H5 site on http://localhost:9801 and the API on http://localhost:9700.

Before exposing any of that beyond your own machine, copy .env.example and set at least the secret and the database password. The file is explicit that the JWT key must be changed in production and that PLAYEDU_DB_PASS is shared between the application and the MySQL root user.

cp .env.example .env
# then edit PLAYEDU_JWT_KEY and PLAYEDU_DB_PASS before re-running compose

One flag deserves attention before you flip it. PLAYEDU_DEMO_MODE is described in .env.example as making resource deletion remove only the database record while leaving the S3 object in place, for use on a demo site. The same comment warns that leaving it on in production produces S3 objects that can never be reclaimed. It defaults to false, which is the correct default.

Where PlayEdu stops being the right tool

The most concrete limitation is the edition split. A training program that needs an exam, a document to read rather than a video to watch, or a policy that learners cannot skip ahead through a video will not be served by the open source repository as the README describes it. Those are commercial edition features, and the README presents them as the reason the commercial edition exists. Building them yourself is possible under the licence, but the README's modification clause requires a comment on every change, which turns a fork into a maintenance commitment with a paper trail.

The second limitation is operational. The stack builds from source on every fresh machine and depends on base images hosted in a regional Aliyun registry. Teams whose build runners cannot reach that registry, or who need a reproducible image digest rather than a rebuild, will have to mirror the bases themselves. The repository does not document a prebuilt image.

The third is the database ceiling. The Hikari pool defaults to ten connections, and the README does not discuss sizing for concurrent video playback or progress reporting. Video itself is stored privately, per the feature list, which means the API is in the path of storage access and the pool is shared across all of it. That is a design that works at department scale and needs measurement before it works at company scale.

Finally, the README does not document rollback, backup or upgrade procedure for the MySQL volume. The deployment documentation is linked from the README as an external handbook, so the repository alone is not a complete operations guide.

PlayEdu against Moodle and against buying the commercial edition

The obvious alternative for a self-hosted training system is Moodle, and the difference is not feature count. Moodle is an academic learning management system: courses, quizzes, assignments, gradebooks and a plugin ecosystem that assumes formal assessment. PlayEdu's open source edition is narrower on purpose, with department and student management, video learning and progress tracking, and a Chinese-language admin console built for corporate onboarding rather than for a semester. If your training is compliance video plus a completion record, PlayEdu's scope is closer to the job. If assessment is the point, Moodle covers it without a commercial tier.

The other alternative is PlayEdu's own commercial edition. The README positions it as faster and more concurrent, with audio and video learning, document preview, exams and learning tasks, plus video transcoding and encryption, hotlink protection, anti-fast-forward and anti-idle detection, and WeCom, DingTalk and Feishu integration. That is not a different product; it is the same product with the parts most enterprises actually ask for. Anyone evaluating the open source edition should price that comparison before committing engineering time to a fork, because the fork has to be maintained against upstream changes.

Maintenance, releases and what the licence actually asks of you

The repository is not archived. The last push was on 2026-05-19, and the 2.2 release carries the same date, with 2.1 five days earlier and 2.0 back on 2025-05-23. That pattern is worth noting: two releases in a week after roughly a year of quiet, which suggests the project moves in bursts rather than on a schedule. There is a CHANGELOG.md at the repository root, so release-to-release differences are traceable without reading the commit log.

Upgrade cost is mostly the build. Since compose.yml builds from the repository rather than pulling a tagged image, moving to a new release means checking out the new code and rebuilding the frontends and the API. The MySQL volume persists across that, and the README does not describe schema migration steps, so a backup before upgrading is the obvious precaution. The external deployment handbook is the project's own reference for this.

The licence is Apache-2.0, and the repository ships a LICENSE file. On top of that, the README's usage notes assert that Hangzhou Baishu Technology holds full copyright in the open source edition, permit modification only with a comment recording each change, and forbid removing or altering copyright information and the open source notice files. They also require the "Designed By PlayEdu" page mark and the official site link to remain in place in every usage scenario, with legal action threatened for violation. Whether those README terms are enforceable alongside Apache-2.0 is a question for your own counsel, not something this article can settle. What is clear is that the project states them, and a team that intends to white-label the interface should read them before starting.

Editorial conclusion

Adopt PlayEdu if you need department and student management, online video learning and progress tracking on infrastructure you control, and you accept that the open source edition stops there. Do not adopt it if online exams, document preview, anti-fast-forward or DingTalk, WeCom and Feishu integration are requirements, because the README places all of those in the commercial edition. Before committing, verify three things: whether the 2.2 release matches the main branch you clone, whether your video storage can be reached from the API container, and whether the copyright clauses in the README are acceptable to your legal team. The deployment handbook linked from the README is the only place the project points to for production setup.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. PlayEdu/PlayEdu on GitHub
3. Project website
4. README
5. Releases