MinePanel

Self-hosted Minecraft server management, the right way.

A single docker-compose up brings up the stack on your own machine. No cloud lock-in. Full control.

Hosted dashboard for your self-hosted MinePanel instance.

Usable today. Still being built.

[ EARLY ACCESS ]

MinePanel is already running.

You can self-host the panel today on your own hardware. The hosted dashboard is a client for self-hosted instances; MinePanel does not host your Minecraft servers for you.

  • Docker deployment with PostgreSQL and Caddy HTTPS
  • Account authentication, sessions, TOTP 2FA, and optional Google sign-in
  • Create, start, stop, restart, and delete Minecraft servers
  • Per-server OPEN, REQUEST, and PRIVATE access controls
  • Admin host metrics over authenticated WebSocket connections

[ ACTIVE DEVELOPMENT ]

More operations are on the roadmap.

The foundation is usable, while the operational surface is still expanding. Current roadmap work includes:

  • Richer real-time events and server console operations
  • Backups and scheduled tasks
  • File and plugin management
  • Velocity proxy and Bedrock networking

Core Features

One-Command Deploy

The full stack - backend, database and MC servers - runs on your hardware with a single command. Zero external dependencies.

🐳

Docker-Native

Each Minecraft server runs in its own isolated container, controlled through a local Docker socket (rootful by default; rootless via DOCKER_SOCKET).

🛡️

Role System

Three roles: ADMIN, MOD, USER. MODs get granular per-server permissions without full admin access - built-in PBAC.

📡

Real-Time Events

Host metrics (CPU, RAM, disk) pushed to admins via WebSocket. Live per-server stats, console logs, and player events land in later phases.

🔒

Security First

JWT via HttpOnly cookies, rate limiting, Helmet security headers, input validation, and Docker socket guardrails.

[ Future phases ]
🔗

Multi-Backend

Point the frontend at independent self-hosted backends. CHIPS Partitioned cookies are the primary cross-origin mechanism where supported; the PKCE fallback remains reserved.

📱

Mobile App

KMP app for iOS and Android. Not just for admins - players get their own portal: server status, access requests, push notifications, and profile.

👤

Player Portal

Unlike other MC panels, MinePanel is built for players too. Browse your servers, request access, view your Minecraft profile and playtime - all in one place.

Tech Stack

TypeScript 5NestJS v11Bun 1.3PostgreSQL 16Drizzle ORMDocker / DockerodeCaddy (auto-HTTPS)JWT · HttpOnly Cookies2FA · TOTPSocket.IO (WebSocket)Helmet · ThrottlerRCON via docker exec (rcon-cli)GitHub Actions CI/CD

[ Quick Deploy ]

# Download deployment assets for the current edge channel
curl -fsSLo docker-compose.yml https://raw.githubusercontent.com/MinePanelProject/minepanel-backend/master/docker-compose.yml
curl -fsSLo .env.example https://raw.githubusercontent.com/MinePanelProject/minepanel-backend/master/.env.example
curl -fsSLo Caddyfile https://raw.githubusercontent.com/MinePanelProject/minepanel-backend/master/Caddyfile
cp .env.example .env

# Set required values in .env, then use pre-stable edge
sed -i 's|^MINEPANEL_IMAGE=.*|MINEPANEL_IMAGE=ghcr.io/minepanelproject/minepanel-backend:edge|' .env
docker compose pull
docker compose up -d

Edge is the current pre-stable channel; no stable release is published yet. Requires Docker Engine with Compose, a domain, open ports 80/443, configured secrets, and Minecraft data storage.

[ Full deployment guide ]

Team

Roadmap

  • Completed
  • In Progress
  • Planned
  • Future

[ Backend / Core API ]

1

The current NestJS foundation: authentication, authorization, server lifecycle, Docker deployment, host metrics, and release automation.

  • JWT auth via HttpOnly cookies
  • Register & login endpoints
  • Token refresh & logout
  • Session management (list & revoke)
  • Password change and forced recovery
  • Rate limiting and security validation
  • Health and protocol-1 capability endpoints
  • Transactional first-admin bootstrap
  • Roles, account status, and MOD PBAC
  • 2FA — TOTP with backup codes
  • Admin user management and last-admin protection
  • Docker service and managed-container guardrails
  • Server lifecycle and graceful RCON stop
  • Resource admission and startup reconciliation
  • Server visibility and access request workflow
  • Requestable server discovery
  • Host metrics via WebSocket
  • Unit + PostgreSQL e2e tests
  • CI/CD pipeline + GHCR edge/stable release channels
  • Docker deployment (Compose + Caddy + boot migrations)

100% complete

2

With documentation authority reconciled, stabilize the API protocol, close resource-isolation gaps, and add trusted lifecycle coverage before stable v1.

  • Stable API error envelope, machine codes, and request IDs
  • Resolve password semantics and bcrypt UTF-8 byte limits
  • Delete or wire dead login-throttle environment variables
  • Progressive login-abuse throttling using account + source context
  • Minecraft CPU quota and PIDs limit
  • Reproducible Minecraft image strategy
  • Trusted real-Docker lifecycle CI
  • Hosted-browser PKCE fallback if required

Next milestone

3

The core Phase 1.5 scope is complete: Google OAuth and the server authorization spine are shipped. Optional/deferred onboarding integrations remain future work and do not gate backend feature completion.

  • Google OAuth with challenge-bound local verification
  • Google account linking with explicit confirmation
  • Server visibility: OPEN / REQUEST / PRIVATE
  • Access request and approval workflow
  • Requestable server discovery
  • MOD granular permissions (PBAC per server)
  • [Optional] GitHub OAuth
  • [Optional] Invitation and alternate registration modes
  • [Optional] Magic-link authentication when SMTP is enabled
  • [Deferred] Microsoft Minecraft account linking
  • [Deferred] Offline player UUID linking

Core scope complete; optional/deferred follow-ons remain

4

Framework-neutral foundations for operations and integrations. API keys and webhooks do not block core Minecraft management.

  • Append-only audit log
  • Framework-neutral system-event model
  • Add a scheduler when a real feature first requires it

Starts after stable-v1 foundation

5

The core operations suite, delivered as concrete product requirements and security boundaries are established.

  • RCON / console command broker (Docker-exec default)
  • Real-time server logs, stats, and player events
  • Backup and restore
  • Scheduled tasks
  • Controlled filesystem-write architecture
  • File manager
  • Player management
  • Plugin and mod management
  • Notifications

Planned

6

Later consumers of the platform foundations; these do not gate core server management.

  • API keys
  • Outbound webhooks
  • External integrations
  • System-event consumers
7

Deferred product surfaces with intentionally unresolved designs.

  • Creation presets and server wizard
  • Mod-loader and mod selection
  • Velocity networking
  • Geyser / Bedrock support
  • Mobile app and player portal
8

Post-feature-completion, parity-first migration from NestJS when Elysia 2 and its required Bun ecosystem are stable. No migration preparation is planned now.

  • Complete and freeze the final NestJS feature baseline
  • Document deferred functionality and synchronize all docs
  • Establish stable API/error contracts and black-box HTTP/WS conformance
  • Add trusted real-Docker lifecycle coverage
  • Verify Elysia 2 ecosystem reliability on the selected Bun runtime
  • Port with route, status, body, auth, cookie, DB, Docker, and WS parity

[ live data - last updated: 2026-08-27 ]