firefrost-operations-manual/docs/consultations/gemini-modpack-version-checker-review-2026-04-01.md

Gemini's Architectural Review: Modpack Version Checker

From: Gemini AI
To: Chronicler #52 + Michael (The Wizard)
Date: April 1, 2026
Re: Modpack Version Checker - Architecture & Scope Definition

---

Hello Chronicler #52 and Michael (The Wizard)! 👋

This is exactly how you build a legacy that fuels the RV dream: strategic, scalable, passive income. Moving from internal infrastructure to a commercial product is a massive level-up.

To make this a true "install-and-forget" passive income stream on BuiltByBit, the architecture needs to be bulletproof. A poorly designed extension will drain your time with support tickets, defeating the purpose of passive income.

Here is my candid, systems-level architectural review of the Modpack Version Checker.

---

1. The Tech Stack Reality Check (PHP vs. Node.js)

The Blueprint framework modifies Pterodactyl, which is built on Laravel (PHP) and React.

While you have Node.js on your Dev VPS, do not build this as a Node.js service. If you do, anyone who buys your extension on BuiltByBit will have to manually install Node.js, set up a Systemd service, and monitor it alongside their panel. Server hosts hate extra dependencies.

• The Architecture: Build this 100% native to Laravel using PHP.
• Background Jobs: Pterodactyl already requires a system cron job that runs php artisan schedule:run every minute. You will inject your version-checking logic directly into Laravel's Task Scheduler. This makes your extension purely "plug-and-play" for buyers.
• The UI: Blueprint allows you to inject React components into the frontend and Blade templates into the Admin area.

2. API Strategy & The "API Key Trap"

This is the biggest gotcha for commercial panel extensions.

CurseForge API: CurseForge requires an API key. Never hardcode your own API key into a distributed product. If you sell this to 100 server hosts, and each host has 20 servers, your single API key will be making thousands of requests an hour. You will be rate-limited and banned, breaking the product for all your paying customers.

• The Solution (BYOK): Implement a "Bring Your Own Key" model. The extension must have an Admin Settings page where the buyer inputs their own CurseForge API key to enable the integration.

Modrinth API: Modrinth is public but strictly enforces User-Agent headers.

• The Solution: Hardcode a dynamic User-Agent in your PHP HTTP requests that identifies the buyer's panel (e.g., FirefrostExtension/1.0 (Contact: admin@buyer-domain.com)).

Caching Strategy: Do not check APIs on every page load. The Laravel scheduled task should run once every 12 or 24 hours (configurable by the buyer), ping the APIs, and store the latest_version in the local database. The UI should only ever read from the local database.

3. Database Schema Design

Blueprint handles database migrations seamlessly using Laravel's migration system. You need one core table to map Pterodactyl servers to modpack projects.

Table: modpack_version_tracker

• id (Primary Key)
• server_id (Foreign Key -> Pterodactyl servers.id)
• platform (Enum: curseforge, modrinth)
• project_id (String/Int - The ID of the modpack on the platform)
• current_version_id (String - What the server is currently running)
• latest_version_id (String - Fetched from API)
• last_checked_at (Timestamp)
• created_at / updated_at (Timestamps)

4. Scope Definition: Protecting the MVP

To get to market efficiently and safely, you must ruthlessly guard the MVP scope.

Keep for v1.0:

• Database tracking and Laravel scheduled checks.
• Admin dashboard UI (showing outdated servers).
• Discord Webhooks (Server hosts love Discord webhooks. Make it so they paste a webhook URL in the extension settings, and it pings them when an update is found).

Cut from v1.0 (The Danger Zone):

• Automatic Modpack Update Deployment: Absolutely do not do this for v1.0. Updating a modpack automatically can corrupt worlds, break configurations, and wipe player data. If your extension destroys a buyer's server, your BuiltByBit reputation will tank. Version checking is safe; version updating is a massive liability.
• Email Notifications: Skip this. Integrating with panel SMTP settings is notoriously finicky across different host environments. Stick to Discord webhooks; they are universal and foolproof.

5. Marketplace Readiness & Pricing

• Pricing: Quality-of-life Pterodactyl extensions typically sell for $10 to $15. It's a sweet spot where it's an impulse buy for a host looking to save time, but high enough to filter out low-effort buyers who generate the most support tickets.
• Support/Documentation: To make this truly passive income, your documentation must be flawless. Include a step-by-step installation guide, troubleshooting FAQs, and exactly how to get a CurseForge API key.
• Testing: Your plan is solid. Build on Dev -> Deploy to Prod Panel -> Beta test with 2 external hosts. Finding external beta testers on BuiltByBit forums before launching is highly recommended, as different hosts have wildly different Nginx/Apache and OS configurations.

---

This is a highly viable product that fills a real gap in the market. By keeping it native to Laravel, enforcing a BYOK model for CurseForge, and strictly avoiding automatic file deployments in v1.0, you are setting up a highly stable, low-maintenance revenue stream.

When it comes to the user interface, do you envision this alerting only the Master Admin of the Pterodactyl Panel, or do you want the version alerts to be visible to the individual end-users (the server owners) on their specific server consoles?

---

Fire + Frost + Foundation = Where Love Builds Legacy 💙🔥❄️

— Gemini AI