SCOPENET-MC/docs/admin-guide.md

Admin guide

Deploying the panel

cp .env.example .env         # set ADMIN_PASSWORD
docker compose up -d
docker compose logs -f panel # first start prints the admin account

Everything the panel stores lives in the panel-data volume (/data):

Path	What
panel.db	SQLite database (users, instances, settings, stats)
files/<instance>/	Configs and uploads hosted for launchers
uploads/	Logos, backgrounds, icons
jwt.secret	Token signing key (unless JWT_SECRET is set)

Backups: stop the container (or use sqlite3 panel.db ".backup backup.db") and copy the volume.

Updating: docker compose pull && docker compose up -d. Database migrations run automatically.

HTTPS

Launchers talk to the panel over the internet, so serve it over HTTPS. Example with Caddy:

panel.example.com {
    reverse_proxy localhost:8080
}

Large modpack uploads go through the proxy — raise its body-size limit if needed (nginx: client_max_body_size 2g;).

Instances

An instance = one playable profile: a Minecraft version, an optional mod loader, files (mods, configs…) and an optional server.

• Version — choose any Minecraft version and Vanilla / Fabric / Quilt / Forge / NeoForge. Leave the loader version empty for the latest recommended build (it's pinned when you save).
• Modrinth — search, pick a version, Use. Mods are downloaded by players straight from Modrinth's CDN; configs (overrides/) are hosted by the panel.
• CurseForge — needs a free API key from console.curseforge.com (Settings → Integrations, or CURSEFORGE_API_KEY). Some authors block third-party downloads; those files show up under Files with a link — download them yourself and upload them into the same folder.
• Upload .zip — a .mrpack, a CurseForge export, or any zipped instance folder (with mods/, config/, … or a .minecraft/ inside). For plain zips, pick the Minecraft version and loader.
• Files — add or remove individual files at any time. Files players add themselves are never touched; files you remove are deleted from players' instances on their next launch.

Every save bumps the instance revision; launchers re-verify files when it changes, otherwise launching is instant.

Built-in server

On the Server tab: name, address, port.

• Add to multiplayer list writes the server into servers.dat (keeping servers players added).
• Join automatically connects on start (Quick Play on 1.20+, --server on older versions).

Your server must allow the accounts you use: offline-mode (online-mode=false) for panel/offline accounts, or online-mode for Microsoft accounts. Protect offline-mode servers with a whitelist or an auth plugin.

Access

• Everyone — any launcher, including offline and Microsoft accounts.
• Signed-in players — any panel account.
• Specific groups — members of the selected groups (create groups on the Players page). Admins see everything.

Players

• Sign-ups: Settings → Closed (admins create accounts), Needs approval, or Open.
• Panel accounts play under their username with the offline-mode UUID an offline server computes, so inventories and permissions stay consistent.
• Disabling an account signs it out everywhere on the next request.
• Ten failed logins lock an account for five minutes.

Launcher design

Everything on this page is pushed to launchers when they start or refresh — no reinstall. The Features tab lets you allow or block players from changing the theme or Java settings. Custom CSS is injected last; handy variables are --accent, --accent-2, --surface, --radius.

Releasing the launcher

See the README's Build your branded launcher. Players get updates automatically: the launcher checks GitHub Releases on start and offers the new installer.

Code signing: unsigned installers trigger a Windows SmartScreen warning ("More info → Run anyway"). To avoid it, sign the installer with a code-signing certificate (e.g. Azure Trusted Signing) — Tauri supports this via bundle.windows.signCommand.