Files
firefrost-operations-manual/docs/tasks-index/task-104-mod-deployment-automation.md
Claude dce651e09a Add Task #104: Server-Side Mod Deployment Automation
- Gemini consultation documented
- Chose Option B (Trinity Console Push) for speed
- Holly working in parallel with her Catalyst
- Will compare approaches and merge best ideas
2026-04-09 21:36:28 +00:00

131 lines
3.2 KiB
Markdown

---
task_number: 104
title: Server-Side Mod Deployment Automation
status: In Progress
priority: P1-High
is_blocker: false
owner: Holly
tags:
- automation
- pterodactyl
- mods
estimated_hours: 8
---
# Task #104: Server-Side Mod Deployment Automation
## Problem
Every time we deploy a new public modpack, Holly has to manually install and configure 14 server-side mods per server. With 10 servers and ~1 hour per server, that's 10 hours of repetitive file manager work.
## Solution
Automate deployment via Trinity Console using Pterodactyl API.
## Architecture Decision
**Chosen: Option B — Trinity Console Push (API)**
Per Gemini consultation (April 9, 2026), we evaluated three approaches:
| Option | Approach | Verdict |
|--------|----------|---------|
| A | Egg Startup Script (self-healing pull) | Future — after 50+ servers |
| B | Trinity Console Push (API) | **NOW** — fast to build, we control it |
| C | Hybrid | Effectively B with intent to revisit A |
**Why B for now:**
- 6 days from soft launch — speed matters
- Holly needs relief NOW
- We already have Pterodactyl API in Arbiter
- Can test on single server before mass deploy
- No egg modifications needed
**Revisit Option A** post-launch when stability > flexibility.
---
## Implementation Plan
### Phase 1: Bundle Creation (Holly)
Holly creates 3 mod bundles:
| MC Version | Bundle Contents |
|------------|-----------------|
| 1.16.5 | 14 mods + configs |
| 1.20.1 | 14 mods + configs |
| 1.21.1 | 14 mods + configs |
**Bundle structure:**
```
1.20.1.zip
├── mods/
│ ├── mod1.jar
│ ├── mod2.jar
│ └── ...
└── config/
├── mod1.toml
└── ...
```
**Storage location:** Command Center `/var/www/html/deploy/` or Gitea LFS
### Phase 2: Trinity Console Integration (Claude/Michael)
Add to Servers page:
1. Display MC version on each server card (from Pterodactyl egg variables)
2. "Deploy Server Mods" button per server
3. Button workflow:
- Stop server (power action)
- Wait for offline status
- Upload correct bundle via Files API
- Extract zip
- Start server
### Phase 3: Mass Deploy
Add "Deploy Mods to All [version] Servers" button for batch operations.
---
## Gemini Consultation Summary
**Key recommendations:**
1. **Storage:** Web-accessible directory on Command Center
2. **Never push to running servers** — stop first, then deploy
3. **Skip CurseForge API** — overkill for 14 mods, manual download is fine
4. **Self-healing (Option A)** is better long-term but invasive now
**Full consultation:** `docs/consultations/gemini-mod-deployment-automation-2026-04-09.md`
---
## Safety Protocol
```
Stop Server → Wait for Offline → Upload Files → Extract → Start Server
```
Never overwrite JARs while JVM is running (causes crashes).
---
## Open Questions
1. Where exactly to store bundles? (Command Center web dir vs Gitea LFS)
2. How to detect MC version from Pterodactyl API? (egg variable name)
3. Should configs overwrite existing or merge?
---
## Notes
- Holly is working on this with her Catalyst in parallel
- Compare approaches and merge best ideas
- This is P1 because it directly affects Holly's workload before launch
---
**Fire + Frost + Foundation = Where Love Builds Legacy** 🔥❄️