Panel Laravel Package

Product Decisions This Supports

• Build vs. buy for game-server hosting. Pterodactyl is an open-source Laravel panel plus a game-server daemon (Wings). If game-server management is a feature of your product rather than the product itself, this is the baseline to evaluate against a from-scratch build: user/tenant management, server lifecycle, file manager, scheduling, and per-game templates ("eggs") all come out of the box.
• Security-response ownership as a line item, not an afterthought. v1.15.2 is a security release for "php2shell" (CVE-2026-109618, CVE-2026-109619) affecting the PHP runtime under the panel. Self-hosting means you own CVE triage and patching. The PM decision is whether to commit to a patch SLA (e.g. critical CVEs applied within N days of disclosure) or to buy a supported/managed panel that absorbs that obligation. This release is the concrete data point that makes that cost visible.
• Release-track decision (1.x vs. 2.0 beta), now with two patch streams. v1.15.2 confirms the 1.x line is still actively security-maintained — which validates keeping revenue-bearing panels on 1.x. But if you also pilot 2.0, you are now tracking and patching two lines. Budget the maintenance effort for both, or sequence the 2.0 pilot so it does not overlap with a security patch window.
• Runtime upgrade as a scheduled roadmap item. The release sets a PHP floor of 8.2.35 / 8.3.36 and instructs non-Docker operators to upgrade every PHP package together. This is a coordinated maintenance window with real downtime risk, not a background update. Put it on the roadmap with an owner.
• Deployment topology decision (Docker vs. bare metal). The published Docker image carries the fix and the hardening (session.upload_progress disabled in php-fpm). Bare-metal/package installs get the patched PHP but must replicate that hardening manually. Choose deliberately: Docker gives you the security posture by default; bare metal gives you flexibility at the cost of config drift your team must police.
• Deployment reproducibility. Pin ghcr.io/pterodactyl/panel:v1.15.2 on the stable track (and the equivalent tag on any 2.0 pilot). Treat the tag as the unit of version control so a security rollback is a one-line change.
• Not a feature release. No new capabilities, no breaking changes, no deprecations on 1.x. The PM takeaway is status, not scope: both the 1.x stable line and the 2.0 beta are actively maintained, which is a maintenance-health signal to weigh against the beta risk on 2.0.

When to Consider This Package

Adopt when:

• You need multi-tenant game-server hosting (Minecraft, Rust, Valheim, etc.) and want lifecycle management, per-server file access, resource limits, and scheduled tasks without building them.
• Your team is already on Laravel/PHP and wants to extend a familiar stack rather than adopt an unfamiliar platform.
• You can self-host and operate Docker plus the Wings daemon on the target nodes — this is infrastructure you own, not a managed service.
• You can staff a patch SLA for security releases like this one, and you are already on (or can move to) PHP 8.2.35+ / 8.3.36+.
• You accept beta-level stability for a pilot, or you are content on the 1.x stable line with a planned upgrade.
• You are evaluating a commercial panel or a custom build and want a credible open-source reference implementation and cost baseline.

Look elsewhere when:

• You need a vendor-backed GA product with SLAs, support contracts, and a guaranteed upgrade path. Neither an open beta nor a community-maintained 1.x line provides those commitments — and this release is exactly the kind of CVE response you would otherwise be paying a vendor to own.
• You cannot absorb unplanned patch windows. Security releases arrive on the project's schedule, not yours.
• You have no appetite for operating daemons, node provisioning, Docker image pinning, and PHP runtime upgrades — the operational surface is real and does not disappear because the software is free.
• Your workload is not game servers. The panel's abstractions (eggs, per-game templates, daemon-per-node) are tuned for that domain and will fight you elsewhere.
• You need a hard compatibility or deprecation contract for an integration; beta releases can change before GA.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can replace a meaningful amount of custom platform work with an open-source, Laravel-based game-server panel. There is no licence cost, and the core capabilities — tenant management, server provisioning, file management, scheduled tasks, templated game configurations — are already built and in use elsewhere. The 1.x line we would run in production just shipped a security patch for two CVEs in the underlying PHP runtime; that is a maintenance event, not a capability change, and it is evidence the project is actively maintained. It also illustrates the real trade-off: with open source, we own security response and runtime upgrades ourselves. The recommendation is to keep revenue-bearing panels on the patched 1.x release, pilot 2.0 only on non-critical infrastructure, and fund a small standing maintenance budget — patch windows, PHP upgrades, node operations — rather than a licence. That budget, not the software cost, is the number to compare against a commercial panel.

For engineering:

• Patch now. v1.15.2 addresses CVE-2026-109618 and CVE-2026-109619 ("php2shell"). Treat as a priority upgrade on any internet-facing panel.
• Docker path (preferred): pin ghcr.io/pterodactyl/panel:v1.15.2. The image ships PHP 8.3.36 and disables session.upload_progress in php-fpm — you get the fix and the hardening together.
• Bare-metal path: upgrade to PHP 8.2.35 or 8.3.36 and upgrade every PHP package together (sudo apt update && sudo apt install --only-upgrade 'php8.*'). Do not upgrade PHP packages piecemeal.
• Config parity gap: non-Docker installs do not automatically get session.upload_progress disabled. Replicate that php-fpm setting explicitly and add it to your config baseline, or the two topologies will drift in security posture.
• No application-level changes: no API changes, no schema changes, no deprecations, no breaking changes. Upgrade risk is low; the risk is in the runtime and package upgrade, so rehearse against a copy of the panel first.
• Two tracks, two patch obligations. If the 2.0 beta pilot is live, confirm whether it inherits this fix and patch it on the same schedule.
• Operational surface remains: Docker on nodes, the Wings daemon, the panel application, and now a PHP runtime you must track for CVEs. Factor that into estimates — the licence is free but the platform is not zero-maintenance.