ShardHost

ShardHost is a control plane for managed game-server hosting. The repository contains a Java/Micronaut API, a hardened Rust node agent, a SvelteKit customer and administration interface, production-like deployment definitions, and maintained game runtime images.

Release status: production candidate. The source builds and the available unit/contract checks pass, but a paid-customer launch remains blocked until the Docker-based integration, image, restore, provider-sandbox, load and penetration gates in docs/release-checklist.md pass in the target environment.

Repository map

Path	Responsibility
server/	Java 21 / Micronaut control plane, REST API, database migrations, durable jobs, billing and administration
shard-rs/	Rust node agent, mTLS gRPC, Docker workload lifecycle, descriptor-safe file API, backup and restore execution
frontend/	SvelteKit public site, customer workspace and separated administration workspace
contracts/	Active versioned protobuf contract shared by Java and Rust
docker-images/	Maintained game runtime images eligible for the signed allowlist after CI validation
deploy/	Compose stack, reverse proxy, monitoring, alerting and systemd node unit
scripts/	Environment bootstrap, secret generation and local verification
production-readiness/	Original audit, threat model, permission model and architecture decisions
server-rs-legacy/	Read-only migration reference; not part of the production runtime

Quick verification

./scripts/bootstrap-dev.sh
./scripts/verify.sh

For a development stack:

./scripts/generate-dev-secrets.sh
cd deploy/compose
cp .env.example .env
# Set PUBLIC_URL and review every generated secret before use.
docker compose -f compose.yml -f compose.development.yml config

Production deployment is documented in docs/deployment.md. Do not expose PostgreSQL, MinIO or node gRPC to the public Internet.

Architecture principles

• deny-by-default permissions and server-side ownership checks;
• short-lived access tokens with rotating refresh-token families;
• one-time node enrollment and per-node mTLS identity;
• durable, idempotent operations instead of long-running HTTP requests;
• approved workload images identified by immutable digests;
• customer workloads treated as hostile code;
• append-oriented security audit events;
• money stored as integer minor units;
• backups are not trusted until checksum and restore verification pass;
• SFTP remains disabled; the authenticated descriptor-safe file API is the supported path.

Frontend extension model

The current product only exposes game hosting. The interface is organized around a neutral service workspace, shared design tokens and data-driven navigation, so later products such as VPS, dedicated servers or web hosting can receive their own service modules without changing the visual language or mixing their domain logic into the game-server module. No empty or misleading future-product tabs are shown today.

See docs/frontend-architecture.md.