GameFrameX Admin

All-in-One Solution for Indie Game Development · Empowering Indie Developers' Dreams

Documentation · Quick Start · QQ Group: 467608841 / 233840761

English | 简体中文 | 繁體中文 | 日本語 | 한국어

One-line positioning: an operations + publishing backend platform for indie game developers. Backend .NET 10 + SqlSugar with three hosts (Admin / Client / Hub), frontend Vue 3 + PrimeVue — a full-stack pipeline from admin login to player payment callbacks, ready out of the box.

GameFrameX Admin is a game-operations-oriented backend system: the Admin API lets operations / GM / customer service staff edit menus, query orders, push versions, and view logs; the Client API handles game-side login / payments / config fetching; the Hub API serves external systems (CI builds, Tapd WebHooks, third-party callbacks). One repository, three hosts, deployed on separate databases so they never drag each other down.

It is not a generic OA / CRM / e-commerce system. Menus, permissions, dictionaries, forms, and client configs are all designed around real "game backend" business scenarios.

This project is built on secondary development of Admin.NET; all Furion framework leftovers and original Admin.NET business naming have been replaced and rebaselined (U5 / U8 / C37–C41). Credits to the original author zuohuaijun and contributors.

Single repository (monorepo): frontend and backend live in one codebase. Since 2026-10-19, the historical sub-repositories GameFrameX.Admin.Unified.Api / GameFrameX.Admin.Unified.Vue have been frozen read-only and merged into this repository as snapshots; all new code lands here.

Admin/
├── GameFrameX.Admin.Unified.Api/    # .NET backend: Admin / Client / Hub hosts + Application / Entity / Core layers
├── GameFrameX.Admin.Unified.Vue/    # Vue frontend: PrimeVue + Pinia + vue-i18n (5 languages)
├── build/                           # Nginx config + deploy scripts (deploy-*.sh / docker-build-push.sh / entrypoint.sh)
├── doc/                             # README images
├── .github/workflows/               # CI: three API images + frontend image builds, frontend tests, external image sync
├── docker-compose.yml               # One-command full-stack orchestration (PostgreSQL + 3 APIs + frontend)
├── .env.example                     # Compose environment variable template (copy to .env and override as needed)
├── AGENTS.md / CLAUDE.md            # AI agent entry points (root instructions + readme_i18n config)
└── LICENSE.md                       # License

Suppose you want to set up an operations backend for a new game. After reading this section you should be able to go from zero to logging in and seeing the menu tree with the TeamS admin account.

• .NET 10 SDK
• Node.js ≥ 20 (20 recommended) + pnpm ≥ 11.5.2 (corepack enable)
• No database required — running from local source defaults to zero-config SQLite; production uses PostgreSQL / MySQL and 34 DbTypes in total

# 1. Get the code (single repository, frontend and backend included)
git clone https://github.com/GameFrameX/Admin.git
cd Admin

# 2. Start the backend (from the repository root! Connection strings resolve relative to the working directory)
dotnet run --project GameFrameX.Admin.Unified.Api/GameFrameX.Web.Api     # Admin API → http://localhost:20802
dotnet run --project GameFrameX.Admin.Unified.Api/GameFrameX.Client.Api  # Client API → http://localhost:20808
dotnet run --project GameFrameX.Admin.Unified.Api/GameFrameX.Hub.Api     # Hub API → http://localhost:20806

# 3. Start the frontend
cd GameFrameX.Admin.Unified.Vue
corepack enable
pnpm install
pnpm run dev    # Defaults to http://localhost:20800 (hash routing)

Open your browser → you should see the login page → account admin / password 123456 / tenant 1300000000001 (on first startup, SqlSugar Code-First automatically creates the tables and seeds the data).

docker compose up -d --build

Compose ships PostgreSQL + the three hosts (20802/20806/20808) + the Admin frontend (20800, mutually exclusive with pnpm run dev — stop the dev server before starting the containers); once the healthchecks turn green you are good to go.

Environment variable entry point: copy the root .env.example to .env and override as needed (unset variables fall back to the compose defaults; .env is not committed to git).

For finer-grained commands and pitfalls, see GameFrameX.Admin.Unified.Api/README.md (backend manual) and GameFrameX.Admin.Unified.Vue/README.md (frontend manual).

• Backend: .NET 10 + ASP.NET Core native hosting + SqlSugar (Code-First, 34 DbTypes) + JWT/HMAC + SignalR + Serilog.
• Frontend: Vue 3.5 + Vite 6 + TypeScript strict + PrimeVue 4.5 + Pinia 3 + vue-i18n (5 languages) + Axios.

For the full technology list and version matrix, see Backend README · Tech Stack and Frontend README · Tech Stack.

One repository, three hosts, deployed on separate databases so they never drag each other down: Admin API (20802, admin console), Client API (20808, game client login/payment/config), Hub API (20806, external systems / CI / WebHooks). All three share Entities and SqlSugar repositories; dependencies only point downward (Application.* / Core.* must never reference hosts back).

The Service suffix must NEVER appear in URLs. This is a trap 100% of newcomers hit — the frontend generates calls based on this convention; change the class name and the frontend breaks everywhere.

A three-layer model, from the outside in:

SuperAdmin (platform level) ── can access global config, cross-tenant queries
    ↓
Tenant (multi-tenant SaaS) ── shared across apps
    ↓
App (a specific game / product under a tenant) ── AppId scope

Multi-tenancy and database boundaries take effect automatically via entity attributes: [Tenant] automatically adds TenantId filtering + soft delete; [SystemTable] routes to the main database, [LogTable] routes to the log database, and unmarked entities route by the JWT TenantId. For details see Backend README · Repositories and Multi-Database Routing.

Grouped by "the scenarios you'll actually use", not by directory structure.

Identity & Permissions

Platform Configuration (visible to SuperAdmin only)

System Capabilities

Game Backend (76 Application.Game services)

Integrations

Frontend Framework Features

• Backend-driven menus: menus, permissions, and copy are all controlled by the backend. The frontend doesn't define menus — add them in the backend menu management; the frontend only renders the menu tree returned by the backend.
• Automatic JWT renewal: before the token from login expires, the frontend automatically adds X-Authorization so the backend silently reissues it — one login lasts a long time.
• App scopes: routes tagged with meta.appScope + meta.menuContext for the platform / tenant / app scopes; the frontend decides menu visibility based on the scope.
• i18n completeness gate: pnpm run lint:i18n checks that all 5 languages have complete keys; one missing key fails immediately.

Not "recommendations" — hard constraints that take effect by default.

Zero-config by default: running from local source defaults to SQLite (under db/ at the repository root); production uses PostgreSQL (MySQL / Oracle and 34 DbTypes in total are also supported). GameFrameX.Application/Configuration/Database.json is the single source of connection strings (shared by the three hosts — change it once and all three pick it up).

• Main / tenant / log databases are routed automatically by entity attributes (see the multi-tenancy section above).
• Tenant databases are created automatically: named gameframex_admin_tenant_<TenantId> by tenant ID, no manual connection strings needed; the default tenant database is likewise derived automatically.
• For connection-string syntax when switching databases, see Database-ConnectionStrings.md; for paired environment variable overrides (GFX_MAIN_DB_TYPE + GFX_MAIN_DB_CONNECTION_STRING) and other deployment details, see Backend README · Database.

SQLite is for local development only. Forbidden in production — weak concurrent writes, no standalone service process, and insufficient backup/restore and ops monitoring capabilities.

docker compose up -d --build
# Ships PostgreSQL + Admin(20802) + Client(20808) + Hub(20806) + frontend(20800); wait for healthchecks to turn green (the frontend container and the dev server both grab port 20800 — they are mutually exclusive)

For single-container docker run, paired environment variable overrides (a half-paired override fails fast at startup), and other details, see Backend README · Deployment.

Want to add a new CRUD service? See GameFrameX.Admin.Unified.Api/README.md → Add a New CRUD Service. In the Admin API, simply implement IDynamicApiController and you get REST endpoints automatically (Page / Add / Update / Get / List / Delete — six in total), with no Controller to write.

CI gates (anti-regression):

• ThreeHostApiRoutingContractTests — three-host routing / verbs / parameter binding / error-code semantics
• AdminEndpointReturnContractTests — Response DTO contracts
• AdminActionStyleContractTests — Admin action style conventions
• NamingAbbreviationGuardTests + NamingAbbreviationBaseline.baseline.txt — business abbreviations banned system-wide

The 5 core feature pages you see after entering a tenant app workspace. The same pages shown under Chinese and English UI languages (switch instantly via the language switcher in the top-right corner, no refresh needed):

Feature	简体中文	English
Remote Config
Version Update
Package Management
Payment Config
Ad Callback Verification

• Project documentation site: https://gameframex.doc.alianblank.com
• Backend operations manual (detailed): GameFrameX.Admin.Unified.Api/README.md
• Frontend operations manual (detailed): GameFrameX.Admin.Unified.Vue/README.md
• Issue feedback: GitHub Issues
• Client / Admin / Web repositories: see Project Repositories

See GitHub Releases for release notes.

See LICENSE.md for license information.