EzePanel · php fpm
Keep busy PHP sites within deliberate resource limits.
Manage installed PHP runtimes, domain assignments and account pool policy as connected but separate decisions. Keep application compatibility and server pressure in the same conversation.
Explore the capabilitySwipe to inspect · tap the image for full context
A website’s PHP version, request settings and worker capacity answer different questions. EzePanel gives operators controls for each without making a server-wide runtime change the default response to one site.
Start with the installed runtime.
The administrator reviews discovered PHP versions, availability, defaults, extension information and service state. Customers choose among the versions and options available to their account.
Technical details
A version appearing in inventory is not a guarantee of application compatibility. Review the intended version and required extensions, then test the site’s important requests after assignment.
Choose the change scope deliberately.
A domain-level selection targets that website’s runtime. An account-level version change can update the account’s domains together. Server-level runtime controls have a broader impact.
Technical details
Follow reconciliation and the recorded result. A failed assignment can require restoring the previous setting, and a restoration attempt can itself fail. Confirm the effective runtime before repeating the change.
Capacity is connected
Workers and memory share the same host.
PHP-FPM workers determine how many requests can execute concurrently in the pool. Per-request PHP memory, account memory and CPU policy constrain different layers of the workload.
Technical details
More workers can increase database demand and memory pressure. The workers-times-request-memory calculation is a capacity warning, not measured consumption. Use current workload evidence before expanding concurrency.
Swipe to inspect · tap the image for full context
Workers
Concurrent requests
Request memory
Per-request PHP setting
Account policy
Grouped workload ceiling
Host capacity
Shared physical resources
Follow the effective resource policy.
Account overrides take precedence over package values, followed by server fallback. The resource engine reconciles the relevant runtime settings and records synchronization outcomes.
Technical details
A saved value and an applied value are different. Missing helpers or related service failures can leave partial application. Review warnings, the effective limits and the actual website behavior.
Investigate a slow or unavailable PHP application.
Connect domain assignment with Server Health, process ownership, account limits and monitoring evidence. Review request behavior and downstream database or cache dependencies.
Technical details
Shared distribution PHP services and tenant FPM masters are different targets. Use the smallest supported action for the actual scope, then verify the application. No zero-downtime change or automatic performance gain is promised.
In daily operations
Change one runtime deliberately.
Example: one domain needs a newer PHP version. Preserve a recovery copy, choose the domain scope, follow the change and test the application before considering a wider account update.
Frequently asked questions
Questions about the workflow.
Does choosing a PHP version increase available resources?
No. Runtime compatibility and account resource policy are separate decisions.
Should I raise worker limits whenever a site is slow?
First examine request duration, memory, CPU and database pressure. More concurrent work can increase contention.
Does changing the account runtime affect every domain?
The account-level workflow can update its domains. Choose a domain-specific workflow when that is the intended scope.
Is a saved PHP option proof that the runtime changed?
No. Follow application/reconciliation results and verify the effective runtime and website.
Connected capabilities
Connect this workflow to your hosting operation.
Explore the platform or discuss the requirements of your server, team and customers.