# teaching-open: a Scratch to Python teaching platform with courses, classes and assignments

> teaching-open is a Java and JavaScript platform for institutions and schools running STEAM courses, bundling a CRM, a course system, a homework system, a question bank, a competition system, a community and an article system, with editors for Scratch, ScratchJr, Python Turtle and Blockly behind it. The README documents both a Docker deployment and a manual one, and the licence is Apache-2.0.

**open-scratch/teaching-open** — Scratch少儿编程教学平台，集成Scratch、ScratchJr、Python教学工具。包含课程、班级、作业、权限、社区等。

- Repository: https://github.com/open-scratch/teaching-open
- Website: https://teaching.vip/
- Stars: 632 · Forks: 279
- Language: Java
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-scratch-teaching-open

## One platform for the institution, not just the editor

teaching-open is a JavaScript and Java platform for institutions and schools, described as a STEAM online education solution that provides a low cost way to try things out.

What makes it more than an editor is the set of systems it integrates. The project description lists a CRM, an academic affairs system, an assignment system, a question bank, a competition system, a community system and an article system, and it says it wraps commonly used utilities such as tool classes, WeChat ecosystem integration and payment integration.

That list describes an institution's software rather than a classroom's software. A class needs somewhere to put the students' work, and an institution needs a customer relationship system, a way to run competitions, a way to take payments and a way to keep parents or the public informed through an article system. The platform puts all of those in one deployment, which is the point of a product aimed at the institution rather than the individual teacher.

The open source version's feature tree is a fair guide to what is in scope. There is a home page, a community, a creation area, a student centre with your own work, class assignments, personal settings and your courses in card or map form, assignment management with work management and class assignment distribution, course management with course unit management, information management, system management, and system monitoring.

Inside system management the list is long enough to be interesting in itself: user management, role management, permission settings, class management, dictionary management, a back office menu and a front office menu, website configuration, and a Scratch asset library. The combination of a role and permission system, a dictionary and two menu systems is the shape of a system that has to be re-skinned for each school, and the front and back office menu separation is what makes that possible without touching code.

## The editors are separate open source projects, and Scratch 2.0 is retired

The teaching tool integrations are listed with links to the projects they wrap, and each one is a separate repository under the same organisation.

Scratch 3.0 is the current integration, ScratchJr is there for the younger tablet audience, Python Turtle is the text-based Python teaching environment, and Blockly comes from Google. Scratch 2.0 is listed but marked as retired, which tells you the platform has already had to migrate its editor once and will probably have to again.

The consequence for an operator is that the interesting logic is not in this repository. The top-level entries are api/, web/, deploy/, a changelist.txt, the teaching-open.code-workspace file and a directory named for reference material. The JavaScript editors live elsewhere, and the asset library configuration the README describes for Scratch 3 points at a path inside the scratch3 project, at scratch3/static/internalapi, which means the platform is deployed with a modified copy of the editor tree rather than a stock one.

That is visible in the fix for a common problem. When a custom asset library uploaded in the admin panel does not appear, the explanation is that the custom library must use Qiniu cloud storage, because the default is a local library, and the solution is to upload the local library to Qiniu keeping the directory structure, selecting the internalapi directory. Then the asset library address in scratch3/index.html is switched to the cloud domain with a two-line change:

```js
assets:{
  assetHost: getSysConfig('qiniuDomain')
}
```

So a deployment is partly a deployment of this platform and partly a deployment of a patched Scratch 3 tree, and the two have to be kept in step.

## Docker is the quick path, and the server advice is specific

The README gives two deployment routes, and the Docker one is presented as the quick way to try the system.

There is a panel-based route through a Chinese control panel, where you add a container orchestration entry and paste in the contents of docker-compose.yml and the .env file, then wait a few minutes. And there is a command line route with two steps: install Docker and Docker Compose, upload the deploy folder to the server, and run docker compose up -d inside it.

The server requirements are given as advice rather than as hard limits, and they are worth taking seriously. Two cores and 4 GB of memory or more is the recommendation, along with bandwidth of 100M billed by traffic. The note about not installing Nginx on the server is a practical gotcha, since the platform's own port would then be occupied, and the workaround is to change the port configuration yourself. And if you want to use a different database or a different cloud storage, you have to edit the .env configuration first.

For a reader outside China, some of the dependencies are worth flagging before you start. The object storage is Qiniu, a Chinese service, and the README's manual setup section walks through registering at qiniu.com, completing the identity verification, creating an object storage bucket, setting the access control to public, binding a domain, and collecting the access key and secret key. There is a note that the free test domain expires after a month, which is the sort of detail that bites in month two.

The project also publishes an open source demo at open.teaching.vip, with an admin account for the super administrator, a teacher account and a student account, all with the default password of 123456.

## The manual build is Java, MySQL, Redis, Maven and Node

The manual deployment path is a long one and the README documents it step by step, which is unusual and useful.

The environment preparation is CentOS as the example, and the components are MySQL 8, Redis 6.0, Java, Nginx and a registered Qiniu account. The Java install is a single command, yum install -y java-1.8.0-openjdk, and the database step is to import two SQL files from the api/db folder, teachingopen2.8.sql and qrtzUpcase.sql, with a note that an upgrade means running the update_xxx.sql files in version order.

The backend configuration lives in application.yml, which switches between the test and production profiles and defaults to the production one, application-prod.yml. The things you have to change are the domain, the uploadType which selects local storage or Qiniu, the datasource block with the MySQL URL and credentials, the redis block with its database number, host, password and port, and the qiniu block with the access key, secret key, bucket name, static domain and storage area. The areas are given as codes, with z0 for east China, z1 for north China, z2 for south China, na0 for north America, as0 for south east Asia and cn-east-2 for the Zhejiang east region.

There is a configuration practice here that is worth adopting regardless of the stack. The README says the configuration file can be modified after compilation, and recommends putting the yml file next to the jar package, because Java will use the same-directory configuration first, which makes upgrades easier.

The build itself is Maven, and the README asks you to configure a mirror in the settings, with an exclusion list that keeps a few specific repositories from being mirrored:

```xml
<mirrors>
       <mirror>
            <id>nexus-aliyun</id>
            <mirrorOf>*,!jeecg,!jeecg-snapshots,!getui-nexus</mirrorOf>
            <name>Nexus aliyun</name>
            <url>http://maven.aliyun.com/nexus/content/groups/public</url>
        </mirror> 
 </mirrors>
```

From the api directory you run mvn clean package, which produces a jar in the target directory, and that jar is uploaded to the server with the yml file alongside it. The API is then started in the background with nohup java -jar, or through the included start-teaching.sh script.

The frontend is a separate build with Node 16, npm install or yarn install, and npm run build or yarn run build, and the resulting dist folder is uploaded to the web root and served by Nginx, with an /api location proxied to the backend on port 8080.

## Local storage is possible but not recommended

One configuration decision deserves its own note, because the README is unusually direct about it and because the default surprises people.

The default upload target is a local library, and the local storage mode is configured in the jeecg section of application-prod.yml with an uploadType of local, an upload root directory and a staticDomain pointing at the API's own static file route. The README strongly recommends cloud storage, on the grounds that it greatly reduces the bandwidth pressure on the server, and says that if you do not want a Chinese object storage service or you are deploying on a local network, you can use local storage mode.

The warning that comes with it is the operational consequence. After switching to cloud storage, previously uploaded files have to be migrated by hand. That is the kind of step that gets skipped and regretted, because the system keeps working and the old assets are simply unreachable.

The same dependency shows up in the troubleshooting section. When a Scratch project submission hangs, the three causes listed are a misconfigured Qiniu setup, in which case other uploads in the system will fail too, a page left open long enough for the session to expire, which you can work around by saving the Scratch file locally and submitting again after a refresh, and a network problem.

The other troubleshooting entries are more diagnostic of how the platform is put together. A page that loads forever has two likely causes, the API not running, which you can check by visiting the port 8080 address directly, and a misconfigured Nginx reverse proxy, whose signature is a 502 or 504 on the API calls. And a background upload of Scratch assets that does not show up is a Qiniu configuration problem rather than a bug.

The upgrade procedure is documented as a numbered list: prepare the compiled API and web builds, run the upgrade SQL files in version order from the api/db folder, upload the newest jar, stop the old API, restart, and overwrite the front end files.

## Conclusion

teaching-open is worth evaluating if you run coding classes for a school or an institution and want one system for courses, class assignments, submissions and a student portfolio rather than a set of separate tools, because the editing integrations are the part that is genuinely hard to build and they are already wired up. It is the wrong tool for an individual tutor with a handful of students, since the platform carries a CRM, a permission system and a competition system you would not use, and it is the wrong tool if you cannot run Java, MySQL and Redis. Before you deploy it, verify three things yourself: that the Java and Node versions it expects are what you have, since the manual build asks for Java 1.8 and Node 16, that the storage decision is made deliberately, because the custom Scratch asset library requires object storage and will not display from the local library, and that the demo credentials are changed before the platform faces real students, since the open source demo is published with an admin, teacher and student account and a shared default password.

## FAQ

### What is the teaching-open platform?

It is a STEAM online education platform for institutions and schools, written in Java and JavaScript, that integrates a CRM, an academic affairs system, an assignment system, a question bank, a competition system, a community and an article system. It is Apache-2.0 licensed and the homepage is teaching.vip.

### Which coding environments does teaching-open support?

The teaching tool integrations are Scratch 3.0, ScratchJr, Python Turtle and Blockly, each a separate open source project. Scratch 2.0 is listed as retired, and a custom Scratch asset library requires object storage and a change to the assetHost line in the editor's index.html.

### How do I deploy teaching-open with Docker?

Install Docker and Docker Compose, upload the deploy folder to the server and run docker compose up -d inside it. The recommended server has two cores and 4 GB of memory or more with 100M bandwidth, and the README warns against installing Nginx on the same host because the port would be occupied.

### What does a manual build of teaching-open require?

MySQL 8 with the SQL files imported from the api/db folder, Redis 6.0, Java 1.8 installed with the openjdk package, Nginx, and a registered object storage account. The backend is built with mvn clean package in the api directory and the frontend with npm run build on Node 16, and the dist folder is served by Nginx with the /api path proxied to port 8080.

### Can teaching-open use local file storage instead of cloud storage?

Yes, by setting uploadType to local in the jeecg section of application-prod.yml along with an upload directory and a staticDomain. The README strongly recommends cloud storage because it reduces server bandwidth pressure, and warns that files uploaded before the switch have to be migrated by hand.

## Sources

- [License: Apache-2.0](https://github.com/open-scratch/teaching-open/blob/master/LICENSE)
- [open-scratch/teaching-open on GitHub](https://github.com/open-scratch/teaching-open)
- [Project website](https://teaching.vip/)
- [README](https://github.com/open-scratch/teaching-open/blob/master/README.md)
- [Releases](https://github.com/open-scratch/teaching-open/releases)

---

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