Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
The right PHP host is the one that matches your application’s required PHP branch, extensions, database, web server and HTTPS settings, while providing enough memory, workers and CPU for real traffic. After compatibility, compare the hosting model, upgrade path, backups and restores, staging, deployment access, support, security controls, migration help and the full renewal cost.
“Supports PHP” is not a meaningful specification by itself. A plan can run a basic script yet fail when your site needs a particular PHP version, Composer packages, cron jobs, queue workers, a database version, rewrite rules or a higher PHP memory limit. Use the process below to verify those details before paying, and document the answers so you can compare providers on the same basis.
As an Amazon Associate I earn from qualifying purchases.
What should a PHP hosting provider support?
Start with a written compatibility profile for the application you will deploy. Confirm every item before comparing promotional storage or bandwidth figures.
| Requirement | What to verify with the provider | Why it matters |
|---|---|---|
| PHP branch | The exact supported branch (for example, PHP 8.4), whether it can be selected per site, and how upgrades are tested | Your code, plugins and frameworks may require a minimum version; an old branch creates security and compatibility risk. |
| Extensions | Required modules such as PDO drivers, mbstring, cURL, GD or Imagick, Intl, ZIP and XML; ask whether you can enable them yourself | Applications often fail with an “extension missing” error even when the PHP version is correct. |
| Database | MariaDB or MySQL engine, exact version, database-size limits, remote-access policy and backup coverage | Database features and character-set behavior vary by version, and database limits can become the first bottleneck. |
| Web server | Apache or Nginx, rewrite support, HTTP/2 or HTTP/3 availability, and per-site configuration options | Routing, caching and security headers depend on the server configuration. |
| HTTPS | Certificate issuance and renewal, redirect controls, TLS settings and support for HTTPS on staging domains | Modern browsers, payment systems and search engines expect encrypted connections. |
| Runtime tools | SSH, Composer, Git, cron, environment variables, queue or worker processes and scheduled-task limits | These tools determine whether you can deploy and operate a modern PHP application without workarounds. |
For WordPress, the published baseline is PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, HTTPS, and Apache or Nginx with rewrite support. WordPress.org lists those requirements at wordpress.org; verify your specific theme and plugin stack separately because meeting the platform baseline does not guarantee every extension is compatible.
#1 Best Overall
Which PHP version should you choose?
Prefer a currently supported PHP branch and a clear, tested upgrade path. The WordPress hosting handbook recommends PHP 8.4 or later for production. It records PHP 8.3 as moving to security-only support on 31 December 2025 and PHP 8.2 reaching end of life on 31 December 2026. A host that only offers an older branch may keep an application running today, but it leaves you with fewer security fixes and less time to resolve future incompatibilities.
Ask whether the provider offers multiple branches per account or per site, whether you can switch versions without opening a ticket, and whether older branches receive documented security backports. Test a version change on staging before changing production. Current PHP releases generally improve efficiency and security, but a plugin, theme or custom library can still require code changes.
Free tools Windows power users keep installed
One-click scans. No signup required.
How much PHP memory does a site need?
Use the application’s workload, not the provider’s headline “unlimited” claim, to choose a memory limit. The WordPress hosting handbook gives these practical tiers:
| Workload | PHP memory guidance | Typical reason for the tier |
|---|---|---|
| Basic site | 128M minimum | Small brochure sites with a light plugin set |
| Typical production WordPress | 256M recommended default | Normal themes, forms, analytics and several plugins |
| Resource-intensive site | 512M or more | WooCommerce, page builders, multilingual plugins or import/export tools |
Confirm whether the advertised PHP memory value is the per-process memory_limit, an account-wide allowance or merely a support recommendation. A high memory limit cannot compensate for low CPU, too few concurrent workers or a database that is throttled.
Should I choose shared hosting, managed WordPress, a VPS or cloud hosting?
Choose the least complex model that provides the control and predictable resources your workload needs. Shared hosting is economical for a simple, lower-traffic site; managed WordPress reduces administration; a VPS or cloud instance is better when you need system-level control or dedicated capacity.
| Hosting model | Best fit | Advantages | Trade-offs to check |
|---|---|---|---|
| Shared hosting | Low-traffic sites, prototypes and simple WordPress installations | Low administration burden and usually a lower starting cost | Neighbors share hardware; CPU, processes, inodes, database size and worker limits can be tight. SSH, Composer and custom extensions may be restricted. |
| Managed WordPress | Teams that want WordPress updates, security and routine operations handled | Purpose-built dashboards, staging and application-focused support may be included | Some plugins, server settings, cron behavior or non-WordPress applications may be disallowed. Add-on charges can change the total cost. |
| VPS | Applications needing SSH, Composer, custom PHP extensions, cron, queues or predictable allocation | More control over PHP, the web server and services; clearer resource boundaries | You may be responsible for patching, hardening, monitoring, backups and recovery unless administration is included. |
| Cloud hosting | Variable traffic, multiple services or a need to scale components independently | Flexible capacity and the option to separate web, database and worker roles | Billing can be less predictable; architecture, networking, security and operational work are more complex. |
Do not select a model solely by visitor count. A small application that runs a queue worker, needs private Composer packages and requires root-level extensions may outgrow shared hosting before it receives much traffic. Conversely, a low-traffic informational site can waste money and operational time on a VPS.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
How do I compare resource limits beyond storage and bandwidth?
Ask for documented limits and the conditions that trigger throttling. Storage and monthly transfer rarely describe the constraint that users feel first.
- CPU allocation: Find out whether CPU is a shared percentage, a burst allowance or a dedicated allocation, and what happens after a burst.
- RAM and PHP memory: Distinguish physical or virtual RAM from the PHP
memory_limit. Check whether the limit applies per process, per site or to the whole account. - Entry processes and concurrent workers: These cap simultaneous PHP requests. A site can show spare CPU while visitors queue because all workers are occupied.
- Storage type and IOPS: SSD or NVMe storage, database I/O limits and filesystem quotas affect response time more than raw capacity.
- Inodes and file count: Backups, caches, image variants and mailboxes can hit an inode ceiling even when gigabytes remain.
- Database size and connections: Check per-database limits, maximum connections, query-time limits and whether slow-query logs are available.
- Bandwidth policy: Clarify fair-use language, transfer overage rates and whether traffic spikes cause suspension or throttling.
- Process and task limits: Ask how many cron jobs, queue workers, long-running processes and scheduled executions are allowed.
Request the limits in writing, including what is measured, the reset period and the notification process. If a plan says “unlimited,” ask which technical limits still apply and where they are documented.
How can I verify PHP, database and deployment compatibility before buying?
Use a short technical checklist and request a test account or staging environment when possible. The following sequence catches most incompatibilities before migration.
- Write the application matrix. Record the minimum and preferred PHP branch, required extensions, database engine and version, web server assumptions, memory requirement, scheduled tasks and deployment commands. Include versions imposed by plugins, themes or framework packages.
- Ask about per-site PHP selection. Confirm the exact branches available, whether each site can use a different branch, and whether switching changes configuration files, opcode caches or extensions.
- Verify extensions and configuration. Provide your module list and ask which are enabled by default, which can be enabled without support and whether settings such as upload size, execution time and
post_max_sizecan be adjusted. - Check the database service. Confirm MariaDB or MySQL and its version, database and user limits, character-set support, import size and backup frequency. Ask whether restoring a database requires a support ticket.
- Confirm web-server behavior. Ask whether Apache or Nginx rewrite rules are supported, where redirects and headers are configured, and whether a front-end cache changes request handling.
- Test HTTPS. Confirm certificate issuance and renewal, HTTP-to-HTTPS redirects, secure cookies and HTTPS support on staging. Verify that your application can reach external APIs over TLS.
- Test the deployment path. Ask for SSH access, Composer version, Git deployment options, environment-variable handling, cron syntax and queue-worker support. Check whether shell access is jailed and whether private package repositories are reachable.
- Run a staging smoke test. Install the application, run its migrations, exercise login and uploads, execute scheduled tasks and load representative pages. Check logs for missing extensions, permission errors and memory exhaustion before going live.
What security practices should a PHP host provide?
Look for a documented patching process and controls that limit the impact of a compromised site. Security is a combination of current software, isolation and recoverability, not a single “malware scanning” badge.
- Current runtime and database: The provider should publish supported PHP branches, patch cadence and a process for retiring end-of-life versions.
- HTTPS and certificate management: Certificates should renew automatically or have a clearly documented renewal workflow, with support for redirects and modern TLS settings.
- Account isolation: Ask how customer accounts are separated from one another and from the server’s default shared username. WordPress specifically recommends asking this question because weak isolation can let one compromised account affect others.
- Least privilege: Separate application, database and deployment credentials; restrict file permissions; and provide role-based control where teams need different access.
- Vulnerability response: Ask how the provider handles newly disclosed PHP, web-server and control-panel vulnerabilities, and how customers are notified of emergency changes.
- Logging and alerting: Confirm access to PHP errors, web-server logs, authentication events and resource alerts, while checking retention periods and export options.
- Network and abuse controls: Clarify firewalling, rate limits, outbound-mail restrictions and procedures for an infected site or abusive traffic.
Do not treat a security add-on as a substitute for patching and isolation. A host that cannot explain who applies updates, how accounts are separated and how a customer restores clean data has not demonstrated a complete security process.
What backup, restore and staging features are worth paying for?
Prioritize backups you can restore yourself and verify, rather than a backup icon with no recovery detail. Ask what is copied, where it is stored, how long versions are retained and whether application files and databases are restored together.
- Off-site copies: Backups should be stored separately from the production server so a filesystem or account failure does not destroy both copies.
- Granularity: Check whether you can restore an individual database, site or file set instead of reverting an entire account.
- Restore path: Confirm whether restores are one-click, require support, overwrite production immediately or can be downloaded for inspection first.
- Staging: A staging clone lets you test PHP upgrades, plugin updates, migrations and configuration changes without exposing visitors to a broken release.
- Rollback: Automated updates should have a documented rollback method. Ask whether rollback includes the database, because code-only rollback can leave incompatible schema changes.
- Testing: Perform periodic test restores and record the steps. A backup that has never been restored is an assumption, not a recovery plan.
Ask how backups interact with large databases, excluded directories, cron-generated files and uploaded media. Also clarify whether staging consumes a separate site, storage quota or paid add-on.
How do support and migration services affect the decision?
Support quality matters most when the problem crosses the boundary between PHP, the web server and your application. Evaluate the people and process, not only the advertised response channel.
Questions to ask support
- Is support available 24/7, and which hours are handled by an escalation team?
- Will agents troubleshoot PHP fatal errors, Composer dependency failures, database imports and cron execution, or only the control panel?
- Are response targets different for outages, security incidents and routine questions?
- Can support provide logs and resource graphs, and can it explain throttling or worker exhaustion?
- What is the escalation path when first-line support cannot reproduce an issue?
Migration details to confirm
Ask whether migration assistance includes files, databases, DNS, mail and SSL, and whether it covers the application’s current PHP branch. Confirm who changes DNS, how long the old site remains available, whether a final database sync is performed and what happens if the migration must be reversed. Before authorizing a move, obtain a full backup and identify an exit route that does not depend on proprietary export tools.
How should I calculate the real cost of PHP hosting?
Compare the recurring cost after the introductory term, not the first invoice. Add every service required to operate the site safely.
| Cost item | What to include in your comparison |
|---|---|
| Hosting renewal | The regular monthly or annual price after any introductory promotion, including taxes where applicable |
| Backups | Off-site storage, longer retention, database backups and restore fees |
| Staging | Extra environments, storage, additional databases or per-site staging charges |
| Resources and overages | CPU, RAM, transfer, inode, database, worker and storage overage rates; suspension thresholds |
| Email and domains | Mailbox limits, migration charges, domain renewal and privacy services if you need them |
| Migration and support | One-time migration fees, managed administration, premium support or emergency assistance |
| Exit costs | Data-export restrictions, required paid services to download backups, DNS changes and replacement certificates |
Calculate a 12- or 36-month total using the renewal price and the options you will actually use. A cheaper plan can cost more if it requires paid backups, staging, support or frequent upgrades to escape resource limits.
What exact request can I send to a prospective host?
Use a consistent request so each provider answers the same technical questions. WordPress.org supplies this opening wording: “I’m interested in running the open source WordPress https://wordpress.org/ web software, and I was wondering if my account supported the following”. Add your own application matrix and ask for written answers to these points:
Rank #4
- Which PHP 8.4 or later branches are available, and can I select one per site?
- Are PHP 8.3 and older branches available only with security backports, and until what date?
- Are MariaDB 10.11 or later or MySQL 8.0 or later available, and what are the database-size and connection limits?
- Is Apache or Nginx with rewrite support available, and can I configure redirects and headers?
- Which extensions, Composer versions, SSH features, Git workflows, cron schedules and queue workers are supported?
- What are the CPU, RAM, PHP memory, entry-process, worker, inode, storage and bandwidth limits?
- How are accounts isolated from the server’s default shared username?
- How often are backups made, where are they stored, how long are they retained and how do I perform a restore?
- Is staging included, and does it support PHP-version changes and database synchronization?
- What are the renewal prices, overage fees, add-ons, migration charges and cancellation or export procedures?
Which PHP hosting choice fits common workloads?
Map the application’s operational needs to a model before looking at brand names or discounts.
Simple brochure or personal site
Shared hosting can be sufficient when traffic is modest, the plugin set is light and you do not need custom extensions or long-running processes. Confirm PHP version selection, HTTPS, backups, inode limits and a memory limit of at least 128M.
Typical business WordPress site
Managed WordPress is attractive when you want application-focused updates, staging and support without administering a server. Verify that your required plugins are allowed, that PHP 8.4 or later is available for production, and that the included memory and workers match peak usage.
WooCommerce, page-builder or multilingual site
Plan for the 512M-or-more memory tier recommended for resource-intensive WordPress workloads, while checking CPU, concurrent workers, database connections and import limits. A managed plan with strong staging and restore tooling may work; move to a VPS or cloud design if you need custom workers or predictable allocation.
Recommended Free Tools
Custom framework or API
A VPS or cloud environment is usually the better fit when deployment requires SSH, Composer, private packages, custom extensions, queues, workers or multiple services. Budget for patching, monitoring, backups and incident response unless those duties are explicitly managed.
What are the most common PHP hosting mistakes?
Choosing by “unlimited” storage
Unlimited storage does not remove CPU, inode, worker, database or fair-use limits. Obtain the actual quotas and throttling rules before committing.
Running an end-of-life PHP branch
An old branch may preserve compatibility temporarily but increases exposure to unpatched defects. Use staging to test a supported branch and set a date for retiring legacy code.
Confusing PHP memory with server capacity
Raising memory_limit cannot fix exhausted workers, CPU throttling or slow database I/O. Diagnose the constrained resource from logs and provider metrics.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Skipping a restore test
A successful backup job does not prove that files, databases, permissions and configuration can be recovered together. Perform a test restore before a major release and document the result.
Ignoring deployment requirements
Applications that depend on Composer, Git, cron or queue workers can become fragile when those tools are unavailable or restricted. Verify the full deployment command on staging rather than assuming a control panel’s file manager is enough.
Comparing only the introductory price
Promotions can conceal higher renewals, paid backups, staging charges and migration fees. Compare the same 12- or 36-month feature set for every candidate.
What is the final pre-purchase checklist?
- List the exact PHP branch, extensions, database, web-server behavior, HTTPS needs and deployment tools.
- Confirm the provider supports those requirements per site and document the answer.
- Choose shared, managed WordPress, VPS or cloud hosting according to required control and resource predictability.
- Compare CPU, RAM, PHP memory, workers, storage, inodes, database limits and bandwidth policy.
- Verify current PHP support, patching, account isolation, least-privilege controls and vulnerability response.
- Test staging, backups, restores, rollback and the complete deployment path.
- Check support scope, escalation, migration procedure and an independent exit path.
- Calculate renewal cost with backups, staging, overages, domains, migration and support included.
- Run a representative smoke test before changing DNS or accepting production traffic.
Frequently Asked Questions
Can I change PHP versions without moving hosts?
Often you can switch branches in the hosting panel, but the availability and scope vary by provider. Confirm whether the change is per site, whether extensions and opcode settings follow the switch, and whether a rollback is available after testing on staging.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Do I need SSH access for a WordPress site?
A basic installation can run without SSH, but SSH becomes valuable for Composer, scripted deployments, log inspection, database imports and repeatable maintenance. If your workflow uses command-line tools now or may use them later, treat SSH access and its restrictions as a selection criterion.
What happens when a PHP version reaches end of life?
The host may remove it, keep it temporarily with security backports, or leave you responsible for upgrading. Ask for the retirement date and test the next supported branch early so a forced change does not become an outage.
Is a staging site always included with managed hosting?
No. Some plans charge for an additional environment, limit its storage or exclude database synchronization. Verify whether staging uses the same PHP branch, extensions and worker settings as production before relying on it for upgrade testing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
