robojerk/stronghold
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
stronghold/references/SUMMARY.md
robojerk c31e48e2b1 Proof of concept: Container management with FastAPI backend 
- FastAPI backend with REST API endpoints
- SQLite database for container metadata
- Docker/Podman SDK integration with label filtering
- Frontend: Server creation form and management page
- Container operations: create, list, start, stop, delete
- Single container deployment (nginx + Python + supervisor)
- Support for Docker and Podman (rootless)
- Volume management for persistent data
2025-10-31 11:50:31 -07:00

3.6 KiB
Raw Permalink Blame History

Reference Projects Summary

This directory contains detailed analysis of reference projects for the Stronghold Minecraft server management tool.

Files

  1. itzg-projects.md - Core Docker projects by itzg that Stronghold will integrate with:

    • docker-minecraft-server
    • docker-mc-proxy
    • mc-router
    • docker-rcon-web-admin

  2. server-managers.md - Existing web-based server management tools:

    • Crafty (CraftyControl)
    • Pterodactyl Panel
    • Fork (ForkGG)
    • MCSManager
    • setupmc.com

  3. launchers.md - Client-side launchers with excellent modpack workflows:

    • ATLauncher
    • Prism Launcher

  4. examples/ - Docker Compose example files from itzg repository:

    • docker-compose-big.yml (Large Biomes world type)
    • docker-compose-curseforge-atm7.yaml (All The Mods 7 modpack)
    • docker-compose-curseforge.yml (Basic CurseForge example)
    • docker-compose-magma.yml (Hybrid mods + plugins)
    • docker-compose-rconcmd.yml (Advanced RCON commands)
    • EXAMPLES-ANALYSIS.md (Detailed analysis of each example)

Key Insights

Architecture Recommendations

  • Keep it simple (KISS): Docker API directly, no agents/daemons needed initially
  • Start without database: Use file-based configuration, add database later if needed
  • Node.js stack: Could work well (like MCSManager but simpler)
  • Single-host focus: Start with single Docker host, expand later

Feature Priorities

  1. Server CRUD: Create, read, update, delete servers
  2. Configuration UI: User-friendly interface for itzg container environment variables
  3. Console Access: RCON integration for server management
  4. File Browser: Access server files (worlds, configs, mods)
  5. Modpack Support: ATLauncher-like experience for server creation

Technical Stack Suggestions

  • Backend: Node.js/Express or Python/FastAPI
  • Frontend: React, Vue, or SvelteKit
  • Docker: Direct Docker API integration
  • Storage: File-based configs initially, optional database later
  • APIs: Modrinth, CurseForge for modpack integration

UI/UX Principles

  • Take inspiration from Crafty and Fork for clean, intuitive interfaces
  • Follow ATLauncher's model for modpack installation simplicity
  • Use setupmc.com as reference for configuration UI patterns
  • Prioritize common workflows over advanced features

Implementation Phases

MVP (Phase 1)

  • Basic Docker integration
  • Simple server creation/management
  • Basic web UI
  • Console access

V1.0 (Phase 2)

  • Full configuration UI
  • File browser
  • Modpack installation (basic)
  • Proxy server support

V1.5+ (Phase 3)

  • Modpack browser
  • Advanced features
  • Templates/presets
  • Backup system
  • mc-router integration

Notes on Reference Projects

Most Relevant

  1. itzg/docker-minecraft-server: Core technology Stronghold will use
  2. itzg examples: Real-world docker-compose configurations showing patterns and edge cases
  3. setupmc.com: Shows how to simplify Docker config generation
  4. ATLauncher: Target UX for modpack installation
  5. Crafty: Good UI/UX patterns to follow

Study but Don't Copy

  1. Pterodactyl: Too complex, but has good separation of concerns
  2. MCSManager: Good architecture ideas, but agent model overkill for Docker
  3. Fork: Great UX, but Windows-focused

Questions to Resolve

Based on these references, Stronghold needs to decide:

  1. Tech Stack: Node.js vs Python vs Go?
  2. Database: Start with files or include database from start?
  3. Multi-user: Single-user MVP or multi-user from start?
  4. Deployment: Single container, docker-compose, or microservices?
  5. Modpack APIs: Which to support first (Modrinth, CurseForge, both)?