Pterodactyl Addon Laravel Package

Product Decisions This Supports

• Build vs. buy for the billing↔panel seam. This addon is the integration layer between PteroCA (billing/customer management) and Pterodactyl (game server control plane): automated user provisioning, SSO from the billing panel into the panel, and API key management. The decision it supports is whether to own that glue in-house or depend on a community package. At v0.1.x, this is a buy-with-caveats — cheap to adopt, but we own the patch latency.
• Security posture as a product requirement. v0.1.4 fixes a CVSS 9.9 vulnerability in the addon's /api/application/* API key endpoints, affecting all installs ≤ 0.1.3. The fix enforces application-api middleware (admin-only), root_admin + users write permission for key create/delete, input validation, and SSO hardening (mandatory token expiry, mandatory secret, same-site-only post-login redirects). This is a product decision, not just a maintenance one: any deployment older than 0.1.4 should be treated as a potential compromise, not merely an outdated image.
• Incident-response scope. The release notes require post-upgrade forensics — audit account API keys on admin accounts and hunt for unexpected root_admin users. That means the upgrade is a ~1–2 hour engineering task with an audit trail, plus a customer-comms decision if unauthorized admin accounts are found.
• Patch SLA and dependency governance for hosting-critical paths. A pre-1.0 third-party addon holding an Application API key with users read/write is a high-privilege dependency. This release is the forcing function to define version pinning, a security-release subscription, and a maximum time-to-patch for privileged integrations.
• Compatibility envelope. Tested on Pterodactyl 1.11.11 and 1.15.1. The root_admin/users write requirement is a potential behavioral break for any deployment that ran the addon with a deliberately limited-scope Application key — worth confirming before rollout, since the notes' "no configuration changes" assumes a full-scope key.
• Use cases gated on this: reseller/white-label game hosting, self-serve server provisioning, single-sign-on from billing to panel, automated account lifecycle.

When to Consider This Package

Adopt (with controls) when:

• You run both PteroCA and Pterodactyl and manual user provisioning / duplicate logins are real support cost.
• You need SSO and automated user creation more than you need vendor-backed SLAs.
• You can pin the version, subscribe to security advisories, and patch privileged dependencies within days — not quarters.
• You have someone who can read a GHSA advisory and audit admin accounts.
• You are on Pterodactyl 1.11.x or 1.15.x (the tested envelope), and you can run a full-scope Application API key with users write.

Look elsewhere / defer when:

• You need a supported vendor contract, indemnity, or a 1.x API stability guarantee — this is 0.1.x and endpoints/middleware are still shifting.
• You need SSO against an external IdP (Okta, Entra, Google) rather than panel-local SSO; that's not what this does.
• You can't tolerate a security release that requires post-incident auditing as part of the upgrade.
• You run multiple panels, heterogeneous Pterodactyl versions, or a locked-down least-privilege API key model that forbids root_admin.
• Provisioning volume is low enough that manual account creation is cheaper than owning this dependency.
• You're mid-audit or under a compliance regime (SOC 2, PCI) where a pre-1.0 community addon on the admin API path is a finding you'd have to document.

How to Pitch It (Stakeholders)

For executives: We integrate our billing system with the game server panel via a small community addon. A critical security flaw (CVSS 9.9) was disclosed in every version up to 0.1.3 — it lets an attacker reach admin-level API key endpoints. A patched version (0.1.4) shipped and requires no configuration change. The ask is small and time-boxed: ~1–2 hours of engineering to upgrade, plus a one-time audit of admin accounts and API keys to check whether the flaw was used. Doing nothing leaves a known, publicly documented hole on the system that controls customer servers and account creation. This also surfaces a governance gap — we should decide how quickly we patch high-privilege third-party dependencies as a standing rule.

For engineering: Upgrade to ^0.1.4 immediately on all environments (prod first, then staging parity), run php artisan optimize:clear, and verify the Application API key still has users read/write and root_admin — provisioning and key management will fail without it. Then perform the advisory's audit: enumerate account API keys on administrator accounts, revoke anything unrecognized, and search for unexpected root_admin users; escalate to security if found. Confirm the addon's /api/application/* routes now 401/403 for non-admin callers, that SSO rejects tokens without expiry and blocks cross-site redirect targets, and that key deletion no longer 500s on Pterodactyl 1.11+. Pin the version in composer.json and add a watch on the repo's security advisories. Flag any environment where the addon previously ran with a restricted-scope key — that's the one place "no config changes" may not hold.