Delivery System for a Privately Deployed AIGC Practical Training Platform for Colleges
Chapter 01
Overview
A delivery system for privately deployed AIGC practical training platforms for colleges. Starting from a public-internet authorization center, it generates a dedicated full set of deliverables for each college or department: student installation media containing a local large video model, a teacher-side installer and an on-campus server. The inference service source code is locked to a commit and then compiled natively; every stage has a version anchor and SHA-256 verification, and runtime authorization is constrained by 24-hour leases signed with Ed25519. Video inference is designed to run on the local GPU of student machines, and the model weights do not leave the campus.
Chapter 02
Delivery architecture
FIG.Delivery architecture diagram
Privately Deployed AIGC Practical Training Platform for Colleges · Delivery Architecture
From locked source code to the college campus: version anchors plus SHA-256 verification link build and delivery together, and 24-hour leases signed with Ed25519 constrain runtime authorization
A layered static version is shown on mobile.
Highlight by flow
Select a flow to highlight its nodes and connections; press it again to restore everything.
- Build & delivery
- Authorization & lease
- Classroom runtime
-
01 Public control plane
-
Authorization & Delivery Control Center
Node.js 24 · node:sqlite · Ed25519 · HTTPS
Deployment & release batches · per-school build credentials · artifact verification
Server activation · heartbeat lease renewal · admin console
- Build & delivery: → Inference service compiler Builder Sends locked branch and commit
- Build & delivery: → Private artifact storage Store · read back
- Build & delivery: → Visual packaging workbench One-time wake-up link + per-school script
-
Private artifact storage
Private object storage bucket
Read-back verification after storing · transactional version switch
-
-
02 Build & release
-
Inference service compiler Builder
Windows x64 · Python 3.13 · Nuitka · Zig
Read-only pull of the locked commit, with ancestry verification
12 toolchain components hash-verified one by one
- Build & delivery: → Authorization & Delivery Control Center Release package stored after per-file verification
-
Visual packaging workbench
Electron 43 · macOS arm64
One-time wake-up via custom protocol · six-step wizard
Resumable transfer and full verification of about 66 GB of resources
- Build & delivery: → Per-school build script Isolated execution
-
Per-school build script
Separate Node 24 child process
Read-only check separated from the actual build
Outputs recorded with byte size, SHA-256 and source commit
- Build & delivery: → Student installation media, Teacher client installer, On-campus server package Each deployment must produce three outputs tagged with its deployment number
-
-
03 Deliverables
-
Student installation media
UDF ISO · single installation entry
Student client + inference service + ComfyUI + 5 model weights
- Build & delivery: → Student shell + local gateway Unified installer: SHA-256 verified while copying
-
Teacher client installer
Windows x64 · NSIS
Does not include the video model
- Build & delivery: → Teacher client
-
On-campus server package
Ubuntu 24.04 · Docker Compose
Writes the one-time activation credential
- Build & delivery: → Authorization agent Single deployment command · install after verification
-
-
04 On campus
Student machine (Windows · NVIDIA)
-
Student shell + local gateway
Electron · Windows x64
Dual server signature verification · school account check · managed launch of the inference service
- Authorization & lease: → Authorization agent Nonce challenge: dual verification of platform and server signatures · school account check
- Classroom runtime: → Local inference service Managed launch · launch credential hash proof
-
Local inference service
FastAPI compiled with Nuitka
Random port · new session token on every launch · parent process and install root checks
- Classroom runtime: → ComfyUI + MiniMax H3 open weights Loopback HTTP + WebSocket progress
-
ComfyUI + MiniMax H3 open weights
Local GPU · ≥ 11 GiB
Video inference runs locally on the student machine; model weights do not leave the campus
Teacher machine
-
Teacher client
Electron · Windows
LAN access to teaching services
- Authorization & lease: → Authorization agent Nonce challenge: dual verification of platform and server signatures · school account check
On-campus server
-
MovLab teaching service
Koa 3 · MySQL · MongoDB
Binds only to the local loopback address
-
Authorization agent
Node 24 · Ed25519
Machine fingerprint · heartbeat lease renewal
- Authorization & lease: ↔ Authorization & Delivery Control Center Activation + heartbeat lease renewal: Ed25519-signed 24-hour lease, not later than the authorization expiry date
- Authorization & lease: → MovLab teaching service Reverse proxy while the lease is valid; business access paused on expiry
-
The architecture is implemented in code; real-machine acceptance testing of Windows compilation, the complete student media, local GPU inference and the Ubuntu server is in progress. MiniMax H3 is a model released by MiniMax as open weights (MiniMax H3 Community License), not developed in-house; third-party components such as ComfyUI are distributed with the media under their own licenses.
Chapter 03 03 items
Three flows
-
01 4 steps
Build and release
- An administrator creates a deployment and a release batch for a college in the authorization center
- the authorization center issues the locked branch and commit; Builder pulls the source code on Windows, verifies the build inputs and then compiles the inference service with Nuitka, and the release package is verified file by file before being stored
- the authorization center wakes the packaging workbench with a one-time link, which runs the per-school build script in an isolated child process
- three artifacts are produced (student media, teacher installer, server package), and their byte counts, SHA-256 and source commit are recorded.
-
02 4 steps
Authorization and lease
- The server package is installed with a single deployment command (a read-only pre-check of any existing database; installation stops if it is incompatible)
- the authorization agent activates with a one-time activation credential and the machine fingerprint
- the authorization center issues an Ed25519 instance identity, with a 24-hour lease that ends no later than the authorization expiry date
- the agent renews the lease with periodic heartbeats and reports IP changes immediately; if the platform is temporarily unreachable, service continues while the lease is valid, and business access is suspended once it expires.
-
03 4 steps
Classroom runtime (designed flow)
- The student client sends a nonce challenge to the authorization agent, verifies both the platform signature and the server signature, and then verifies the school account
- it launches the local inference service under a managed protocol (random port, a new session token on every launch, hash proof of the launch credential)
- the inference service hosts ComfyUI and runs the video model on the local GPU
- generated results are synced to the on-campus cloud drive.
Chapter 04 08 items
Architecture key points
-
Every deployment must include three artifacts carrying the deployment number: student UDF installation media (a single installation entry point), a teacher-side Windows installer and an Ubuntu server package; intermediate files are cleaned up automatically to avoid mistaken installation across different colleges.
-
Local inference resources of about 66 GB (5 model weights plus the ComfyUI archive, 65,974,196,650 bytes in total): packaging supports resumable transfer, and installation computes SHA-256 while copying, writing to disk only after verification passes.
-
Two-level signature verification: the platform issues the server instance identity signed with Ed25519; the client sends a nonce challenge, the server signs the response with its instance key, and the client verifies both levels of signature.
-
Three checkpoints from source code to artifact: when Builder generates the manifest, when the platform receives the release package, and when the per-school script re-checks, Python / TypeScript source code, source maps and script files are rejected and SHA-256 is compared file by file; on the platform side, a self-written ZIP parser rejects Zip64, encrypted entries and path traversal, and verifies executable file headers.
-
Supply-chain locking: Builder verifies its 12 built-in toolchain components one by one; the toolchain archive, 24 Python wheels, the Node runtime and the source build inputs are pinned by SHA-256; once the source code has been pulled, the compile stage needs no network access (Zig is used instead of MSVC).
-
Credentials tiered by purpose: wake-up links are valid for 10 minutes and single-use, compile sessions for 24 hours, build credentials and the inference service download credentials issued with them for 7 days, and deployment tokens and desktop tool download tokens for 30 minutes; activation credentials are single-use, and a new batch automatically invalidates old credentials; tokens are stored only as SHA-256 hashes, and credentials awaiting delivery are temporarily stored encrypted with AES-256-GCM.
-
The authorization center does not depend on a web framework: native node:http + node:sqlite (12 tables), with activation, migration and version switching all done in database transactions; its only direct runtime dependency is an object storage SDK. A single read-only version anchor constrains 7 components, and the build is refused if versions are inconsistent.
-
Delivery repository size: 92 commits (all by me), 252 tracked files, about 37,000 lines including tests and build scripts, 53 test files.
Chapter 05 07 items
My work
-
Designed the entire delivery architecture in four layers (public control plane, build and release, deliverables, on campus), using a read-only version anchor and Ed25519 authorization signatures to link 7 components into a traceable delivery chain.
-
Independently developed the authorization and delivery control center (native Node.js 24 implementation): deployments and release batches, per-school build script generation, packaging sessions and compile sessions, file-by-file artifact verification and private storage, server activation, heartbeat lease renewal and migration, and the admin console.
-
Independently developed the Windows inference service compiler (Builder): pulls the locked commit read-only and verifies its ancestry, compiles a native service containing no Python source code with Nuitka on a pinned toolchain, and uploads after the manifest is verified file by file.
-
Independently developed the visual packaging workbench (Electron, macOS arm64): one-time wake-up via a custom protocol, a six-step wizard, resumable transfer and verification of about 66 GB of resources, isolated execution of per-school scripts, and cross-building of the Windows installers and UDF student media on a Mac.
-
Independently developed the Electron desktop shells for the student and teacher clients and the unified student installer (the business UI reuses the MovLab team’s front end): server discovery and dual signature verification, school account verification, managed launch of the inference service and a local gateway, environment pre-checks, and model installation with resumable download.
-
Independently developed the Ubuntu on-campus server package: Docker Compose orchestration, a single deployment command, a netplan network wizard with timeout rollback, and the authorization agent (machine fingerprint, immediate reporting of IP changes, suspension of business access when the lease expires).
-
Took part in business development of the MovLab teaching platform (a team project) and independently completed the local school edition branch: separate builds for the student and teacher clients, obfuscation of production packages, the on-campus cloud drive, and unified login.
Chapter 06
Sub-project
Local video generation workspace (based on MiniMax H3)
A local AI video generation client for students with no prior experience: it hosts a headless ComfyUI in the background, drives the MiniMax H3 open-weight video model, and simplifies the node canvas to “choose a workflow → enter a prompt → click Generate”; it offers four entry points (text-to-image, text-to-video, image-to-video and all-in-one reference) and is the AIGC engine of the student client in the delivery system above (compilation on real Windows machines is pending acceptance).
-
Managed secure runtime (by me): secure mode is hard-coded into the compiled builds, which cannot fall back to development mode; only a student client under the same installation root is accepted as the parent process; a new session token is generated on every launch, and after the port is bound exclusively, identity is proven with the SHA-256 of the launch credential; every request must carry the session header.
-
Secure release script (by me): back end compiled with Nuitka, front end obfuscated, workflows and prompt specifications compressed and embedded in the back end; before release it checks for forbidden source file extensions and verifies the file manifest, sizes and SHA-256, and replaces the release directory atomically, leaving no partial output on failure.
-
Account and on-campus cloud drive integration (by me); generation task reliability improvements (by me, later updates on the delivery branch): queue persistence, isolation of cancel and pause, recovery across workflows, retryable media delivery.
Chapter 07 09 items
Tech stack
- Node.js 24 (node:http / node:sqlite / node:crypto)
- Ed25519 · AES-256-GCM · SHA-256
- Electron 43 · electron-builder (NSIS / DMG)
- Python 3.13 · FastAPI · Nuitka (Zig toolchain)
- React 18 · TypeScript · Vue 3
- Koa 3 · MySQL 8.4 · MongoDB 8.0
- Docker Compose · Ubuntu 24.04
- ComfyUI · MiniMax H3 open weights
- Tencent Cloud COS
Chapter 08
Note
Sources and licenses
The video model is MiniMax H3, released by MiniMax as open weights (MiniMax H3 Community License; not developed in-house; this license does not apply to the European Union, the United Kingdom, South Korea and the United States); delivery uses quantized weights repackaged by Comfy-Org, and the media include the full license text and NOTICE; MiniMax is only the model provider and has no partnership or endorsement relationship with this project. Third-party components such as ComfyUI and FFmpeg are distributed with the media under their respective licenses. The editing desk and project home page UI of the video generation workspace are adapted from the open-source project LTX-Desktop (Apache-2.0).