Skip to content

Architecture ​

Understanding how Minepanel works under the hood.

Overview ​

Minepanel is a web-based Minecraft server management panel built with modern technologies. It uses a microservices architecture where each component is containerized and communicates through well-defined interfaces.

Minepanel

Components ​

1. Frontend (Next.js) ​

Technology Stack:

Responsibilities:

  • Render the web interface
  • Handle user interactions
  • Manage application state
  • Make API calls to backend
  • Display real-time data
  • Route management

Key Features:

  • Server-side rendering (SSR) for fast initial load
  • Static generation for optimal performance
  • Client-side routing for smooth navigation
  • Real-time updates without page refresh
  • Responsive design for all devices

Directory Structure:

frontend/
β”œβ”€β”€ src/
β”‚   β”œβ”€β”€ app/              # Next.js 14 App Router
β”‚   β”‚   β”œβ”€β”€ page.tsx      # Home page
β”‚   β”‚   β”œβ”€β”€ layout.tsx    # Root layout
β”‚   β”‚   └── dashboard/    # Dashboard pages
β”‚   β”œβ”€β”€ components/       # React components
β”‚   β”‚   β”œβ”€β”€ ui/           # Base UI components
β”‚   β”‚   β”œβ”€β”€ molecules/    # Composite components
β”‚   β”‚   └── organisms/    # Complex components
β”‚   β”œβ”€β”€ lib/              # Utilities
β”‚   β”‚   β”œβ”€β”€ hooks/        # Custom React hooks
β”‚   β”‚   β”œβ”€β”€ translations/ # i18n files
β”‚   β”‚   └── types/        # TypeScript types
β”‚   └── services/         # API clients
└── public/               # Static assets

2. Backend (NestJS) ​

Technology Stack:

Responsibilities:

  • Expose REST API
  • Authenticate users
  • Manage Docker containers
  • Execute server commands
  • Monitor resources
  • Handle file operations
  • Manage server lifecycle

Key Features:

  • RESTful API design
  • JWT authentication
  • Docker integration via socket
  • Real-time log streaming
  • Error handling and validation
  • Type-safe with TypeScript

Directory Structure:

backend/
β”œβ”€β”€ src/
β”‚   β”œβ”€β”€ main.ts                    # Application entry point
β”‚   β”œβ”€β”€ app.module.ts              # Root module
β”‚   β”œβ”€β”€ auth/                      # Authentication module
β”‚   β”‚   β”œβ”€β”€ auth.controller.ts
β”‚   β”‚   β”œβ”€β”€ auth.service.ts
β”‚   β”‚   β”œβ”€β”€ jwt.strategy.ts
β”‚   β”‚   └── local.strategy.ts
β”‚   β”œβ”€β”€ server-management/         # Server management module
β”‚   β”‚   β”œβ”€β”€ server-management.controller.ts
β”‚   β”‚   β”œβ”€β”€ server-management.service.ts
β”‚   β”‚   └── dto/
β”‚   β”‚       └── server-config.model.ts
β”‚   └── docker-compose/            # Docker Compose integration
β”‚       β”œβ”€β”€ docker-compose.service.ts
β”‚       └── docker-compose.service.spec.ts
└── test/                          # Tests

API Endpoints:

typescript
// Authentication
POST   /auth/login          # Login
POST   /auth/logout         # Logout
GET    /auth/profile        # Get current user

// Servers
GET    /servers             # List all servers
POST   /servers             # Create new server
GET    /servers/:id         # Get server details
PUT    /servers/:id         # Update server
DELETE /servers/:id         # Delete server

// Server Control
POST   /servers/:id/start   # Start server
POST   /servers/:id/stop    # Stop server
POST   /servers/:id/restart # Restart server

// Server Data
GET    /servers/:id/logs    # Stream logs
POST   /servers/:id/command # Execute command
GET    /servers/:id/stats   # Get resource stats
GET    /servers/:id/players # Get online players

3. Filebrowser ​

Technology:

Responsibilities:

  • Browse server files
  • Edit configuration files
  • Upload/download files
  • Manage permissions
  • View file contents

Integration:

  • Runs as separate container
  • Accessed via iframe in frontend
  • Independent authentication
  • Direct file system access

4. Docker Engine ​

Role:

  • Container runtime
  • Resource isolation
  • Network management
  • Volume management

Docker Socket: Minepanel communicates with Docker via /var/run/docker.sock:

yaml
volumes:
  - /var/run/docker.sock:/var/run/docker.sock

This allows Minepanel to:

  • Create containers
  • Start/stop containers
  • Monitor containers
  • Read logs
  • Execute commands
  • Manage networks/volumes

Data Flow ​

Creating a Server ​

User                Frontend              Backend              Docker
  β”‚                    β”‚                     β”‚                   β”‚
  β”‚  Fill form         β”‚                     β”‚                   β”‚
  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β†’ β”‚                     β”‚                   β”‚
  β”‚                    β”‚  POST /servers      β”‚                   β”‚
  β”‚                    β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β†’β”‚                   β”‚
  β”‚                    β”‚                     β”‚  Validate input   β”‚
  β”‚                    β”‚                     β”‚  Create config    β”‚
  β”‚                    β”‚                     β”‚  Build compose    β”‚
  β”‚                    β”‚                     β”‚  docker compose   β”‚
  β”‚                    β”‚                     β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β†’β”‚
  β”‚                    β”‚                     β”‚                   β”‚ Pull image
  β”‚                    β”‚                     β”‚                   β”‚ Create container
  β”‚                    β”‚                     β”‚                   β”‚ Start container
  β”‚                    β”‚                     │◄───────────────────
  β”‚                    │◄─────────────────────                   β”‚
  │◄─────────────────────                    β”‚                   β”‚
  β”‚  Server created!   β”‚                     β”‚                   β”‚

Viewing Logs ​

User                Frontend              Backend              Docker
  β”‚                    β”‚                     β”‚                   β”‚
  β”‚  View logs         β”‚                     β”‚                   β”‚
  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β†’ β”‚                     β”‚                   β”‚
  β”‚                    β”‚  GET /logs          β”‚                   β”‚
  β”‚                    β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β†’β”‚                   β”‚
  β”‚                    β”‚                     β”‚  docker logs -f   β”‚
  β”‚                    β”‚                     β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β†’β”‚
  β”‚                    β”‚                     │◄───────────────────
  β”‚                    β”‚  WebSocket stream   β”‚  Stream logs      β”‚
  β”‚                    │◄─────────────────────                   β”‚
  │◄──────────────────────                   β”‚                   β”‚
  β”‚  Real-time logs    β”‚                     β”‚                   β”‚

Server Container Structure ​

Each Minecraft server runs in its own Docker container using itzg/docker-minecraft-server.

Container Configuration ​

Example docker-compose.yml for a server:

yaml
services:
  my-server:
    image: itzg/minecraft-server:latest
    container_name: minepanel-my-server
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
      VERSION: "1.20.1"
      MEMORY: "2G"
      MAX_PLAYERS: "20"
      DIFFICULTY: "normal"
      MODE: "survival"
      PVP: "true"
      ONLINE_MODE: "true"
    ports:
      - "25565:25565"
    volumes:
      - ./servers/my-server:/data
    labels:
      - "minepanel.server=true"
      - "minepanel.name=my-server"
      - "minepanel.type=PAPER"
      - "minepanel.version=1.20.1"
    restart: unless-stopped

Volume Mapping ​

Host                          Container
β”œβ”€β”€ servers/
β”‚   β”œβ”€β”€ my-server/           β†’ /data
β”‚   β”‚   β”œβ”€β”€ world/              World files
β”‚   β”‚   β”œβ”€β”€ plugins/            Plugins (Paper/Spigot)
β”‚   β”‚   β”œβ”€β”€ mods/               Mods (Forge/Fabric)
β”‚   β”‚   β”œβ”€β”€ server.properties   Config
β”‚   β”‚   β”œβ”€β”€ ops.json            Operators
β”‚   β”‚   └── logs/               Server logs
β”‚   └── another-server/

Labels ​

Minepanel uses Docker labels to track servers:

yaml
labels:
  minepanel.server: "true" # Identifies as managed server
  minepanel.name: "my-server" # Server identifier
  minepanel.type: "PAPER" # Server type
  minepanel.version: "1.20.1" # Minecraft version
  minepanel.created: "2024-10-24" # Creation date

Security Architecture ​

Authentication Flow ​

User β†’ Frontend β†’ Backend
                    ↓
              [Validate credentials]
                    ↓
            [Generate JWT token]
                    ↓
              [Return token]
                    ↓
        [Store in httpOnly cookie]

Security Measures:

  • Passwords hashed with bcrypt (12 rounds)
  • JWT tokens for stateless authentication
  • httpOnly cookies prevent XSS
  • CORS protection
  • Input validation and sanitization

Docker Socket Access ​

Risk: Direct access to Docker socket = root access

Mitigation:

  • Minepanel container runs with minimal permissions
  • Only necessary Docker operations allowed
  • Can use Docker Socket Proxy for additional security
  • Audit logs for all Docker operations

Optional: Docker Socket Proxy

yaml
services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      CONTAINERS: 1
      IMAGES: 1
      NETWORKS: 1
      VOLUMES: 1
    restart: always

  minepanel:
    environment:
      DOCKER_HOST: tcp://socket-proxy:2375

Network Isolation ​

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚        Docker Network: bridge        β”‚
β”‚                                      β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”‚
β”‚  β”‚ Minepanel│←──→│Filebrowserβ”‚      β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜      β”‚
β”‚                                      β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”‚
β”‚  β”‚Server 1  β”‚    β”‚Server 2  β”‚      β”‚
β”‚  β”‚(isolated)β”‚    β”‚(isolated)β”‚      β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜      β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Each server runs in isolation:

  • Cannot access other servers
  • Limited network access
  • Resource limits enforced
  • Own filesystem namespace

Storage Architecture ​

Directory Structure ​

minepanel/
β”œβ”€β”€ docker-compose.yml          # Main compose file
β”œβ”€β”€ .env                        # Environment variables
β”œβ”€β”€ servers/                    # All server data
β”‚   β”œβ”€β”€ server-1/
β”‚   β”‚   β”œβ”€β”€ world/              # World save
β”‚   β”‚   β”œβ”€β”€ world_nether/
β”‚   β”‚   β”œβ”€β”€ world_the_end/
β”‚   β”‚   β”œβ”€β”€ plugins/            # Plugins (if applicable)
β”‚   β”‚   β”œβ”€β”€ mods/               # Mods (if applicable)
β”‚   β”‚   β”œβ”€β”€ config/             # Plugin/mod configs
β”‚   β”‚   β”œβ”€β”€ logs/               # Server logs
β”‚   β”‚   β”œβ”€β”€ server.properties
β”‚   β”‚   β”œβ”€β”€ server.jar
β”‚   β”‚   └── ...
β”‚   β”œβ”€β”€ server-2/
β”‚   └── backups/                # Backup storage
β”‚       β”œβ”€β”€ server-1/
β”‚       └── server-2/
└── filebrowser-data/           # Filebrowser config
    └── filebrowser.db

Volume Strategy ​

Bind Mounts: Used for server data to allow easy access from host:

yaml
volumes:
  - ./servers/my-server:/data

Benefits:

  • Direct access from host filesystem
  • Easy backups
  • Simple file transfers
  • Debug and inspect files

Named Volumes: Could be used for better isolation (future option):

yaml
volumes:
  my-server-data:

services:
  my-server:
    volumes:
      - my-server-data:/data

Scaling Considerations ​

Vertical Scaling ​

Increase resources for existing servers:

  • Allocate more RAM
  • Add more CPU cores
  • Upgrade disk to SSD
  • Optimize JVM parameters

Horizontal Scaling ​

Run more servers:

  • Add more server containers
  • Use different ports (25565, 25566, 25567...)
  • Share resources efficiently
  • Consider network proxies (BungeeCord, Velocity)

Multi-Node Setup ​

Split services across machines (advanced):

Machine 1: Minepanel + Filebrowser
    ↓
Machine 2: Docker Engine β†’ Minecraft Servers

Use Docker's remote API:

yaml
environment:
  DOCKER_HOST: tcp://192.168.1.100:2376

Performance Optimizations ​

Backend Optimizations ​

  1. Caching

    • Cache server list
    • Cache resource stats
    • Redis for distributed cache (future)
  2. Connection Pooling

    • Reuse Docker API connections
    • Keep-alive for HTTP requests
  3. Async Operations

    • Non-blocking I/O
    • Parallel container operations
    • Background tasks for heavy operations

Frontend Optimizations ​

  1. Code Splitting

    • Lazy load routes
    • Dynamic imports for heavy components
  2. Data Fetching

    • React Query for caching
    • Prefetch data on hover
    • Stale-while-revalidate strategy
  3. Static Generation

    • Pre-render static pages
    • ISR for dynamic content

Docker Optimizations ​

  1. Image Caching

    • Keep frequently used images
    • Pre-pull common versions
  2. Resource Limits

    • Prevent resource exhaustion
    • Fair resource allocation
  3. Network Optimization

    • Custom bridge networks
    • DNS caching

Monitoring & Observability ​

Logs ​

Minepanel Logs:

bash
docker compose logs -f minepanel

Individual Server Logs:

bash
docker logs -f minepanel-my-server

Metrics ​

Container Stats:

bash
docker stats

Resource Usage:

  • CPU percentage
  • Memory usage / limit
  • Network I/O
  • Block I/O

Health Checks ​

Docker health checks monitor container status:

yaml
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

Future Enhancements ​

Planned Architecture Improvements ​

  1. Microservices Split

    • Separate auth service
    • Dedicated metrics service
    • Queue for async operations
  2. Database Integration

    • PostgreSQL for persistent data
    • Store server configs
    • User management
    • Audit logs
  3. Message Queue

    • RabbitMQ or Redis
    • Async task processing
    • Event-driven architecture
  4. Orchestration

    • Kubernetes support
    • Docker Swarm mode
    • Auto-scaling
  5. Observability

    • Prometheus metrics
    • Grafana dashboards
    • Loki for log aggregation
    • Jaeger for tracing

Technology Choices ​

Why Next.js? ​

  • βœ… Server-side rendering for better SEO
  • βœ… File-based routing
  • βœ… API routes (not used, but available)
  • βœ… Great developer experience
  • βœ… Built-in optimizations

Why NestJS? ​

  • βœ… TypeScript native
  • βœ… Modular architecture
  • βœ… Dependency injection
  • βœ… Similar to Angular (familiar patterns)
  • βœ… Extensive ecosystem

Why Docker? ​

  • βœ… Isolation and security
  • βœ… Consistent environments
  • βœ… Easy deployment
  • βœ… Resource control
  • βœ… Portability

Why itzg/minecraft-server? ​

  • βœ… Most popular MC Docker image
  • βœ… Supports all server types
  • βœ… Well-maintained
  • βœ… Extensive documentation
  • βœ… Active community

Next Steps ​

Released under the MIT License.