sg-exam: a Spring Boot and Vue teaching platform for exams, quizzes and practice

A full teaching platform rather than a component

sg-exam is a teaching management platform built on Spring Boot and Vue, described as a new generation platform that merges a multi-tenant system with detailed permission management, covering online exams, daily practice and interactive learning.

The scope is the first thing to establish, because it decides whether this project is useful to you. This is a whole platform, not a library and not a single service. It combines a web front end, a back office administration system and an H5 client, and the project documentation describes the three parts as building a smooth online learning and examination environment.

Inside the administration side, the system configuration module manages units, users, departments, roles, menus and operation logs, and it supports code generation. The examination management side covers the whole chain from course creation through exams, the question bank and score evaluation. Users can favourite exams, questions and courses, and pick a question bank for targeted practice.

The audience is a school, a training organisation or a corporate learning team that wants a working system to adapt, and a developer who reads Java and Vue and wants a reference implementation of that shape. It is not aimed at embedding a quiz widget in an existing product.

The README also describes a lightened deployment, with middleware dependencies trimmed in this version to simplify deployment and maintenance.

Exam modes, question types and the course hierarchy

The exam model supports several types of activity, described as exam, practice and questionnaire, with answering modes that include one-shot completion, sequential answering and time-limited answering. That combination covers the common shapes of assessment: a graded exam under a clock, a quiz that repeats until it is learned, and a survey with no right answer.

The question types are where the work sits. The list covers single choice, multiple choice, true or false, short answer, and multimedia types including video and audio, with content that can mix text, images and video. Manual authoring, quick selection from the bank, and randomised paper generation from the bank are all listed as ways to build a paper.

Courses have their own structure. The documentation says course design supports breaking content down to the knowledge point level, and a course can carry illustrated and video content. Alongside courses there is a question bank and an evaluation of results, and the file listing of the front end shows screens for course lists, course detail, chapter and section views, admin dashboards, exam management, subjects, scores, menus and a monitoring view.

The one-line summary in the repository description mentions permissions, exams, questionnaires and practice. The real feature set is broader than that: it is a course delivery system with assessment attached to it, which is a materially larger thing to own and customise.

A multi-module Gradle build with three front end apps

The repository layout shows how the system is put together. On the Java side there are several Gradle modules: sg-api, sg-common, sg-exam-service, sg-generator, sg-job and sg-user-service, alongside build.gradle, settings.gradle, gradle.properties, the gradlew wrapper and gradlew.bat for Windows. The names suggest a separation between the shared code, the public API, the examination service, the user service, a code generator and a scheduled job module.

The front end is a directory named frontend, and the Dockerfile copies three separate build outputs out of it, which tells you there are three distinct web applications:

COPY frontend/sg-exam-web/dist /usr/share/nginx/html
COPY frontend/sg-exam-admin/dist /usr/share/nginx/html/admin
COPY frontend/sg-exam-mobile/dist /usr/share/nginx/html/mobile

The user-facing web app, the administration console and the mobile H5 build are served from the same Nginx document root, with the admin and mobile builds under their own subpaths. That is a single-host deployment, which keeps the infrastructure small, at the cost of the three apps sharing a domain and a set of server-side certificates.

Other top-level pieces complete the picture: a config-repo directory holding the configuration files, a docs directory, a docker-compose.yml, a Dockerfile and a setup.sh script. The service jar is copied in as well:

COPY sg-user-service/build/libs/*.jar app.jar

Note the implication for a first build. The image expects a compiled jar from sg-user-service and three built front end distributions to exist already, so a fresh checkout has to be built with Gradle and the front-end toolchain before the container image means anything.

docker-compose bundling MySQL, Redis and MinIO

The deployment story is the docker-compose file, and it is the most useful artefact in the repository for an evaluator. It defines a network named sg-network and four services, three of which are infrastructure the application expects to find.

The MySQL service is pinned to a specific image rather than latest:

  mysql-service:
    image: mysql:5.7.27
    container_name: mysql-service
    restart: always
    networks:
      - sg-network
    volumes:
      - ./data/mysql-data:/var/lib/mysql
      - ./config-repo/mysql/conf/my.cnf:/etc/my.cnf
      - ./config-repo/mysql:/docker-entrypoint-initdb.d
    environment:
      - "MYSQL_ROOT_PASSWORD=123456"
      - "MYSQL_DATABASE=sg-exam-user"
    ports:
      - "3306:3306"

The database name sg-exam-user matches the user service module name, and the SQL init directory is mounted into the standard entrypoint path, so the schema is applied on first start. A custom MySQL configuration file is mounted over the image's own, which is how you change buffer sizes or character sets without rebuilding anything.

Redis is pinned to redis:latest and given its own configuration file and data directory. MinIO is the object store, and it is the one to look at twice, because it ships with example credentials and a wide open listen address:

  minio-service:
    image: minio/minio
    container_name: minio-service
    restart: always
    networks:
      - sg-network
    command: server /data --address "0.0.0.0:9000" --console-address "0.0.0.0:9090"
    ports:
      - "9000:9000"
      - "9090:9090"
    environment:
      - "MINIO_ACCESS_KEY=admin"
      - "MINIO_SECRET_KEY=admin123456"

MinIO is where course video and audio would live, which makes sense for a platform whose question types include video and audio answers. The example access key and secret are exactly the kind of thing that must be replaced before this is reachable by anyone else, and the console on port 9090 is exposed to the host as well.

The application service itself is the fourth entry:

  sg-exam:
    image: sg-exam:latest
    restart: always
    networks:
      - sg-network
    env_file: config-repo/sg-exam.env
    ports:
      - "80:80"
      - "8080:8080"

The environment comes from a file, config-repo/sg-exam.env, and the container publishes both the HTTP port and the application port. The compose file states that each embedded service can be deleted if you already run MySQL or Redis elsewhere, which is the intended path for a real deployment.

One container image running Nginx and Java 17

The Dockerfile describes the application image, and its structure is unusual enough to be worth reading before you build it. The base is not a slim Java image but an Alibaba Cloud Linux 3 registry image, and the label records the version, the maintainer and the Apache 2.0 licence.

Nginx and Java 17 are installed with yum, and the timezone is pinned to Asia/Shanghai both as a system link and as an environment variable. The working directory is /apps/data/web/working, and the three front end distributions are copied into the Nginx document root and its admin and mobile subdirectories, as the earlier snippet shows.

The runtime command is a shell script rather than a Java command:

WORKDIR /apps/data/web/working
COPY frontend/sg-exam-web/dist /usr/share/nginx/html
COPY frontend/sg-exam-admin/dist /usr/share/nginx/html/admin
COPY frontend/sg-exam-mobile/dist /usr/share/nginx/html/mobile
COPY config-repo/nginx /etc/nginx/
COPY sg-user-service/build/libs/*.jar app.jar
COPY config-repo config-repo
COPY setup.sh setup.sh

EXPOSE 80
CMD ["sh", "setup.sh", "start_inner"]

So Nginx and the application run inside one container, which simplifies the compose file to a single application service. The start_inner argument to setup.sh is the inner start command, and the script itself is copied into the image alongside the config-repo directory, so the container can read its configuration and the jar at startup.

Only port 80 is exposed by the Dockerfile, even though the compose file also maps 8080. That mismatch is worth resolving in your own environment rather than assuming both are served.

A note on the label version, 0.0.14, against the README badge showing 0.0.15. The image metadata and the project version are not in lockstep, so do not treat the label as a release identifier.

Documentation you have to request, and a quiet commit history

This is the part of the project that most affects whether you can adopt it, and it is a documentation access problem rather than a code problem.

The README does not carry a deployment manual, an operations handbook or a source walkthrough. Instead it points to a Yuque documentation space with a roadmap page, and it states that the deployment documentation, the operations manual, the source analysis and the video tutorials are obtained by following the author's WeChat public account and sending a keyword. There is also a Gitee issue used to register as an open source user, and the project asks for pull requests and issues through Gitee rather than GitHub.

The consequence is concrete. The repository gives you source, a compose file, a Dockerfile and a config-repo, but the operating instructions live in a document you have to ask for, and the tutorial content is video. For a team that wants to run the platform this is a real obstacle, and it is a different kind of obstacle from the code quality.

On maintenance, the facts are modest. The last push was on 2026-04-05, and the repository has no GitHub releases. The README does carry a CHANGELOG.md, and the version badge shows 0.0.15, but there is no tagged artifact to pin and no published release to diff against. The homepage points to yunmianshi.com.cn.

The licence is Apache 2.0, with the LICENSE file in the repository and a badge stating the same. That is a permissive licence, so a company can fork this, modify it and ship the result without disclosing the source, provided the licence and notice travel with it.

Editorial conclusion

Adopt sg-exam if you need a working multi-tenant teaching and examination platform rather than a component, and you are prepared to read the deployment manual and adapt the code yourself. Do not adopt it if you need an active upstream to carry security patches, since the last push was on 2026-04-05 and the project ships no GitHub releases, and do not deploy the bundled compose file as-is, because its MySQL root password, MinIO access keys and the exposed ports are example values. Verify first that the frontend dist folders you build match the three directories the Dockerfile copies, that setup.sh start_inner behaves as your environment expects, and that you replace every example credential in config-repo before the stack comes up.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. wells2333/sg-exam on GitHub