A developer publishing as quonaro has released two linked open-source tools for running modded Minecraft servers with small groups: MiniMin, a self-hosted web panel that manages servers in Docker and exports client modpack archives, and MiniMin Sync, a desktop client that installs and updates those archives on a friend's machine. The author describes the project as a personal fix for a recurring problem rather than a polished product, writing that it carries "no enterprise / clean-code claims" and that part of the code was AI-assisted, naming Devin and Kimi K2.6 as tools used.
The problem the author describes is a familiar weekend-session loop: someone starts a server, mods are copied by hand, a client build is zipped and dropped into Discord, and then one participant has the wrong version, another crashes, and a third does not update. MiniMin is intended to replace that with a browser panel where the server is created or updated and a client archive is generated, after which friends receive a single link. The author frames the division of responsibility as the server side owning how the build is assembled and the client side owning how not to break the player.
MiniMin runs as a single container combining a Go backend with an embedded frontend behind Caddy. It supports multiple servers from one dashboard with start, stop, restart and monitoring, and orchestrates one Docker container per server through the Docker API, based on the itzg/minecraft-server image. The panel mounts the host Docker socket and maps volumes to the host; the author states explicitly that this arrangement is not appropriate for a SaaS deployment but is acceptable for home self-hosting.
Supported server engines are listed as VANILLA, FABRIC and FORGE only. NeoForge is aliased to FORGE and Quilt to FABRIC, and version data comes from Mojang, Paper, meta.fabricmc.net and Forge's promotions_slim.json, with no separate NeoForge or Quilt API. The author asks readers directly whether honest NeoForge and Quilt support with separate loader versions is needed or whether aliasing is sufficient, which indicates the current behaviour is a deliberate simplification rather than a finished integration.
Beyond server lifecycle, the panel offers browser-based file management for browsing, uploading, downloading and editing configs, live logs and an RCON console over WebSocket, and player management covering online status, bans, op and whitelist. Mod handling covers installing, removing, enabling and disabling both server and client mods, including mods-client jars, resourcepacks, shaderpacks and disabled files. Search and metadata come only from Modrinth; there is no CurseForge API integration. Crash reports and resources get their own tabs.
Client archives can be exported in four formats: zip, mrpack, curseforge and prism. The zip format is a plain mods, resourcepacks and shaderpacks layout. The mrpack export is described as simplified, using FormatVersion 1 and VersionID 1.0.0 with empty hashes and no dependencies. The curseforge export is manifest.json with minecraftModpack plus overrides, and is export-only rather than an API integration. The prism format is the one Sync consumes, containing instance.cfg, mmc-pack.json, a .minimin.json marker holding serverId, token and baseUrl, and files under .minecraft/mods. The panel also exposes /info, /manifest with SHA-256 hashes, and /file/{path} endpoints used for differential syncing.
Scheduled backups already exist through a scheduler that accepts interval, cron or event triggers and a backup action with keepLast and keepDays options, but only the world directory is archived to tar.gz, with save-off and save-all issued over RCON. There is no multi-user support: a single static ORCHESTRATOR_API_KEY is used for Bearer, cookie and query authentication. The author also notes there is no OpenWrt build. The frontend is Nuxt 4 with Vue 3 and TailwindCSS; the backend is Go with the Docker SDK, exposing REST and WebSocket.
MiniMin Sync is a separate Wails application built with Go, Vue 3 and Tailwind rather than Electron. It works only with the prism format link, downloads the archive, extracts it with Zip Slip protection, and writes a .minimin.json marker recording serverId, token, baseUrl and lastSyncAt. Update checking diffs local files against the server manifest and classifies them as missing, outdated by size or SHA-256 mismatch, or orphaned, where orphans are extras found only at the top level of mods, resourcepacks, shaderpacks, scripts, kubejs and defaultconfigs.
Applying an update downloads only changed files using four workers, renames replaced files into a .minimin-backup directory, checks free disk space, verifies SHA-256 after writing, and rolls back on mismatch. Background checking runs only while the app is open, with an autoCheckLoop every five minutes by default; there is no OS autostart and no tray icon. Launcher support is hardcoded to three options: Prism Launcher, ElyPrismLauncher and MultiMC, located via standard paths and PATH, launched with --launch <serverID> and fallbacks. The client is described as knowing nothing about game or loader versions and simply mirroring files from the server.
Installation requires only Docker and Docker Compose. The documented steps fetch a compose file and an env template, then require editing .env to set ORCHESTRATOR_API_KEY and MC_SERVERS_HOST_DIR before running docker compose up -d and opening the panel on localhost:8081. Optional variables include ORCHESTRATOR_LOG_LEVEL, MC_SERVERS_DIR and MODRINTH_CUSTOM_URL. A dev.yml with hot reload is provided, running the frontend on port 3000 and the backend on 8081.
The author closes with an explicit list of open questions rather than a roadmap. These include whether the full Modrinth format with hashes and dependencies is needed or whether prism plus zip is enough, whether importing foreign mrpack or CurseForge packs matters, whether honest NeoForge and Quilt support is required, and which of autostart with tray, a headless daemon without a GUI, or broader launcher support is most valuable. The author also asks whether full server backups including mods and configs are needed beyond the world directory, whether multi-user support is required given the single API key, and whether documentation for weak hardware or OpenWrt would be interesting.
For developers and freelancers who run small multiplayer servers for clients, teams or communities, the interesting part is the pattern rather than the game: a server-side manifest with per-file hashes, a thin client that diffs against it, and a marker file that ties an installed instance to a source. That is the same shape as asset or dependency distribution in other projects, and the author's decision to keep the client ignorant of loader versions pushes all build logic to one place. The tradeoff is that the panel becomes a single point of configuration, and the Docker socket mount means the host running it should be treated as trusted.
Several limitations are stated by the author and should be read as such. The mrpack export omits hashes and dependencies, NeoForge and Quilt are aliases rather than real integrations, backups cover only the world directory, authentication is a single shared key with no multi-user model, and the sync client checks for updates only while its window is open, with no autostart, tray or headless mode. Launcher support is limited to three named launchers. The author presents the project as self-hosted and personal, and no independent testing, adoption figures, pricing or support commitments are provided in the sources.
The practical question for anyone considering it is whether the current scope matches their setup. A group already using Prism or MultiMC, running Docker on a home machine, and willing to accept a single shared key and world-only backups could plausibly replace manual zip distribution with the link-and-sync flow the author describes. Groups needing NeoForge or Quilt with distinct loader versions, CurseForge imports, multi-user access control or unattended background updates would be waiting on features the author has listed as open questions rather than commitments.
What remains unknown is how the tools behave outside the author's own environment. The sources contain no benchmarks, no reports from other users, and no indication of how the panel handles concurrent server operations or large modpacks. The author's invitation to clone the repositories, run them and report what breaks first is itself an acknowledgement that the software is early. Treat the feature list as a description of current behaviour by its author, not as a verified capability set.