Catalyst #2 - Gemini consultation: Server mod automation module
- Proposing Trinity Console module for automating server-side mod deployment - Current pain point: 2-3 hours manual config per new server - Goal: Reduce to 15-30 minutes via template system - 7 specific architectural questions for Gemini - Includes technical challenges and proposed solutions
This commit is contained in:
Catalyst
@@ -0,0 +1,212 @@
|
||||
# Gemini Consultation: Trinity Console Server-Side Mod Automation Module
|
||||
|
||||
**Date:** April 9, 2026
|
||||
**From:** Holly (The Catalyst) + Claude (Catalyst #2)
|
||||
**To:** Gemini (Architectural Partner)
|
||||
**Re:** Automating server-side mod installation and configuration
|
||||
|
||||
---
|
||||
|
||||
## Hey Gemini! 👋
|
||||
|
||||
Holly here with a workflow pain point that's begging for automation. Every time we add a new Minecraft server to the fleet (and we have 13+ running), we manually install and configure the same server-side mods on each one. It's tedious, error-prone, and takes Holly away from creative building work.
|
||||
|
||||
We're thinking about adding a module to Trinity Console (Arbiter 3.0) to automate this. Before we dive in, we'd love your architectural guidance.
|
||||
|
||||
---
|
||||
|
||||
## Current Workflow (Manual)
|
||||
|
||||
**When deploying a new modded Minecraft server:**
|
||||
|
||||
1. Create server in Pterodactyl Panel
|
||||
2. Upload modpack
|
||||
3. **Manually upload server-side mods** (same set every time)
|
||||
4. **Manually configure each mod** (config files, permissions)
|
||||
5. Set up LuckPerms
|
||||
6. Configure Discord integration
|
||||
7. Test and launch
|
||||
|
||||
**Steps 3-4 are repetitive and identical across servers.**
|
||||
|
||||
---
|
||||
|
||||
## What We Want to Automate
|
||||
|
||||
**Common server-side mods we install on every server:**
|
||||
- LuckPerms (permission management)
|
||||
- EssentialsX (commands, warps, homes)
|
||||
- Vault (economy/permission bridge)
|
||||
- WorldEdit (building tools for Holly)
|
||||
- CoreProtect (rollback/logging)
|
||||
- DiscordSRV (Discord integration)
|
||||
- TAB (player list formatting)
|
||||
- Chunky (pre-generation)
|
||||
- [Plus modpack-specific mods]
|
||||
|
||||
**Each mod has:**
|
||||
- JAR file (downloaded from CurseForge, Modrinth, or SpigotMC)
|
||||
- Configuration files (YAML, JSON, or properties)
|
||||
- Some need initial setup (database connections, API keys)
|
||||
|
||||
---
|
||||
|
||||
## Proposed Architecture
|
||||
|
||||
### Trinity Console Module: "Server Template Manager"
|
||||
|
||||
**User Flow:**
|
||||
1. Holly logs into Trinity Console
|
||||
2. Goes to "Server Templates" module
|
||||
3. Selects a template (e.g., "Standard Survival", "Creative Build", "Pokerole RPG")
|
||||
4. Template contains:
|
||||
- List of mods with versions
|
||||
- Pre-configured config files
|
||||
- LuckPerms groups/permissions export
|
||||
- Discord webhook settings
|
||||
5. Clicks "Deploy to Server" → selects Pterodactyl server
|
||||
6. Trinity Console:
|
||||
- Downloads mods via Pterodactyl API (file upload)
|
||||
- Uploads config files to /config/
|
||||
- Restarts server
|
||||
- Validates installation
|
||||
|
||||
**Template Structure (JSON/YAML):**
|
||||
```yaml
|
||||
name: "Standard Survival"
|
||||
description: "Base survival server with essentials"
|
||||
minecraft_version: "1.20.1"
|
||||
server_type: "paper" # or fabric, forge
|
||||
|
||||
mods:
|
||||
- name: "LuckPerms"
|
||||
source: "spigot"
|
||||
file_id: "12345"
|
||||
version: "5.4.102"
|
||||
config_files:
|
||||
- path: "plugins/LuckPerms/config.yml"
|
||||
template: "luckperms-standard.yml"
|
||||
|
||||
- name: "EssentialsX"
|
||||
source: "spigot"
|
||||
file_id: "67890"
|
||||
version: "2.20.1"
|
||||
config_files:
|
||||
- path: "plugins/Essentials/config.yml"
|
||||
template: "essentialsx-standard.yml"
|
||||
|
||||
luckperms_export: "luckperms-groups-standard.json"
|
||||
discord_webhook: "${DISCORD_WEBHOOK_URL}"
|
||||
```
|
||||
|
||||
**Backend:**
|
||||
- Store templates in PostgreSQL (`server_templates` table)
|
||||
- Config templates stored as text blobs or file references
|
||||
- Integration with Pterodactyl API for file uploads
|
||||
- Queue-based deployment (so long operations don't block UI)
|
||||
|
||||
---
|
||||
|
||||
## Technical Challenges We're Considering
|
||||
|
||||
### 1. Mod Downloads
|
||||
**Challenge:** How do we get the mod files?
|
||||
|
||||
**Options:**
|
||||
- **A)** Holly manually uploads JARs to Trinity Console first (template includes upload reference)
|
||||
- **B)** Integrate with CurseForge/Modrinth APIs (auto-download by file ID)
|
||||
- **C)** Store mods in S3/CDN, templates reference URLs
|
||||
|
||||
**Our instinct:** Option A (manual upload) for MVP, Option B later when we scale
|
||||
|
||||
### 2. Config File Templating
|
||||
**Challenge:** Some configs need server-specific values (server IP, database credentials)
|
||||
|
||||
**Options:**
|
||||
- **A)** Simple string replacement (`${SERVER_NAME}`, `${DATABASE_URL}`)
|
||||
- **B)** Full templating engine (Handlebars, EJS)
|
||||
- **C)** Interactive form before deployment (Holly fills in per-server values)
|
||||
|
||||
**Our instinct:** Option A for simple cases, Option C for complex setup
|
||||
|
||||
### 3. Pterodactyl API Integration
|
||||
**Challenge:** Uploading files via API vs SFTP
|
||||
|
||||
**Pterodactyl Client API supports:**
|
||||
- File upload (POST to `/api/client/servers/{server}/files/write`)
|
||||
- File deletion
|
||||
- Directory creation
|
||||
- Server restart
|
||||
|
||||
**Our instinct:** Use Pterodactyl API for everything (already have credentials in Arbiter)
|
||||
|
||||
### 4. Error Handling
|
||||
**Challenge:** What if mod upload fails mid-deployment?
|
||||
|
||||
**Options:**
|
||||
- **A)** Transaction-style rollback (delete uploaded files, restore backup)
|
||||
- **B)** Pause deployment, notify Holly, allow manual resume
|
||||
- **C)** Best-effort only, Holly fixes manually
|
||||
|
||||
**Our instinct:** Option B (pause + notify)
|
||||
|
||||
### 5. Version Management
|
||||
**Challenge:** Mod updates break servers
|
||||
|
||||
**Options:**
|
||||
- **A)** Lock templates to specific mod versions
|
||||
- **B)** Allow "latest" but track what's deployed
|
||||
- **C)** Show version diff before deploying template update
|
||||
|
||||
**Our instinct:** Option A for stability
|
||||
|
||||
---
|
||||
|
||||
## Specific Questions for You
|
||||
|
||||
1. **Architecture:** Does our template-based approach make sense, or is there a better pattern for "deploy identical configs to multiple servers"?
|
||||
|
||||
2. **Pterodactyl Integration:** Any gotchas with programmatic file uploads to Minecraft servers via their API? Should we worry about file permissions, ownership, or timing issues?
|
||||
|
||||
3. **Template Storage:** JSON in database vs files in repo vs hybrid? We're leaning toward database for easy UI editing.
|
||||
|
||||
4. **Deployment Queue:** Should we use a job queue (Bull/BullMQ) for async deployment, or is a simple "polling status" approach sufficient for 1-2 servers at a time?
|
||||
|
||||
5. **Config Templating:** Is simple `${VARIABLE}` replacement enough, or will we regret not using a real templating engine when configs get complex?
|
||||
|
||||
6. **Error Recovery:** What's the right balance between automation and "let Holly fix it manually"? We want to save her time, not create a debugging nightmare.
|
||||
|
||||
7. **MVP Scope:** If we build this in phases, what's the minimum viable feature set that delivers real value? (Our guess: upload template + deploy to one server with pre-uploaded JARs)
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
**Trinity Console Details:**
|
||||
- Already built (95% complete, security hardening in progress)
|
||||
- Tech stack: Node.js + Express, PostgreSQL, htmx + Tailwind
|
||||
- Has Pterodactyl Panel API integration (file reading)
|
||||
- Philosophy: Low-bandwidth friendly, RV-optimized, no complex build pipelines
|
||||
|
||||
**Firefrost Server Fleet:**
|
||||
- 13+ active Minecraft servers across 2 nodes (TX1 Dallas, NC1 Charlotte)
|
||||
- Mix of modded (Fabric/Forge) and plugin-based (Paper/Spigot)
|
||||
- Managed via Pterodactyl Panel
|
||||
- New servers deployed frequently (testing modpacks, seasonal servers)
|
||||
|
||||
**Holly's Workflow:**
|
||||
- Non-technical but very capable with guided UIs
|
||||
- Prefers "click button, it works" over "SSH and run commands"
|
||||
- Spends time building, not configuring
|
||||
- Values consistency (same mods = same experience across servers)
|
||||
|
||||
**Our Goal:**
|
||||
Reduce new server deployment from 2-3 hours to 15-30 minutes, with Holly clicking buttons in Trinity Console instead of manually uploading files via SFTP.
|
||||
|
||||
---
|
||||
|
||||
Thanks Gemini! Your architectural insight would be incredibly valuable here. We trust your judgment on what's worth building vs what's premature optimization.
|
||||
|
||||
🔥❄️
|
||||
|
||||
— Holly + Claude (Catalyst #2)
|
||||
Reference in New Issue
Block a user