TUEO Private Deployment Manual (Xinchuang / domestic IT)

A deployment manual for delivery engineers and operations teams. TUEO private deployment is the main path: one independent, single-site, isolated installation per customer; Xinchuang-first, offline / air-gapped by default, one-click install; data stays inside the enterprise, fully auditable and rollback-capable.

1. Xinchuang and domestic IT adaptation

TUEO fully adapts to domestically produced software and hardware environments and supports deployment and operation on Xinchuang hardware, domestic CPU architectures, domestic GPU accelerator cards, and Xinchuang operating systems, meeting the security-and-controllability compliance requirements of key industries such as party and government, public security, government, energy, and finance:

• Domestic CPU architectures: supports mainstream domestic CPUs (x86 and ARM ecosystems) as control-plane and compute nodes;
• Domestic GPU accelerator cards: supports domestic GPUs for model inference and vector-search acceleration, operable in a fully intranet environment;
• Xinchuang operating systems: adapted to mainstream domestic Linux distributions, compatible with their software repositories and kernel baselines;
• Xinchuang validation: deployment validated in key industries such as public security and government, meeting MLPS and classified-protection requirements.

The platform is also compatible with general-purpose x86 servers and standard Linux distributions, and the delivery form is configurable: a fully domestic stack (Xinchuang hardware + domestic GPU + Xinchuang OS) or a general-purpose stack can both be deployed with one click.

2. Deployment forms and architecture

2.1 Three delivery forms

2.2 Layered architecture

L3 Products and middleware    identity · cohort · studio · capabilities · executor
                              + PG / Redis / MinIO / knowledge base / IM / model gateway
L2 Operations platform        TUEO Console (configuration center · logs · status wall · deployment orchestration · backup · audit)
L1 Base                       Harbor intranet image registry · database high availability · certificates · gateway
L0 Cluster base               k3s HA · intranet cache layer · image proxy
Compute layer                 multi-model compute servers — independent compute nodes that uniformly deploy and manage models
L-1 OS baseline               domestic / general-purpose operating system · kernel baseline · software repository acceleration

Multi-model compute servers are independent compute nodes in the deployment architecture, dedicated to deploying models:

• Uniformly hosting multiple models: large language model inference, vector embedding, and vision / speech models can be deployed and scheduled on demand on the same compute node;
• Domestic / general-purpose accelerator cards: supports domestic GPUs and general-purpose accelerator cards; model inference and vector search are fully completed on the intranet;
• Uniformly managed by the platform: model services are registered and deployed by the operations platform, model keys never leave the server, and invocation is uniformly routed through the intranet model gateway;
• Independently scalable: compute nodes can be scaled out separately according to business size without affecting control-plane or business nodes.

Key point: the base (database / cache / container base / object storage / model compute) is itself a managed object uniformly managed by the operations platform, not third-party infrastructure maintained by another team. The platform is even a managed object of itself (self-upgrade only swaps images; the genesis manifest remains the single source of truth forever).

3. Deployment phases (directory order)

Deployment uses replayable scripts + a site manifest, from bare metal to a production environment, without hand-typing SSH:

After deployment, the 00 Preflight script doubles as an acceptance health check that can be re-run at any time.

4. Site manifest (declarative configuration)

Each customer site has one site/<name>.yaml, read parameterically by the scripts, zero hardcoding:

• Site: name, domain suffix, timezone;
• Network: Pod / service CIDRs, node subnet, gateway, DNS, public entry, out-of-band management network;
• Sources: offline bundle path or image URL (air-gapped sites use the offline bundle);
• Access: jump host, SSH credential references (plaintext never stored);
• Nodes: hostname, intranet IP, role (control plane / compute / multi-model compute), hardware specs and hard constraints;
• Compute: accelerator-card type and count (domestic or general-purpose), plus the model list to deploy and resource reservations.

5. Offline and air-gapped deployment

Air-gapped (fully disconnected) is the default capability, not an option:

• Offline image delivery: build and package images in a connected environment → load them on site into the intranet image registry → the cluster pulls them, zero docker on nodes;
• Offline bundle: package the container base, images, and system packages into an offline bundle, carried in at one go for air-gapped sites;
• Intranet cache: image proxy + software repository cache; on a slow public network (e.g., only 0.5MB/s), each dependency crosses the slow link only once;
• Offline updates: .tueoupdate signed update packages are verified, then imported; the catalog segment goes to the capability platform, the image segment is loaded into the intranet registry, and unsigned packages are always rejected;
• Offline licensing: signed License activates with zero network access; a soft node lock prevents copying to multiple deployments.

6. Operations manual

After deployment, all operations are completed in one interface: TUEO Console:

Platform self-upgrade: pushing code auto-builds → images promote → swap image → liveness convergence; upgrades only change image tags and never re-render the genesis manifest (data volumes / master keys / gateway all preserved).

7. Security and compliance

• Data never leaves the enterprise: all components deployed on the intranet; models can go through the customer’s own managed gateway or local models; keys never leave the customer network;
• Multi-tenant physical isolation: database row-level security + explicit tenant filtering at the service layer, a dual defense;
• Audit trail: cryptographic hash-chain auditing, tamper-detectable; sensitive operations require a second confirmation + approval flow;
• Defense in depth: OIDC single sign-on, converged roles, encrypted credential vault, network-isolated sandbox, content-safety gate;
• Xinchuang compliance: site-wide private deployment, meeting MLPS, classified-protection, and key-industry compliance requirements.

8. Delivery checklist

Questions about deployment, or need joint tuning for a Xinchuang environment, contact the TUEO delivery team.