◎
Version-aware backend
Shared application logic with client-generation-specific protocol handling at the compatibility boundary, rather than maintaining a separate backend for every Geometry Dash version.
Geometry Dash Private Server Core
Build a GDPS on one serious core.
MuchoCore is an open-source Geometry Dash Private Server foundation built around one version-aware backend. It combines client compatibility, deployment, migrations, security, administration, extensions and operational tooling instead of making every GDPS owner assemble those pieces separately.
v1.0.4 stable
1.0 → 2.2 runtime profiles
Docker ready
CI validated
Start on a VPS
$ git clone https://github.com/IZKGMD/GMDmucho-core.git
$ cd GMDmucho-core
$ sudo ./install
Open sourcePublic repository & MIT license
Version awareProtocol differences stay explicit
Operator focusedBackups, updates & diagnostics
AI-readableCanonical docs, sitemap & llms.txt
1.0–2.2Documented client generation profiles
1 coreShared domain logic across versions
PHP 8.3Current application runtime
MITOpen-source license
v1.0.4 is the current published stable release. Product discovery is host-isolated so a GDPS using MuchoCore does not automatically expose the MuchoCore marketing surface on its own domain.
What you get
A GDPS core, not just a pile of endpoints.
The goal is to keep the core maintainable while giving server owners the operational pieces they normally have to bolt on themselves.
↔
Migration tooling
Preflight an existing source database, build persistent ID mappings, then apply account, profile, level and score migrations transactionally.
⌘
Admin Control
Administration, player management, level moderation, analytics, monitoring, backups, server settings and protocol-oriented tools are available from one panel.
★
Rating Studio
Search levels, review requests, choose stars and difficulty, publish feature tiers, and keep creator-point changes inside an audited transaction.
◈
MuchoProtect
Endpoint-aware rate limits, burst protection, account/IP controls, protocol-safe blocking and privacy-aware security audit events sit before application routing.
◆
Modern admin authentication
Separate administrator accounts, RBAC, TOTP, recovery codes and WebAuthn/FIDO2 passkeys are designed for real server-owner workflows.
⌁
Persistent plugins
Keep GDPS-specific functionality outside the tracked core under custom/plugins/ so the stable updater does not overwrite your extensions.
♜
Clans
First-class GDPS-local clans with names, tags, roles, invitations, membership limits, bans, ownership transfer and in-game name decoration.
⬢
Client patching
Included Windows and Android patching workflows are designed to reduce the friction between installing a server and connecting an actual client.
Compatibility
One runtime profile, multiple Geometry Dash generations.
MuchoCore keeps version differences at the protocol boundary. You can accept all documented families or select a restricted/custom combination during deployment.
Documented runtime families
GD 1.0Legacy identity compatibility
GD 1.1Legacy endpoint family
GD 1.5Legacy GJP path
GD 1.9Legacy protocol surface
GD 2.02.x protocol family
GD 2.1Version-aware 2.1 fields
GD 2.2Modern GJP2-aware path
CustomFor example 1,19,22
The repository documents real-client verification for GD 1.0–1.9 across the listed early generations, plus a committed GD 2.2 client contract fixture. Other compatibility coverage is backed by protocol and regression tests where a separate real-client gate is not claimed.
Client-side details
Legacy 1.x endpoint namesNormalized
2.1 authenticationGJP
2.2 authenticationGJP2
Shared database/service layerYes
Separate PHP backend per versionNo
Architecture
Keep compatibility at the edge.
The central design idea is simple: clients may speak different protocol dialects, but the server should not have seven copies of the same business logic.
Request flow
Client request
↓
ClientVersion
↓
CompatibilityProfile
↓
MuchoProtect
↓
Shared Router
↓
Shared Services
↓
MariaDB
Version-specific response framing and authentication choices stay near the protocol boundary. Shared application services remain reusable across generations.
Why this matters for owners
01
Fewer moving parts
One repository, one application, one database model and one operational workflow are easier to back up and update.
02
Version-specific behavior stays explicit
Compatibility rules are documented instead of being scattered through duplicated endpoint implementations.
03
Extensions do not need core forks
Use the plugin SDK for GDPS-specific routes, events and optional database access.
04
Updates remain reproducible
Published stable releases are deployed by tag, migrations run as part of the update path, and custom plugins stay outside the tracked core.
Migration
Moving an existing GDPS should not mean starting over.
MuchoCore includes a Cvolton-oriented migration path for owners who already have accounts, levels and scores in a legacy source database.
Migration model
1
Read-only preflight
Inspect the source database without modifying it and identify migration blockers before applying anything.
2
Persistent ID mapping
Keep source-to-target identifiers stable so migrated references remain understandable and recoverable.
3
Transactional apply
Apply the migration as a transaction rather than leaving a half-migrated database behind on the first error.
4
Post-migration operation
Continue using the normal MuchoCore database and update workflow after the migration is complete.
What can move
AccountsSupported
ProfilesSupported
LevelsSupported
ScoresSupported
Source database preflightRead-only
Always back up the source database first. Migration tooling should be tested against a copy before production cutover.
Plugin SDK
Customize the GDPS without forking the core.
Custom server logic belongs under custom/plugins/. Stable core updates are intended to leave that directory untouched.
Example
custom/plugins/welcome/
├── manifest.json
└── plugin.php
plugin.php
↓
PluginInterface
↓
PluginContext
├── route()
├── on()
└── database access
Capabilities
eventsLifecycle eventsroutesGET / POST / ANYdatabasePDO accessCompatibility guardsSupported
Admin diagnosticsRead-only
The SDK is an API boundary, not a process sandbox. Review third-party plugins as executable server-side code before installation.
Deployment
From an empty VPS to a working GDPS.
01
Point a domain
Use a domain that resolves to the VPS and accepts normal inbound HTTP/HTTPS traffic.
02
Run the installer
sudo ./install prepares MariaDB, PHP 8.3, Caddy, secrets, the admin account and the chosen version profile.
03
Verify liveness
Open /health and expect the Geometry Dash-compatible body 1.
04
Patch the client
Use the included Windows or Android patching workflow and connect the patched client to your domain.
Operations
Run it like a server, not a one-off script.
✓
Backups
Use the built-in database backup helper before major maintenance.
✓
Stable release updates
Published GitHub Releases are deployed by exact tag; ordinary main-branch commits are not treated as stable releases.
✓
Secrets outside git
Database credentials, Cloud Save keys and admin bootstrap secrets are kept outside tracked source files.
✓
Validation in CI
Protocol, security, patcher, Docker and routing checks run in GitHub Actions.
FAQ
Exact answers to the questions GDPS owners ask.
This section is deliberately explicit so both humans and machine readers can understand what MuchoCore is and what it currently documents.
What is MuchoCore?
MuchoCore is an open-source Geometry Dash Private Server core. Its architecture keeps shared server logic in one application while handling client-generation differences at the protocol compatibility boundary.
Which Geometry Dash versions are documented?
The documented runtime profiles are GD 1.0, 1.1, 1.5, 1.9, 2.0, 2.1 and 2.2. A custom profile can accept any supported combination. The repository also documents real-client verification for early 1.x generations and a captured 2.2 client contract fixture.
Can I migrate from Cvolton?
Yes. The project includes a Cvolton migration path with read-only source database preflight, persistent ID mapping, and transactional migration of accounts, profiles, levels and scores. Start with the Migration Kit guide.
Can I add my own server features?
Yes. Persistent custom plugins live under custom/plugins/. Plugins can register routes, subscribe to documented lifecycle events and optionally use the MuchoCore database connection.
Does it include an admin panel?
Yes. The repository documents administration, player and level workflows, moderation, analytics, backups, server settings, Rating Studio and authentication with RBAC, TOTP and WebAuthn/FIDO2 passkeys.
How is it installed?
The supported VPS workflow is centered on sudo ./install. The installer prepares PHP 8.3, MariaDB, Caddy, the database, secrets, administrator account and the selected Geometry Dash compatibility profile.
Where is the source code?
The public source repository is github.com/IZKGMD/GMDmucho-core.
Start here
Make MuchoCore the foundation of your GDPS.
Read the setup guide, inspect the architecture, or clone the repository. The project is designed for owners who want a maintainable server core rather than a collection of disconnected fixes.