Best php.ini Settings for WordPress and Laravel on Shared Hosting and VPS

If you run WordPress or Laravel on shared hosting or a VPS, your php.ini settings quietly decide whether your site feels fast and stable or slow and fragile. The application code, database and caching are important, but PHP itself is the engine that executes every request. If the engine is misconfigured, you get timeouts, white screens, failed uploads, random 500 errors and resource‑limit warnings – even on good hosting hardware.

In this guide, we will walk through the most important php.ini directives for WordPress and Laravel, explain what they actually do and give concrete, tested values for typical site sizes on both shared hosting and VPS plans. We will also highlight where shared hosting limits stop you, when it makes sense to move to a VPS, and how we set things up in practice when deploying projects on dchost.com infrastructure. You can treat this as a checklist: compare it with your current settings, adjust carefully, and you will usually see an immediate improvement in stability and developer happiness.

Why php.ini Matters So Much for WordPress and Laravel

Both WordPress and Laravel are written in PHP. Every page view, API call, cron job, Artisan command or WooCommerce checkout runs inside a PHP process that is governed by php.ini. That file (plus a few .ini overrides) defines hard limits and default behaviour for:

• How much RAM each PHP process can use (memory_limit).
• How long scripts may run before they are killed (max_execution_time and max_input_time).
• How large uploads and forms can be (upload_max_filesize, post_max_size, max_input_vars).
• How errors are handled (error_reporting, display_errors, log_errors).
• How sessions and cookies behave (session‑related directives and security flags).
• Which PHP extensions and accelerators are available (like OPcache).

The same code can behave very differently depending on these values. For example, a WooCommerce checkout with a big cart might work fine with a 256M memory limit but constantly fail with 64M. A Laravel import job may need a higher max_execution_time and a larger post_max_size to process CSV uploads.

We have a separate deep dive on the individual PHP resource limits in our article Choosing the right memory_limit, max_execution_time and upload_max_filesize. Here, we focus specifically on the combination of settings that tends to work best for WordPress and Laravel on shared hosting and VPS.

Where and How You Can Edit php.ini on Shared Hosting and VPS

On shared hosting (cPanel / DirectAdmin style)

On most shared hosting platforms, you do not edit the global server php.ini directly. Instead, you typically have one or more of these options:

• Per‑account php.ini or .user.ini: Many panels let you customize certain directives for your account or per directory by adding a php.ini or .user.ini in public_html/. The server merges those with the global defaults.
• GUI editor in the control panel: cPanel often has a “Select PHP Version” or “MultiPHP INI Editor” section where you can change the most common settings without touching files manually.
• .htaccess overrides: On Apache with mod_php, some directives can be changed via .htaccess using php_value and php_flag. On modern setups (PHP‑FPM), this is less common and .user.ini is preferred.

Remember that shared hosting also enforces account‑level resource limits (CPU, RAM, I/O, entry processes). Even if you bump memory_limit in php.ini, you cannot exceed the account’s real memory allocation. If you often see “Resource Limit Reached”, it’s worth reviewing our article Understanding cPanel resource limits.

On a VPS (root / sudo access)

On a VPS, you (or your sysadmin) control the full PHP stack. Typical locations:

• /etc/php/8.2/fpm/php.ini – PHP‑FPM for web requests.
• /etc/php/8.2/cli/php.ini – CLI PHP for php artisan and wp-cli.
• /etc/php/8.2/mods-available/*.ini – individual extension configs.

After changing php.ini on a VPS, you must restart or reload PHP‑FPM (and sometimes the web server):

• systemctl reload php8.2-fpm (Debian/Ubuntu).
• systemctl restart php-fpm (AlmaLinux / Rocky Linux with generic service names).

One common mistake with Laravel is forgetting that the CLI and FPM have separate php.ini files. Long‑running queue workers or schedulers use /etc/php/*/cli/php.ini, so you may need a higher memory_limit or a different max_execution_time there than in the web SAPI. We use this separation intentionally in many Laravel deployments on our VPS plans.

Core php.ini Settings for Any Modern WordPress or Laravel Site

Let’s look at the essential directives you should review for any WordPress or Laravel project, regardless of hosting type.

1. memory_limit

memory_limit caps how much RAM each PHP process can use. If a script exceeds it, PHP throws a fatal “Allowed memory size exhausted” error.

• Too low: random white screens, WooCommerce admin pages failing, large Elementor pages or Laravel collections causing fatal errors.
• Too high on shared hosting: a single heavy request can eat too much of your account’s limited RAM and impact other sites.

Practical ranges we see work well:

On a VPS, aligning memory_limit with PHP‑FPM pool settings is important so you do not overcommit RAM. We break this down in more detail in our PHP‑FPM and Laravel tuning articles, such as Laravel production optimization with PHP‑FPM and OPcache.

2. max_execution_time and max_input_time

max_execution_time sets how long (in seconds) a script is allowed to run before PHP terminates it. max_input_time controls how long PHP may spend parsing input data (POST/GET files). Example ranges:

• Front‑end page views: 30–60s is usually enough. If a page takes longer, the bottleneck is elsewhere.
• WordPress plugin updates or WooCommerce imports: 120–300s on shared hosting can be helpful.
• Laravel queue workers: often set to 0 (unlimited) and controlled by Supervisor/systemd instead.

On shared hosting you may not be allowed to set extremely high values. On a VPS, you have more freedom, but hanging scripts will still waste resources, so do not just set everything to “unlimited”.

3. upload_max_filesize and post_max_size

These two work together:

• upload_max_filesize – maximum size of a single uploaded file.
• post_max_size – maximum size of the full POST body (all files + form fields).

post_max_size should be at least as large as upload_max_filesize, usually a bit higher (for form overhead).

If you plan frequent large uploads, also think about web server timeouts, browser behaviour and chunked uploads. We cover full upload strategy in our guide to large media file uploads with PHP, Nginx/Apache and chunking.

4. max_input_vars

max_input_vars limits how many form fields PHP will accept. WordPress admin pages with complex option screens, big menus or page builders can easily hit the default of 1000. Symptoms are mysterious: some settings randomly reset or are not saved.

Safe typical values:

• Standard WordPress sites: 2000–3000.
• WooCommerce + big theme options / page builders: 3000–5000.
• Laravel back‑offices with large forms: 3000+ (depending on usage).

5. date.timezone

Always set date.timezone to your primary region, for example:

• date.timezone = Europe/Istanbul
• date.timezone = Europe/Berlin

This prevents PHP notices and ensures consistent log timestamps, cron behaviour and scheduled tasks across WordPress and Laravel.

6. OPcache and performance‑related settings

On PHP 7+ and especially PHP 8.x, OPcache is critical. It keeps compiled PHP bytecode in memory so each request does not have to re‑parse PHP files. On shared hosting you typically just enable OPcache; on a VPS you can fine‑tune it.

We have a full, tested configuration in PHP OPcache settings for WordPress, Laravel and WooCommerce, but at minimum ensure:

• opcache.enable=1 (for web).
• opcache.memory_consumption is high enough (e.g. 128–256M for medium sites).
• opcache.max_accelerated_files is large enough (e.g. 10000–20000).

Recommended php.ini Settings for WordPress on Shared Hosting

On shared hosting, we usually have three goals for WordPress:

1. Avoid white screens and failed uploads.
2. Keep resource usage under the account limits.
3. Have safe defaults for both the front end and wp‑admin.

Baseline php.ini for a small‑to‑medium WordPress site

You can adapt and place something like this in public_html/php.ini or use the equivalent values in your panel’s PHP editor (exact syntax varies by host):

memory_limit = 256M
max_execution_time = 60
max_input_time = 60
max_input_vars = 3000
upload_max_filesize = 64M
post_max_size = 64M

; Always set your timezone
date.timezone = Europe/Istanbul

; Error handling for production
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
log_errors = On
error_log = /home/USERNAME/logs/php-error.log

; Security-related
expose_php = Off
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1

Explanations:

• 256M memory_limit: usually enough for WooCommerce sites with a reasonable plugin set. If you use heavy page builders + many plugins, you may need 384M, but check your host’s limits first.
• 60s execution/input time: balances long plugin updates with the risk of scripts hanging forever.
• 64M upload/post size: suitable for typical image and small video uploads.
• Error logging to a custom file: keeps errors out of public output and centralises them for debugging.
• Secure session cookies: httponly helps mitigate XSS stealing cookies; secure = 1 makes sure cookies are only sent over HTTPS (make sure your site is actually using HTTPS).

If you are in the process of migrating everything to HTTPS, or want guidance on HSTS and canonical redirects, our article Full HTTP→HTTPS migration with HSTS and canonical settings walks through the hosting‑side steps.

WordPress staging and maintenance tools

When you clone a site to a staging subdomain or run heavy maintenance plugins (database cleaners, search/replace, backup tools), temporarily raising max_execution_time to 120–300 seconds can help. After you are done, bring it back down so buggy plugins cannot hang for minutes.

If you frequently run staging environments on shared hosting, our article Setting up a WordPress staging environment on shared hosting gives a full workflow, including database sync and safe DNS/URL choices.

Debug settings for development vs production

For live WordPress sites, keep display_errors = Off. Showing raw PHP errors to visitors is both a security and UX problem, and can leak file paths and SQL queries. Use:

• WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY in wp-config.php for app‑level debugging.
• log_errors = On in php.ini to have PHP‑level issues recorded privately.

We go deeper into safe logging strategy in PHP error logging best practices on hosting servers.

Recommended php.ini Settings for Laravel on Shared Hosting and VPS

Laravel has slightly different patterns than WordPress. It is more likely to have:

• Long‑running queue workers or Horizon.
• Scheduled tasks via php artisan schedule:run.
• API endpoints with large JSON payloads.
• Artisan commands for imports, reports and maintenance.

This means you usually tune both FPM (web) and CLI php.ini separately.

Laravel on shared hosting

Laravel can work on shared hosting if you do not need persistent queue workers and your jobs are light. In this environment, you are constrained similarly to WordPress:

• No long‑running workers: you will likely use database queue + php artisan queue:work --once or rely on synchronous jobs.
• Moderate memory_limit: 256M is a reasonable starting point.

A typical php.ini for a small Laravel app on shared hosting might look like:

memory_limit = 256M
max_execution_time = 60
max_input_time = 60
upload_max_filesize = 32M
post_max_size = 32M
max_input_vars = 3000

date.timezone = Europe/Istanbul

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
log_errors = On
error_log = /home/USERNAME/logs/laravel-php-error.log

expose_php = Off
session.cookie_httponly = 1
session.cookie_secure = 1

You should still keep Laravel’s own .env set to APP_ENV=production and APP_DEBUG=false in production, so Laravel does not leak stack traces to visitors.

Laravel on a VPS: separating web and CLI behaviour

On a VPS, you get the most out of Laravel by running:

• Nginx or Apache → PHP‑FPM for web requests.
• Supervisor/systemd for php artisan queue:work or Horizon.
• Cron for php artisan schedule:run.

Here, we often apply different limits:

• Web (FPM) php.ini: moderate memory_limit per request (256M–512M), max_execution_time around 60s.
• CLI php.ini: higher memory_limit for expensive jobs (512M–1024M), max_execution_time = 0 for workers, and control restarts at the process manager level.

Example (FPM php.ini snippets):

; /etc/php/8.2/fpm/php.ini
memory_limit = 512M
max_execution_time = 60
max_input_time = 60
post_max_size = 64M
upload_max_filesize = 64M
max_input_vars = 5000

Example (CLI php.ini snippets):

; /etc/php/8.2/cli/php.ini
memory_limit = 1024M
max_execution_time = 0
max_input_time = 0

And then in Supervisor for queue workers (conceptual example):

[program:laravel-worker]
command=/usr/bin/php /var/www/app/artisan queue:work --sleep=3 --tries=3
numprocs=4
autostart=true
autorestart=true

This way, web traffic cannot starve the server with huge memory usage, but background workers still get enough space to process big jobs. For a full Laravel deployment playbook on VPS (including Nginx, PHP‑FPM and Horizon), see our Laravel on VPS deployment guide.

Debugging, Logging and Security Options in php.ini

Error reporting levels

For PHP 8.x in production, a common pattern is:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
log_errors = On

This keeps logs detailed enough for developers, while not exposing errors to users. During development (on a separate dev/staging environment), you might temporarily use:

error_reporting = E_ALL
display_errors = On
log_errors = On

Just make sure you never leave display_errors = On in production.

Log file placement and rotation

Set error_log to a path outside the public web root when possible, for example:

• /home/USERNAME/logs/php-error.log on shared hosting.
• /var/log/php/php-error.log on VPS with proper permissions.

On a VPS, combine this with logrotate to avoid disk growth. If you want a more structured observability stack, we describe centralised log management on VPS environments using modern tooling in our article VPS resource usage and monitoring.

Security‑related directives worth checking

php.ini is not a full security solution, but a few directives help reduce risk:

• expose_php = Off – hides the exact PHP version in HTTP headers.
• allow_url_fopen = On/Off – turning it off blocks some remote file includes, but also breaks legitimate use (file_get_contents() on URLs). In many shared setups, it stays On and WAF rules add protection.
• session.cookie_httponly = 1 – prevents JavaScript access to cookies, reducing XSS impact.
• session.cookie_secure = 1 – ensures cookies are only sent over HTTPS (set once your site is fully HTTPS).
• session.use_strict_mode = 1 – mitigates session fixation by rejecting uninitialised IDs.
• disable_functions – you can disable high‑risk functions like exec, shell_exec, passthru on shared hosting if you never need them. On Laravel deployments that run CLI tools, be careful not to break legitimate usage.

Combine these PHP options with good practices at the application level (hardened admin logins, WAF, 2FA). For WordPress, we shared a complete login hardening approach, including XML‑RPC and reCAPTCHA, in our secure WordPress login architecture guide.

PHP Version and Compatibility: WordPress, Laravel and PHP 8.x

Your php.ini settings always sit on top of a specific PHP version. Recent WordPress and Laravel versions run best on modern PHP 8.x – but some older plugins and packages may have compatibility issues.

When upgrading PHP on shared hosting or a VPS, we recommend:

• Testing WordPress themes/plugins or Laravel dependencies on a staging copy first.
• Ensuring OPcache is enabled and tuned properly on the new version.
• Reviewing error_reporting and logs carefully after the upgrade for deprecations.

We maintain a detailed step‑by‑step process in our article PHP 8 upgrade guide on shared hosting and VPS for WordPress and Laravel, which you can follow alongside adjusting your php.ini.

Tuning for Growth: When to Raise Limits and When to Move to a VPS

On shared hosting we encourage customers to treat php.ini tuning as a way to stabilise their sites, not as a way to squeeze every last drop of capacity out of a limited account. Signs that you are hitting the ceiling even after reasonable php.ini adjustments:

• Frequent “Resource Limit Reached” messages in the control panel.
• WooCommerce checkouts or admin screens timing out during traffic spikes.
• Laravel jobs that cannot finish within the short execution windows shared hosting allows.
• Regular 5xx errors under moderate concurrent traffic.

In those cases, it is not enough to keep raising memory_limit or max_execution_time. Moving the project to a properly sized VPS with dedicated CPU/RAM and tailored php.ini + PHP‑FPM pools will bring far more predictable performance. We summarise capacity planning for common workloads in our article How many vCPUs and how much RAM you really need for WordPress, WooCommerce and SaaS.

On dchost.com we see a typical path:

1. Start on shared hosting with conservative but stable php.ini values.
2. Optimise WordPress or Laravel code and enable OPcache / caching.
3. Once the project grows (traffic, orders, background jobs), move to a VPS and re‑tune php.ini and PHP‑FPM around that project’s real profile.

If you also manage your own hardware, the same principles apply on dedicated servers or colocation: plan PHP limits, pool sizes and OPcache memory based on your CPU/RAM budget, then verify with real‑world benchmarks.

Summary and Next Steps

The right php.ini values for WordPress and Laravel are not magic numbers; they are practical limits that reflect your site’s size, traffic patterns and hosting environment. On shared hosting, your goal is to avoid obvious bottlenecks (too‑low memory_limit, tiny upload sizes, low max_input_vars) while respecting account limits. On a VPS, you have more freedom to separate web and CLI configurations, allocate enough memory for OPcache and background workers, and tune PHP‑FPM pools for predictable concurrency.

As a quick checklist, review at least: memory_limit, max_execution_time, max_input_time, upload_max_filesize, post_max_size, max_input_vars, date.timezone, error handling (display_errors, log_errors), OPcache, and a few security‑oriented directives. Combine those with solid application‑level practices (caching, database tuning, secure logins) and you will feel the difference in day‑to‑day stability.

If you are unsure whether your current hosting plan or php.ini setup is enough for your next phase – a growing WooCommerce store, a Laravel SaaS, or a content‑heavy blog – our team at dchost.com can help you evaluate options across shared hosting, VPS, dedicated servers and colocation. We work with these settings in real projects every day and can help you translate your business requirements into a concrete, safe PHP configuration and hosting architecture.