Delivery System for a Privately Deployed AIGC Practical Training Platform for Colleges

Status
In development : the authorization and delivery control center is running in a public HTTPS environment (the online version predates the code described here); real-machine acceptance testing is in progress, and no college has officially gone live yet
Role
Independent design and development of the delivery repository (assisted by AI coding assistants); the local video generation workspace is a multi-person collaborative project, and I am responsible for its delivery branch; the MovLab teaching system is a team project, and I completed the local school edition branch
Period
2026.08 – present

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.

01 Public control plane 02 Build & release 03 Deliverables 04 On campus Student machine (Windows · NVIDIA) Teacher machine On-campus server 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 Private artifact storage Private object storage bucket Read-back verification after storing · transactional version switch 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 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 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 Student installation media UDF ISO · single installation entry Student client + inference service + ComfyUI + 5 model weights Teacher client installer Windows x64 · NSIS Does not include the video model On-campus server package Ubuntu 24.04 · Docker Compose Writes the one-time activation credential Student shell + local gateway Electron · Windows x64 Dual server signature verification · school account check · managed launch of the inference service Local inference service FastAPI compiled with Nuitka Random port · new session token on every launch · parent process and install root checks 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 client Electron · Windows LAN access to teaching services MovLab teaching service Koa 3 · MySQL · MongoDB Binds only to the local loopback address Authorization agent Node 24 · Ed25519 Machine fingerprint · heartbeat lease renewal Sends locked branch and commit → ← Release package stored after per-file verification Store · read back One-time wake-up link + per-school script Isolated execution Each deployment must produce three outputs tagged with its deployment number Unified installer: SHA-256 verified while copying Single deployment command · install after verification Activation + heartbeat lease renewal: Ed25519-signed 24-hour lease, not later than the authorization expiry date ← Reverse proxy while the lease is valid; business access paused on expiry Nonce challenge: dual verification of platform and server signatures · school account check Managed launch · launch credential hash proof Loopback HTTP + WebSocket progress
  • Build & delivery
  • Authorization & lease
  • Classroom runtime
  1. 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

    • Private artifact storage

      Private object storage bucket

      Read-back verification after storing · transactional version switch

  2. 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

    • 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

    • 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

  3. 03 Deliverables

    • Student installation media

      UDF ISO · single installation entry

      Student client + inference service + ComfyUI + 5 model weights

    • Teacher client installer

      Windows x64 · NSIS

      Does not include the video model

    • On-campus server package

      Ubuntu 24.04 · Docker Compose

      Writes the one-time activation credential

  4. 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

    • Local inference service

      FastAPI compiled with Nuitka

      Random port · new session token on every launch · parent process and install root checks

    • 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

    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

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.

Delivery architecture: four layers, namely the public control plane, build and release, deliverables, and on campus (the architecture is implemented in code; real-machine acceptance testing is in progress). Solid cyan lines are build and delivery, dashed orange lines are authorization and lease, and blue is classroom runtime

Chapter 03 03 items

Three flows

  1. 01 4 steps

    Build and release

    1. An administrator creates a deployment and a release batch for a college in the authorization center
    2. 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
    3. the authorization center wakes the packaging workbench with a one-time link, which runs the per-school build script in an isolated child process
    4. three artifacts are produced (student media, teacher installer, server package), and their byte counts, SHA-256 and source commit are recorded.
  2. 02 4 steps

    Authorization and lease

    1. 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)
    2. the authorization agent activates with a one-time activation credential and the machine fingerprint
    3. the authorization center issues an Ed25519 instance identity, with a 24-hour lease that ends no later than the authorization expiry date
    4. 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.
  3. 03 4 steps

    Classroom runtime (designed flow)

    1. 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
    2. 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)
    3. the inference service hosts ComfyUI and runs the video model on the local GPU
    4. generated results are synced to the on-campus cloud drive.

Chapter 04 08 items

Architecture key points

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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).

  6. 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.

  7. 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.

  8. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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).

  7. 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)

Role
Responsible for productization, secure release and delivery integration of the delivery branch (a multi-person collaborative project; the repository and the base version were created by a collaborator)

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).

  1. 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.

  2. 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.

  3. 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).

Next project 07 / 07

AI E-commerce Video Generation System

In development