Open-source online judge platform · From problem practice to contest judging
Java 17 · Spring Boot · Vue 3 · TypeScript · Docker
English · 简体中文
Quick Start · Screenshots · Documentation · Roadmap · Contributing
UltiCode is a full-stack online judge platform providing a problem library, contests, online judging, editorials, community, and an admin console.
| Area | Capability |
|---|---|
| Practice | Problem library, contests, code submissions, and judging records |
| Learning and community | Editorials, forum, achievements, and user profile |
| Platform administration | Problem and contest management, moderation, audit, notifications, and operational queries |
| Judging | A standalone Judge worker consumes Submissions from Redis Streams and runs code in a Docker sandbox |
The screenshots below are the design and regression reference screenshots maintained in this repository; see the screenshot index for more pages.
| Console · Problem detail | Management · Dashboard |
|---|---|
![]() |
![]() |
| Layer | Technology |
|---|---|
| Backend | Java 17, Spring Boot, Maven, MyBatis-Plus, Flyway, Dubbo |
| Frontend | Vue 3, TypeScript, Vite, pnpm workspace |
| Infrastructure | Docker Compose, MySQL, Redis, Nacos, MeiliSearch |
git clone https://github.com/DavidHLP/UltiCode.git
cd UltiCodePrerequisites: Docker Compose v2, mise, Node.js ^20.19.0 || >=22.12.0, pnpm 10+, PM2, plus curl, timeout, and openssl. Backend startup runs through the repository's services/mvnw and the mise-managed Zulu Java 17.
Contributors can also use Dev Containers / Codespaces directly; creating the container only installs dependencies and then runs the unit gate by default — it does not start the full stack:
./ulticode doctor --json./scripts/dev/init-env.shRequired reading for the first start
init-env.shgeneratesSUBMISSION_CUTOVER_COMPLETEasfalse. Bothdev-liteanddev-fullrequireAPP_SUBMISSION_ROUTING_MODE=remoteand a completed Submission cutover marker; the startup scripts refuse to run when either is missing.Read Database migrations first, and complete migration and verification according to the authorized cutover/backfill runbook. Do not skip the checks by only changing the marker.
Once the preparation above is done, choose a mode:
| Mode | Search | Frontends |
|---|---|---|
dev-lite |
Database-backed search; no Search worker | Not started by default |
dev-full |
Indexed search with the Search worker | Both frontends started |
./scripts/dev/up.sh --mode dev-litedev-lite uses database search, does not start the Search worker, and does not start either frontend by default; run the following when you need the browser UI:
./scripts/dev/up.sh --frontend-onlydev-full enables indexed search, the Search worker, and both frontends, still behind the same cutover gate:
./scripts/dev/up.sh --mode dev-fullOnce the frontends are running: Console · Management. See Local development for scopes, logs, and troubleshooting entry points.
Optional Core pilot and rollback notes
The Core convergence pilot uses an explicit scope and keeps Judge as a separate process:
./scripts/dev/up.sh --scope core
./scripts/dev/test.sh coreThe Core parent listens on 9108 with readiness at /api/v1/core/health/ready; that profile currently serves owner assembly and boundary verification and has not yet replaced the default distributed topology.
This version no longer supports legacy-rollback; up.sh fails closed for that legacy mode and for unknown modes. Production rollback can only use the last complete release descriptor retained and verified by the deployer — the current binaries cannot restore the old implementation (see Deployment, release, and rollback).
UltiCode/
├── apps/
│ ├── console/ # Console (user application)
│ └── management/ # Management (admin application)
├── packages/ # Shared frontend packages
├── services/ # Backend services, API contracts, and workers
├── init-db/ # Database initialization and Flyway migrations
├── docker/ # Infrastructure and judging sandbox
├── scripts/ # Development, verification, and operations entry points
└── docs/ # Architecture, development, and deployment documents
The default topology is distributed. Auth, Admin, App, Submission, and Notification each own their data and write boundaries; Judge runs judging, and Search maintains derived indexes. See the architecture overview.
Long-form documentation is currently maintained in Chinese.
- Documentation index: authoritative sources by architecture, development, operations, API, status, and history.
- Current status: repository completeness, external boundaries, and current verification entry points.
- Architecture overview: service boundaries, Owner/Worker topology, and key constraints.
- Local development and testing, Testing and quality.
- Deployment, release, and rollback, Database migrations.
- Authentication API, API and internal contracts.
Implementation, configuration, migration scripts, tests, and executable runbooks are the source of truth for behavior; this repository has no production environment, and production deployment, real traffic, and external credentials are the deployer's responsibility.
Report issues and discuss improvements through Issues, or open a Pull Request.
- When reporting an issue, include reproduction steps, expected vs. actual behavior, and sanitized environment details.
- Read
AGENTS.mdand the relevant directory guides before starting; discuss the scope in an Issue first for larger changes. - Add tests for behavior changes and run the matching checks from the testing guide.
- Explain the reason, verification method, and known limitations in the Pull Request.
Before submitting, run git diff --check and the ./scripts/dev/test.sh gate matching the surface you touched. Never commit .env, credentials, private keys, or generated runtime artifacts.
Released under the MIT License.

